I mean, you can't have your cake and eat it too - if you claim that a particular issue is not a bug and you won't fix it, then you have no ethical grounds to say that it shouldn't be disclosed.
Responsible disclosure expects delaying public disclosure to protect the users while the vendor prepares a fix. If the vendor says that they won't fix it, then it's not only a right, but a moral duty to disclose that vulnerability to the users.
Frankly, I think HackerOne deserves a bit of blame for that. Any WONTFIX ought to be made public automatically unless there are extenuating circumstances (like the vulnerability being reported against the wrong product).
H1 itself has no WONTFIX status, FYI. A bug that's not considered to be a bug by the program will either be closed N/A or informative. Ultimately, disclosures are handled and controlled by the program, not by H1; this is both a good and bad thing (and I say that as both a HackerOne employee and a hacker on the platform -- it's a complicated issue from both sides).
There is definitely politics involved, but not H1 internal. The issue is that every program handles disclosure itself, so H1 itself doesn't really have the power. That could be changed at a policy level, but I'm not sure that'll happen (or should happen, honestly; I don't really know where I land on it).
From what I see, your value proposition is both to bug bounty hunters and to companies who see a value in having Hackerone manage their bug bounty program.
This effect (no matter the cause) of incident is about the worst thing that could happen to a company whose value proposition is that. It's like the bad old days where companies would legally threaten you if you found a bug, and from an outside perspective, Hackerone seems to promote it.
If I were an ethical hacker, I'd think twice before using your bug bounty program for fear of that treatment.
If I were a potential customer (or even a current customer), I don't know if I'd want to be associated with a company that tolerates veiled threats against ethical hackers.
"The worst H1 or a client can do is kick you off the platform."
As a hacker on hackerone, this is not my understanding of the relationship. Generally speaking the programs give you "authorized access" under the CFAA conditional on following the disclosure guidelines. I don't know about for other countries, but for the US I'm pretty sure this means that breaking the guidelines means you've retroactively committed a felony.
Now seems a little questionable about if any federal prosecutor would actually take the case, but it definitely doesn't seem like a strictly civil issue to me.
CFAA could (and likely would) apply for remote vulnerabilities i.e. exploiting SQLi on someone else's servers; but in the case of local privilege escalation like this particular case all the exploiting/testing happens on systems owned and controlled by the researcher, so it doesn't violate CFAA and doesn't need any permission from Valve - the breach happened with authorization from the system owner.
You need permission to pentest someone else's systems, you don't need permission to pentest software on your own systems even if that software is written by someone else. In an enterprise setting it's possible that you have signed a contract where you agree not to do such testing or not to publicize its results; but violating that would be a civil matter regarding the terms of that contract, not a felony in respect to CFAA.
I agree, if you're testing someone else's website or servers, you should comply with the scope and disclosure rules or not do the testing, unless the vendor has something else on their website that implicitly authorizes testing (like an email address to send reports to).
But that doesn't apply to Steam; nothing they write can really impact your ability to conduct security research on your own computer.
Yeah, agree in this specific case about local research (baring DMCA issues). Most H1 scopes seem to be remote targets as opposed to downloadables though.
I'm having trouble thinking of a single researcher that has left the US for legal reasons. There are lots of researchers now in Southeast Asia! But that's because bounty programs like H1 let those people work remotely.
Among other reasons, because the site is literally stuffed to its gills full of people reporting bullshit security issues, like "user impersonation possible" (if you convince a user to open developer tools and give you their session cookie), and H1 wouldn't be doing any good if it generated a constant stream of people "WONTFIX-disclosing" those reports.
I don't quite follow this reasoning. Are you saying that by allowing people to make their NA / WONTFIX reports public, it will dilute the H1 brand? Does association with H1 have a significant effect of the perceived legitimacy of individual public disclosures? Why does this matter?
My presumption is that the "other reasons" are business/political and centered around the desire to provide value to or establish goodwill with corporate partners.
People can publish whatever they want, and the only thing H1 can do about it is disinvite them from their platform. But anyone who suggests that H1 encourage people to publish NA/WONTFIX bugs probably hasn't had much contact with H1 bounty reports.
In reality, valid bugs being quashed by vendors is not the real problem H1 has.
I would rather suggest that H1 discourage (or even prohibit) their partners from dis-inviting reporters for publicizing NA/WONTFIX bugs.
In this particular case, is sounds like H1 (or an employee thereof) actively discouraged disclosure, which seems like a problem.
> In reality, valid bugs being quashed by vendors is not the real problem H1 has.
There can clearly be more than one problem. I still fail to see the relevance of the "bug report quality" problem to this discussion (beyond explaining why automatic disclosure of NA/WONTFIX reports is not helpful.)
You're probably outside the security sphere, but H1 is already taken seriously. There is no per-requisit for them to do so to be taken seriously as you state.
There comes a moment when inaction translates to deception, and if you need clarification for what that looks like in the wild, look no further than Facebook.
HackerOne should be getting slated a lot more than they are.
They are selling their bug bounty program to their customers (e.g. Valve) as offering the equivalent control to a traditional pen test contract (with confidentiality) while also trying to sell the spec work/no findings, no pay price advantage of a bug bounty program. It's scummy as hell.
If you don't want to participate in bug bounties, don't participate in them. It's not like it's hard out there in 2019 for application pentesters. This is a "world's tiniest violin" argument.
It's still interesting to hear comments like in the GP for an unknowing person like me.
Your comment is interesting as well, if only for the defensive reaction without addressing the "being scummy" claim. I'm basically hearing, yeah it's scummy, now get off my lawn.
I uninstalled Steam the moment I read the previous disclosure and Valve's approach to it. Any company that treats security as it used to be in the 90s ought to be shunned.
Not sure what you're getting at. There's very few things we need, sounds like they're sacrificing a little to avoid giving a company they deem unethical any money.
I love games and can’t play my steam collection now. But if I have to give that up so that some silly bug elsewhere in my system doesn’t expose me to a ransomware attack (or worse), so be it. I’ll find another way.
Steam's DRM (CEG) customizes the executables so it won't play without the Steam client running and logged in to the correct account. There are lots of not-DRM-enabled games on Steam, but they're decidedly in the minority.
That's why GOG.com is my first choice. They even provide a nice Steam-like installer (unfortunately, no Linux version of the installer), while letting you download your games DRM-free, archivable and standalone.
Not all of the games on GOG are DRM-free at this point. Some require GOGGalaxy, their version of the steam client.
I went through a frustrating refund process after learning about this after making a purchase.
There are a number of tools called “steamworks emulators” that allow one to bypass this outright for many games. These are generally seen as piracy tools, but there’s no good reason you couldn’t use them when you wanted to play your purchased game collection without DRM.
Be a bit careful when experimenting, though. You may run into problems syncing your cloud saves for some games if/when you go back to the official client.
As you'd expect there are (or were, a few years ago when my account was temporarily banned for a few days) cracks to unlock the executables. You might need Steam still installed for this to work the first time, I'm not sure.
Legally I don't know where that stands, but morally I'd say we have a right to play the games we paid for.
Uhg, this drives me nuts. Apparently I'm not allowed to play Sepiko: Shadows Die Twice while traveling outside of the country. A VPN can temporarily get things going again, or staying in Offline mode, but what a pain in the ass...
Nope, that won't work for most Steam games. However, that's why there's GOG (gog.com), DRM free games. You can download the game installation kits using your browser and if you ever decide to stop accessing their site (or stop having access to the Internet) you can still play/install downloaded games.
You would think that any platform/app that actually contains the ability to load currency into itself would take any security threat seriously regardless of the scope.
The researcher can still disclose it, they just aren't going to get permission to disclose it on the Hackerone program. Most things out of scope don't get publicly disclosed as far as I know.
Without seeing the communications it's hard to say, but "When the security researcher -- named Vasily Kravets-- wanted to publicly disclose the vulnerability, a HackerOne staff member forbade him from doing so, even if Valve had no intention of fixing the issue" sounds like more than just not being able to disclose on the H1 program.
I submitted an XSS on the tesla website to hackerone, it was marked as a duplicate. A week later, shared it with an XSS mailing list and got an angry email from HackerOne soon after. Public disclosure violates the terms of their reporting program EVEN if they reject your report.
I'm really curious how much of what is reported to HackerOne ever gets and actual patch. It kind of seems like there are bunch of known vulnerabilities idling on their platform without quick fixes. Should be interesting once the HackerOne database is inevitably leaked.
HackerOne should start requiring companies pay researchers for duplicates - that the company already knew of a flaw should make them more liable, not less.
> HackerOne should start requiring companies pay researchers for duplicates
That would create a perverse incentive for researchers to tell their friends about the vulnerability so that they can resubmit it and also get a bounty.
The problem could be solved on the side of the researchers by splitting the bounty among all submissions of the same bug, but anyone else with access to the report (employees of either HackerOne or the relevant company) could try to get a share by having someone create a duplicate report.
First come, first served seems like it would be the hardest to game, as the first reporter is guaranteed to have actually done the work (not counting rogue employees who create bugs to "find" and report).
There should probably still be some kind of reward for duplicate reports to avoid discouraging researchers, but something symbolic like publicly acknowledging that they found a bug might be enough to provide validation.
> First come, first served seems like it would be the hardest to game
For external parties, yes. However it's the easiest to game for those liable, since you can just mark whatever you want as a "duplicate" and refuse to pay the bounty.
Offering bounties for public disclosures helps remove a lot of perverse incentives.
I like your first idea of splitting the bounty. I think its unlikely employees of HackerOne or the relevant company would risk their job for a small share in a bug bounty.
Splitting the bounty does nothing to fix the incentive problem, since it's the same outlay from the vendor whether they fix after 1 report, or a year later after 20.
In reality, vendors (or at least, serious vendors) aren't gaming H1 to stiff bounty hunters. If anything, the major complaint vendors have about H1 is that they aren't paying enough --- that is, they deal with too many garbage reports for every report that actually merits a fix.
I wonder if you could scale it so that the goal behaviors were also a market equilibrium. So no complicated prohibitions for going public, but each additional report (aided easily by going public) would cut into your own earnings some percentage. But on the flip side, each additional report costs the company money too, so they have monetary incentive also for pushing a fix before someone else finds it or you decide to give up waiting and go public with it anyways. With each on appropriately decreasing scales so there’s always appropriate minimum and maximum payouts.
I assume it'd be hard to convince companies it may be in their better interest to set up an incentive structure this way. But perhaps a third party platform could find some such mutually beneficial equilibrium.
If they get a duplicate report they should let you know the disclosure timeline and keep you posted on progress fixing it. If they're not doing that they have no right to prevent disclosure.
It seems weird that HackerOne put themselves in such a deeply loser position to try to be the ones to prevent submitters from revealing security issues. Why not be a neutral party, and let the companies try to enforce rules on the hackers in these cases?
Eh that one is on you I think. How long did you wait? If we have 5 researchers report the same vulnerability in 30 days we're going to count it as duplicate and still expect to have a full 60-90 days from the first report to deploy a fix.
It was pretty low hanging fruit. I was going through an XSS tutorial and used their site for practice. `<script>alert(1)` could be saved into several user fields including Name and would then be executed on every subsequent pageload around the site.
If there was some indication that someone had reported it recently I maybe would have waited longer, but I suspect this bug had been known for months.
> Kravets said he was banned from the platform following the public disclosure of the first zero-day. His bug report was heavily covered in the media, and Valve did eventually ship a fix, more as a reaction to all the bad press the company was getting.
> The patch was almost immediately proved to be insufficient, and another security researcher found an easy way to go around it almost right away.
Even in the scope of the original comment, doesn't it create a pretty perverse incentive to allow companies to mark HackerOne bugs as WONTFIX and then ban researchers who disclose them?
Isn't security through obscurity largely to be avoided? I thought the working model for most security researchers was: if it's not worth fixing, it's not worth hiding.
More to the point, I thought that responsible disclosure always came with an expectation of public disclosure. The advice I've always been given is that you should never disclose with conditions -- ie. "fix this and I won't tell anyone."
It should always be, "I am going to tell everyone, but I'm telling you first so you can push a fix before I do."
Responsible disclosure expects delaying public disclosure to protect the users while the vendor prepares a fix. If the vendor says that they won't fix it, then it's not only a right, but a moral duty to disclose that vulnerability to the users.