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.
This sounds to me like an edge case that H1 should address if it really wants to be taken seriously.
2. It is not the case that all reporters want their findings disclosed publicly, even if they're rejected.
3. Reporters already retain the right to publish findings however they'd like. The worst H1 or a client can do is kick you off the platform.
4. A bug bounty platform that mandated disclosure of any sort would lose all its customers to the platform that didn't have that mandate.
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.
Strongly agree on all other points though.
But that doesn't apply to Steam; nothing they write can really impact your ability to conduct security research on your own computer.
You don't have to get into legal trouble to see which way the wind is blowing.
There is no such thing as a retroactive crime in rule of law systems. Disclosure could be a considered an offense in its own, though.
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.
However, why doesn't H1 expressly allow reporters the option of public disclosure for all NA or WONTFIX reports?
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.
In reality, valid bugs being quashed by vendors is not the real problem H1 has.
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.)
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.
Edit: I should add from this, it actually looks like its Hackerone making the veiled legal threat: https://mobile.twitter.com/enigma0x3/status/1160961861560479...
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.
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.
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.
Ended up naming it 'Bad QR', putting this page together and sending them a private link (https://writecodeeveryday.github.io/projects/badqr/)
;-)
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.
Legally I don't know where that stands, but morally I'd say we have a right to play the games we paid for.
Doesn't seem too unreasonable.
> The patch was almost immediately proved to be insufficient, and another security researcher found an easy way to go around it almost right away.
You might want to read the article.
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."
Does HackerOne operate under different rules?
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.
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?
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.
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.
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.
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.
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.