Hacker News new | ask | show | jobs
by EnFinlay 2491 days ago
a) Program has scope that doesn't include X

b) Researcher reports vulnerability that falls under X

c) Since it's out of scope, it's closed as N/A

d) Report is locked because company doesn't want to publicly disclose a vulnerability in their system via the Hackerone platform

What's the problem here? Just go with normal vulnerability disclosure. Bug bounty programs are a two way street, and respecting the scope is part of that.

Edit: I guess the important part is that the researcher was then banned for disclosing the report. Seems reasonable, honestly. I don't agree with it, but I understand it.

7 comments

Acknowledgement is one thing. Disclosure is another.

If Steam had no problem acknowledging that this functionality exists, they should have had no problem with it being disclosed. There lies the problem. In the bathroom with the needle in their arm; "...there's no problem here..." but if you swing the door open they'll still try to shut it. Because they know they're wrong.

If HackerOne isn't going to help you they have no right to hinder you. If they want to strongarm everyone into effectively the same agreement as an NDA then there literally is no point in turning vulnerabilities into HackerOne.

They seem to only exist as a cow-catcher on the locomotive of software vendors too lazy to actually fix crappy code.

"Who needs to fix code and shell out bounty if you can pinpoint and silence the researcher?"

> If HackerOne isn't going to help you they have no right to hinder you. If they want to strongarm everyone into effectively the same agreement as an NDA then there literally is no point in turning vulnerabilities into HackerOne.

The article gets this part wrong: the hacker isn't banned from H1, which he says in his blog post -- "Eventually things escalated with Valve and I got banned by them on HackerOne — I can no longer participate in their vulnerability rejection program (the rest of H1 is still available though)." HackerOne is in no way punishing the hacker for his reports and/or public disclosures, for what it's worth.

(Disclosure: I am on the community team at H1, though I've had effectively zero involvement with this.)

You can define whatever you want for your project's scope, but when you're distributing self updating binaries to an audience the size of steam's and you act this casual about an admin escalation exploit, you deserve whatever damage to your reputation that you get.
Thing is, as a result of the ban the next disclosure was immediately public. This left more people vulnerable than the responsible disclosure method would have.

Hence, this practice by steam makes all users of steam less secure (doubly so as they actually don't want to fix these issues). This is something the public deserves to know, so they can act accordingly.

Bug bounty programs exist primarily for the companies’ benefit. If you do not respect the security community, the best you can expect is for researchers to publicly disclose the vulnerabilities. At worst, black hats will find them and sell them since they can be very valuable.
If the vulnerability is out of scope, why do they care about disclosing it? If it is a vulnerability in their system, why is it out of scope?
Well, they did go with normal vulnerability disclosure, and were retaliated against. That's not okay.
Retailiated as in he was banned from their bug bounty program. The program with a scope that they went outside of. I think it's reasonable to be banned.

Obviously it would be better if Valve fixed the issue and gave a (possibly reduced due to out of scope) bounty.

That makes sense if the application is, like, a SAAS app, and the scope is, like, "don't employ credential stuffing or test any of our 3rd party dependencies that have not given us permission to be included in this scope".

But this is software people install on their desktops, and Valve has no say in how security researchers approach that stuff. Valve can and maybe even should exclude LPEs from their bounty scope (if that's not what they're focusing on right now), but they can't reasonably ban people for publishing vulnerabilities they've scoped out of the only mechanism they've provided for submitting and tracking vulnerabilities.

The next time that researcher finds a vulnerability he's definitively not going to report it "responsibly" even if it is "within scope".