Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Valve and HackerOne: how not to handle vulnerability reports

blog.jakegealer.me

Post reply on HN
Print view View original

31–40 of 162 posts

Re: Valve and HackerOne: how not to handle vulnerability reports

#31

Post by gruez »

vntok wrote: post #20
tcd wrote: post #7

Just drop a line on twitter saying you've discovered a vulnerability in $popularSoftware and mention $company. Say you'll be disclosing in 90 days if $company doesn't issue a reply publicly. Make sure to deal with an actual human and that everything is done according to best practice. You may even get publicity this way and even if it's unethical it can be sold or used to your advantage. If they care, trust me when I…

> Say you'll be disclosing in 90 days if $company doesn't issue a reply publicly. That's blackmail. An expedient way of getting your door breached.

That's similar to how project zero (by google) works. Exploits get released in 90 days unless the developers can provide a plausible justification why that deadline can't be reached.

Re: Valve and HackerOne: how not to handle vulnerability reports

#32

Post by hmage »

vntok wrote: post #20
tcd wrote: post #7

Just drop a line on twitter saying you've discovered a vulnerability in $popularSoftware and mention $company. Say you'll be disclosing in 90 days if $company doesn't issue a reply publicly. Make sure to deal with an actual human and that everything is done according to best practice. You may even get publicity this way and even if it's unethical it can be sold or used to your advantage. If they care, trust me when I…

> Say you'll be disclosing in 90 days if $company doesn't issue a reply publicly. That's blackmail. An expedient way of getting your door breached.

Google Project Zero is doing exactly that -- disclosing them in 90 days no matter if they're fixed or not.

This kind of pressure is helpful, because otherwise stories of OP will be dominant and security problems will stay unpatched.

Re: Valve and HackerOne: how not to handle vulnerability reports

#33

Post by gnfargbl »

mtlynch wrote: post #23

I think Valve and HackerOne handled this poorly, but I think the author is partially at fault for repeatedly failing to communicate the issue clearly. I worked as a penetration tester for a while, and I had trouble understanding what the author was saying. The headline should have been that the steam mobile app makes requests to the plaintext HTTP URL ( http://store.steampowered.com ) instead of the TLS-authenticated…

So in a nutshell, could we summarise the issue here as "Valve didn't use TLS and thus Valve's users are vulnerable to the exceptionally well-known consequences of not using TLS?"

If so, then... okay, but I don't know what the blog author was expecting when he reported this. Pointing out that HTTP has MiTM possibilities is kind of up there with pointing out that the sky is blue. If, in 2020, a site has made the choice not to upgrade to TLS then it's more likely a conscious decision than an oversight.

Re: Valve and HackerOne: how not to handle vulnerability reports

#34

Post by _jal »

rasz wrote: post #4

Important life lesson: drop 0days on twitter, you wont get bounties, but at least you will get recognition and job offers.

My guess is that, like the crypto wars, disclosure fights are going to happen every generation.

There was a big discussion about this in the 90s. Vendors would sit on bugs forever, frequently simply to suppress knowledge of them rather than fixing them. Hackers rebelled; some simply published what we now call 0days, others would publish on a non-negotiable timeline. Eventually, "responsibly disclosure" became a norm.

Looks like companies have once more figured out how to game the process, so their counter-parties are going to renegotiate. And the cycle of life is complete.

Re: Valve and HackerOne: how not to handle vulnerability reports

#35

Post by thoraway1010 »

vntok wrote: post #20
tcd wrote: post #7

Just drop a line on twitter saying you've discovered a vulnerability in $popularSoftware and mention $company. Say you'll be disclosing in 90 days if $company doesn't issue a reply publicly. Make sure to deal with an actual human and that everything is done according to best practice. You may even get publicity this way and even if it's unethical it can be sold or used to your advantage. If they care, trust me when I…

> Say you'll be disclosing in 90 days if $company doesn't issue a reply publicly. That's blackmail. An expedient way of getting your door breached.

The idea that your would get a no knock forcible entry for disclosing a bug is appalling and potentially an indictment of our entire criminal justice system.

I'm assuming vntok's legal conclusion and claim of the type of law enforcement response is true (please do not make things up on hackernews).

In which case my former support for the police and low and order is SERIOUSLY diminished.

You have a non-violent offense, that is not an actual offense, and they are doing swat door breaches on you. wow! The priorities of these companies and law enforcement is backwards then.

I guess folks are being told to just sell it to a zero day vendor (which also happens to work for the same govt agency that will bust down your door if you disclose publicly). Pretty appalling behavior here!

Re: Valve and HackerOne: how not to handle vulnerability reports

#36

Post by minitech »

gnfargbl wrote: post #33
mtlynch wrote: post #23

I think Valve and HackerOne handled this poorly, but I think the author is partially at fault for repeatedly failing to communicate the issue clearly. I worked as a penetration tester for a while, and I had trouble understanding what the author was saying. The headline should have been that the steam mobile app makes requests to the plaintext HTTP URL ( http://store.steampowered.com ) instead of the TLS-authenticated…

So in a nutshell, could we summarise the issue here as "Valve didn't use TLS and thus Valve's users are vulnerable to the exceptionally well-known consequences of not using TLS?" If so, then... okay, but I don't know what the blog author was expecting when he reported this. Pointing out that HTTP has MiTM possibilities is kind of up there with pointing out that the sky is blue. If, in 2020, a site has made the choice…

It was an oversight. They had HTTPS support. Going by the bug report, the client checked for a redirect to HTTPS, but didn’t check that it was to the correct domain.

Re: Valve and HackerOne: how not to handle vulnerability reports

#37

Post by _jal »

vntok wrote: post #20
tcd wrote: post #7

Just drop a line on twitter saying you've discovered a vulnerability in $popularSoftware and mention $company. Say you'll be disclosing in 90 days if $company doesn't issue a reply publicly. Make sure to deal with an actual human and that everything is done according to best practice. You may even get publicity this way and even if it's unethical it can be sold or used to your advantage. If they care, trust me when I…

> Say you'll be disclosing in 90 days if $company doesn't issue a reply publicly. That's blackmail. An expedient way of getting your door breached.

A lovely example of why one shouldn't take legal advice from message boards.

But I would say that if you're doing this sort of thing for the first time, I would strongly advise you to talk to a lawyer who knows this corner of the law, and to someone who has done this before.

Smarts do not substitute for experience and domain-specific knowledge.

Re: Valve and HackerOne: how not to handle vulnerability reports

#38

Post by user5994461 »

Saaster wrote: post #25

Companies receive so many "First, you have to be on the other side of this airtight hatch, then you..." reports that anything that looks even remotely like it will just get summarily closed. My personal favorite ones start with some form of "I copied the user's cookies from device A's file-system, and..." Just some suggestion on how to report these kind of things, because there is an actual underlying issue here wort…

Simply say that there is a typo in the steam configuration, it is connecting to the (insecure) URL http://...

This allows steam network traffic to be intercepted. It can be fixed by correcting the URL to https.

For example, somebody using steam from a coffee shop could have his credentials/cookies/accounts intercepted by the coffee shop operator or any other visitor.

I believe coffees and other gaming venues are a supported use case for steam and you do not wish to leave your users at risk.

IMO There is really no need to blow this out of proportion. It's just a typo. Developers make typos all the time. Bet they're more likely to double check something trivial like that if pointed to.

Re: Valve and HackerOne: how not to handle vulnerability reports

#39

Post by Twirrim »

dlgeek wrote: post #2

HackerOne started with such promise, but stories like this keep coming out. It makes you wonder how many people were even more patient than OP. Unfortunately, despite all the HackerOne claims, it still seems to take public disclosure and embarrassment to make companies actually take things seriously. Seems sunlight is still the best disinfectant.

> HackerOne started with such promise, but stories like this keep coming out. It makes you wonder how many people were even more patient than OP.

To state the probably obvious, remember that primarily what you see are the negative interactions. You're unlikely to see many posts about the positive interactions. People don't tend to post so much when things go as expected, they do when they go wrong.

Re: Valve and HackerOne: how not to handle vulnerability reports

#40

Post by gnfargbl »

minitech wrote: post #36
gnfargbl wrote: post #33

Earlier quoted context omitted.

So in a nutshell, could we summarise the issue here as "Valve didn't use TLS and thus Valve's users are vulnerable to the exceptionally well-known consequences of not using TLS?" If so, then... okay, but I don't know what the blog author was expecting when he reported this. Pointing out that HTTP has MiTM possibilities is kind of up there with pointing out that the sky is blue. If, in 2020, a site has made the choice…

It was an oversight. They had HTTPS support. Going by the bug report, the client checked for a redirect to HTTPS, but didn’t check that it was to the correct domain.

OK, that's a little more understandable. I assume that the initial use of HTTP is an intentional tactic that Steam uses to discover whether it is behind a captive portal or similar. That being the case then yes, the Steam client shouldn't rely on the data returned from the HTTP request, and this seems like a bug.
Post reply on HN