Live data from Hacker News

Valve and HackerOne: how not to handle vulnerability reports

blog.jakegealer.me

41–50 of 162 posts

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

#41
post #20
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.

In the US, Blackmail requires a benefit in exchange for not disclosing information.

A public reply isn't much of a benefit, and my understanding is that the vulnerabilities will be disclosed eventually within a reasonably limited timeframe.

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

#42
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…

> I think the author is partially at fault for repeatedly failing to communicate the issue clearly.

I disagree. The first sentence of the report includes "HTTP", "man in the middle attack" and "store.steampowered.com"

If that isn't clear to someone, they are not sufficiently trained to triage vulnerability reports. You simply cannot do that job right if you need the attacker to hand-walk you through the difference between HTTP and HTTPS and why you would use the latter for an online store.

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

#43
I don't get the "this issue is a duplicate so we won't pay" business. If I find a serious issue that's still unpatched and someone tells me "Ops it's a duplicate sorry!" I'm still going to ask for payment. If I don't get it, it's a given that I'm going public - assuming it is legal to do so -. Why doesn't everyone do that?

I'll go even further and say that price negotiation should happen at every disclosure. If you're not satisfied with the price you're getting, go ahead and make the vulnerability public ASAP - assuming it is legal to do so -. It's about time companies that have invested nothing in security compared to their profits and their parasitic middlemen like HackerOne acquire proper incentives. Right now, they are getting away with having the public subsidize their security procedures AT MASSIVELY REDUCED costs. This has to stop.

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

#44
post #17

Earlier quoted context omitted.

any other sources?

Only anecdotal, I once tried to report a persistent XSS issue on the game "hub" pages. After weeks of going back and forth with support (this was before the likes of hackerone) the ticket was closed and the issue was ignored.

On the other hand, before they started moving to HackerOne, they fixed several issues I reported either the next day or within a week or so. Their security@ was incredibly responsive.

Now it seems it takes forever (I have reports waiting to be paid from them too, even ones they have already fixed.)

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

#45
post #18

Wait steam client does not even use https??

If I read it correctly, the mobile app first connects to the store page on http, which then gets redirected to the https version by their server. So probably a typo / misconfiguration in the app. The store itself uses https everywhere. If you intercept the first request you can display whatever you want to the user tho.

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

#46
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…

[deleted]

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

#47
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.

I think what you’re all missing is the asymmetry that most bug reports are bad. If you understand this then you understand that hackerone has respected its promises to companies hiring them: they perform the first set of triage. With the number of reports they are going through, the number of bad stories we’re hearing about them is pretty abysmal.

I feel like it’s the same with any type of bad news, it can easily blow out of proportion and wrongly indicate that things are going very very badly. I guess this is why the news are addicted to shocking and breaking news.

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

#48

How is that vulnerability? If the ISP DNS gets hacked people can intercept traffic. Seriously this is the best attack scenario he could come with with? From what I understand. It seems the steam app is connecting to plain http http://store.steampowered.com/ so it could be man in the middled. Unless I am missing something, it's way overblown. Valve please fix the URL to https and send that guy a $50 Amazon voucher.

> If the ISP DNS gets hacked people can intercept traffic.

Usually machines will follow the DNS server they get from DHCP. You don't have to hack an ISP DNS, just have control over the router the user is connected to.

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

#49
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…

> I think the author is partially at fault for repeatedly failing to communicate the issue clearly. I disagree. The first sentence of the report includes "HTTP", "man in the middle attack" and "store.steampowered.com" If that isn't clear to someone, they are not sufficiently trained to triage vulnerability reports. You simply cannot do that job right if you need the attacker to hand-walk you through the difference be…

Do note that mtlynch is not saying that it's all the authors fault and Valve/HackerOne couldn't handle this better.

What you've written can be true as at the same time, what mtlynch has written is true too. Everyone could do better here.

But most likely, giving feedback to Valve/HackerOne via a Hacker News thread is likely to not be read. The feedback to the author is more likely to be read by the author themselves and other aspiring penetration testers.

So in the end, everyone could have done better.

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

#50
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…

> I think the author is partially at fault for repeatedly failing to communicate the issue clearly. I disagree. The first sentence of the report includes "HTTP", "man in the middle attack" and "store.steampowered.com" If that isn't clear to someone, they are not sufficiently trained to triage vulnerability reports. You simply cannot do that job right if you need the attacker to hand-walk you through the difference be…

Respectfully disagree with this one. We don't even have a bounty program, and we get at least 10 non-issues for every actual potentially exploitable report.

I can definitely see someone reviewing this and accidentally putting it in the "not a problem" bucket. From our perspective, the best vulnerability reports look like:

"This potential exploit can crash your node"

"This potential exploit can steal user funds"

Etc.

It really helps us filter through the nonsense reports we get.

Post reply on HN