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

51–60 of 162 posts

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

#51

Post by aasasd »

baby wrote: post #47
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.

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 blo…

Yeah, as far as I understand the entire model of HackerOne is that it's a first-line force for the security team, just like an outsourced support. And the first line tends to be cheap instead of well-trained.

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

#52

Post by mtlynch »

michaelt wrote: post #42
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…

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

Plaintext HTTP in itself isn't a vulnerability.

Suppose that Steam ran some kind of load balancing server at http://loadbalancer.steam.com (no TLS). Its only job is to respond to HTTP GET requests with the URL of the least-busy steam server like "https://a.store.steampowered.com" or "https://b.store.steampowered.com".

If the mobile client makes the request to the load balancer over plaintext HTTP and then verifies that the response has the steampowered.com domain and is https:// then that's not a vulnerability, despite the fact that an attacker can MitM the plaintext HTTP part.

I would recommend that Steam just do everything over HTTPS for the sake of defense in depth, but I definitely wouldn't award a bounty to someone for proving they could MitM my load balancer and cause no damage. The worst the attacker can do in that scenario is cause the app to see network failures (specifically, TLS handshake failures), but if the attacker is middling traffic, that's possible regardless.

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

#53

Post by contravariant »

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…

That first sentence is a trainwreck but the steps that follow do at least clearly outline the issue.

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

#54

Post by XMPPwocky »

iancarroll wrote: post #44
jtylr wrote: post #17

Earlier quoted context omitted.

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.)

Yup. Have dozens of issues reported to security@, and responsiveness was great- usually human response same day, often in hours. H1 is veeeery slow by comparison, but, hey, I've made five figures off it so...

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

#56

Post by lucideer »

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…

I'm not a security expert. I am a software engineer; as such make it my responsibility to understand something of network security, but I have no formal training in such and I don't work in a specifically security-focused role. Nor do I work for an explicitly security-focused company.

I understood the issue clearly on first read.

You're absolutely right that it could have been explained more clearly, and that there is some ambiguity in the wording (not everyone's a perfect communicator). But if I (a very normal, non-security-focused software engineer) can grok this, it's the absolute least I would expect from someone working for HackerOne! Their entire job is to be able to understand this sort of thing in depth.

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

#57

Post by dsl »

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…

I've been on both sides of this, and sadly having HackerOne/BugCrowd as intermediaries often hurts more than it helps.

On one hand I've had to sort through the never ending stream of "if you bypass the safeguards first" issues and some guy in India copying and pasting open source vuln scanner reports. I get why people don't want to deal with this and outsource it.

On the other hand, I have a legitimate exploit against GitHub that is "working as intended" for months now. No amount of back and forth is going to convince them that leaking commit messages on enterprise accounts is serious apparently.

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

#58

Post by notwedtm »

mtlynch wrote: post #52
michaelt wrote: post #42

Earlier quoted context omitted.

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

Plaintext HTTP in itself isn't a vulnerability. Suppose that Steam ran some kind of load balancing server at http://loadbalancer.steam.com (no TLS). Its only job is to respond to HTTP GET requests with the URL of the least-busy steam server like " https://a.store.steampowered.com" or " https://b.store.steampowered.com" . If the mobile client makes the request to the load balancer over plaintext HTTP and then verifies…

There could also be a captive portal check going on.

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

#59

Post by djsumdog »

michaelt wrote: post #42
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…

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

I immediately understood what he was saying right from the start. He even mentions there is an eventual https redirect, but the app should start with the https request!

I've got about 20 years of experience as a software dev. I probably would have written it differently, but at the same time .. I fully understood what he was saying immediately. There's nothing difficult to understand there.

We're never even talking about HSTS or certificate pinning. We're just talking about the very first call from the mobile app to their website/api.

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

#60

Post by DyslexicAtheist »

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…

> even if it's unethical

it wouldn't even be unethical. responsible disclosure starts with engaging with company at eye-level. all that these bug bounty platforms do is take away exactly this power and allow the company to consolidate the contract to a single entity (e.g. preferred supplier). they deserve even less respect than any shady recruiter or typical outsourcing sweat-shop.

giving these people power is like talking to a cop without a lawyer - regardless of what they say, they don't have your interest in mind and you have lost before the game has even started.

Post reply on HN