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

141–150 of 162 posts

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

#141

Post by tptacek »

austincheney wrote: post #136
tptacek wrote: post #134

Earlier quoted context omitted.

"The vulnerability is that an attacker can perform a MITM attack by spoofing an HTTP request pretending to be from store.steampowered.com". The blog post writeup isn't the best in the world, but the actual H1 submission seems fine.

If the traffic is redirected using a reverse proxy at what point does that traffic reach the intended destination? It doesn't. It reaches the impostor destination. In order for a MITM attack to occur the attacker must establish trust with both end points, which isn't happening in this case.

Oh, I see the point you're making. Yeah, that's true. Sorry!

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

#142

Post by imtringued »

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…

No, the problem is that HackerOne isn't actually a "Bug Bounty as a Service" company. It's a "Cover Corporate Asses as a Service" company. They don't care if they don't understand your vulnerability. Their primary value add is that their customers can stick their heads into the sand and still create the impression that their software has no security flaws. What happens is that HackerOne forces security researchers into one specific workflow. They have an incentive to close as many bug reports as out of scope to avoid paying a bounty. There is no incentive to have qualified staff that actually have the technical background knowledge to determine if your report is actually a security problem or not. The fact that reporters have to create a hackerone account means that HackerOne can ban you from their platform and you automatically lose the ability to report bugs for other companies. What often happens is that they simply ignore your report and try to pretend that it never existed in the first place. When the reporter decides that public disclosure is the the path of last resort then HackerOne will respond immediately and blame the reporter for not following the HackerOne workflow and ban the account of that reporter.

The fact that Valve decided to pay money to this company implies that they don't care about security. You can't blame them for not fixing the vulnerabilities when HackerOne is interfering heavily in the process but you can blame Valve for knowingly choosing a company with a horrifyingly bad track record.

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

#143

Post by imtringued »

restingrobot wrote: post #75
kbenson wrote: post #73

Earlier quoted context omitted.

store.steampowered.com is a fully web accessible site with a CA signed certificate though. It's the main steam marketplace. I think the whole point is that they are leveraging this for their app, so using a self-signed CA doesn't make a lot of sense in that case (not that I'm sure it ever would for a company these days, SSL certs are cheap).

I don't think you understand. There is no such thing as a "self-signed" CA cert, (its one or the other). This not about money, it's about control. There are many benefits to using a self-signed SSL cert over purchasing a CA one. However, Apple and Android inherently distrust self-signed certs so you have to actually provide the cert directly to ATS/Android OS which involves bundling it within the app, (a messy proces…

You can create your own CA and then add it to the trust/keystores of your applications. It's exactly the same thing that public CAs are doing. They strike a deal with browsers and operating systems and get added to those stores.

There is a lot of software that assumes that all connections signed with a given CA are trusted. You wouldn't want to use a public CA in that case because random people could access your services. Want to encrypt mongodb traffic? Create your own private CA. Want to encrypt zookeeper (or etcd for kubernetes) traffic? Create your own private CA. Each server and client gets its own certificate signed with that private CA and since only that private CA is marked as trusted it can be used to authenticate servers and clients. It's basically the same idea as if you had a cryptographically signed token such as JWT. (the private key of the CA is the shared secret)

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

#144

Post by imtringued »

munk-a wrote: post #81
aasasd wrote: post #51

Earlier quoted context omitted.

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.

Eeeh, I think that's a false assumption - it may in fact be the case but specialized first line teams like this don't need to be cheap, they can instead work the margins and be economical by being focused. Not every company is going to have a full security team, so it does make some sense to try and pool those resources into one specialist company that serves the first line triage needs of a bunch of other companies.

Yeah, it should be the opposite. HackerOne should have a pool of experts that small companies wouldn't be able to afford and large companies don't have to hire security experts that sit idle most of the time.

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

#145

Post by jrockway »

This HackerOne thing seems weird. It's like they looked at Google and decided "let's apply their customer service, but for security researchers." With this model, things like this blog post inevitably follow -- including the "they ignored me until I complained on Twitter, then they instantly fixed it". (Classic.)

I took djb's "Unix security holes" class in 2004 and he advocated for just disclosing the security hole immediately, things like this haven't changed my mind. I know people want the money, but it's peanuts and doesn't seem worth the hassle unless you're really young. Nobody is going to spend months looking for obscure bugs for $10,000 when they could get paid that in a week to write the bugs (accidentally) in the first place.

It all makes very little sense to me. If you care about security, you'll have a team like Project Zero. Anything else is just applying the "gig economy" to engineering work, and the results are pretty predictable. It's kind of sad.

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

#146

Post by oarsinsync »

mtlynch wrote: post #116
djsumdog wrote: post #62

Earlier quoted context omitted.

No. No. No. No! Everything about this is wrong. The load balancer ABSOLUTELY should be HTTPS only and all request from the app, from the very first request, should be over HTTPS. If you want more security, add Strict Transport security as well as certification pinning in the app. But at a very basic level, there is absolutely no excuse for this app to making HTTP plain-text requests to steam at all. In your example,…

> In your example, I could setup a free Wi-Fi hotspot with a different DNS entry for http://loadbalancer.steam.com , have it go to my local ngixn server with a page that looks exactly like Steam's login, capture their user credentials, and then redirect them to actual Steam. Sorry, I don't think I communicated my hypothetical app clearly. Imagine the sequence is like this: 1. App makes a background HTTP request to ht…

> If you replaced it with anything but a https://*.steampowered.com, the app would refuse to load the URL, so I don't see the vulnerability.

I’m going to take this as what the intention was when designing this solution.

> 3. App verifies that the domain ends with "steampowered.com" and starts with "https://"

I’m going to take this to be what would have actually been coded in this solution.

I’m now going to register notsteampowered.com, and bypass the bug in the code to deliver an exploit over https.

This solution is fragile. Why not just do the whole thing over TLS to begin with and avoid this vulnerability in the first place?

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

#147

Post by austincheney »

infogulch wrote: post #140
austincheney wrote: post #135

Earlier quoted context omitted.

> 2. The App fails to validate that it is actually communicating with The Store by not using https That is the software defect, and that alone. Everything else is completely working as designed even if the results not expected. That does not rise to the level of a MITM. > 3. Thus, an attacker with control of an external network (e.g. a coffee shop wifi) can "secretly relay and possibly alter the communication between…

> That does not rise to the level of a MITM. You're not gaining any ground by claiming the existence of "levels" of MITM. A MITM vulnerability is failing to validate who you're communicating with. The Steam App did this. Thus Steam is vulnerable to a MITM attack. > In that scenario the store would never believe it is talking with one of its user's because the traffic was relayed to an alternate location. Therefore it…

> The Steam App did this.

It did not, because it cannot validate what it does not have. The reverse proxy in question redirects traffic away from the server to an unrelated location. As such there is nothing for the server to validate since the user traffic is somewhere else.

> Thus Steam is vulnerable to a MITM attack.

The traffic did not go through the attacker to the intended end point. It just went to the attacker.

> I don't understand what this means?

Impersonation is pretending to be somebody else. MITM is more than impersonation in that it must fool both end points, not just the user, of the connection.

> The Store (store.steampowered.com) believes that the user is anyone who can produce the user's credentials.

You are insinuating a replay attack, but there is no evidence of a replay attack. In a replay attack one end of the communication sends a message and an intercepting attacker replays the message for the distant end.

https://en.wikipedia.org/wiki/Replay_attack

Literally all that happened is that the attacker intercepted traffic and redirected it to a different location that is not the intended server. That is IP address spoofing, which is bad but far less bad because its easy to find if you looking for it. For this to be a MITM the attacker would have to intercept the traffic and route it to the intended server. MITM attacks are severe, because they are very challenging to detect since both end points believe the attacker is their intended end point and both end points are exchanging data without indication that trust is violated.

* https://en.wikipedia.org/wiki/IP_address_spoofing

* https://www.techopedia.com/definition/4020/masquerade-attack

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

#148

Post by austincheney »

fulafel wrote: post #120
austincheney wrote: post #118

Earlier quoted context omitted.

Since I see people on HN get this wrong more than 90% of the time I want to demystify the term Man in the Middle . https://en.wikipedia.org/wiki/Man-in-the-middle_attack The Wikipedia article's description is correct. MITM is a cryptographic attack where an impostor is performing certificate interception and so relays encrypted traffic. MITM is not merely listening to just any traffic. If the violation occurred over…

You are contradicting thr WP description, there is no cryptography required to meet the definition: "In cryptography and computer security, a man-in-the-middle attack (MITM) is an attack where the attacker secretly relays and possibly alters the communications between two parties who believe that they are directly communicating with each other" The WP definition is the commonly accepted one too, not a case of WP gett…

> "In cryptography and computer security, a man-in-the-middle attack (MITM) is an attack where the attacker secretly relays and possibly alters the communications between two parties who believe that they are directly communicating with each other"

If the attack is redirecting traffic away from the server at what point does the server believe it is communicating with the user? The server cannot validate the user traffic since it does not have it.

> The WP definition is the commonly accepted one too, not a case of WP getting it wrong.

That is the opposite of what I said.

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

#149

Post by peterangular »

mtlynch wrote: post #116
djsumdog wrote: post #62

Earlier quoted context omitted.

No. No. No. No! Everything about this is wrong. The load balancer ABSOLUTELY should be HTTPS only and all request from the app, from the very first request, should be over HTTPS. If you want more security, add Strict Transport security as well as certification pinning in the app. But at a very basic level, there is absolutely no excuse for this app to making HTTP plain-text requests to steam at all. In your example,…

> In your example, I could setup a free Wi-Fi hotspot with a different DNS entry for http://loadbalancer.steam.com , have it go to my local ngixn server with a page that looks exactly like Steam's login, capture their user credentials, and then redirect them to actual Steam. Sorry, I don't think I communicated my hypothetical app clearly. Imagine the sequence is like this: 1. App makes a background HTTP request to ht…

This is an insanely flawed design and the responses to it are 100% factually correct in their assessment. loadbalancer.steampowered.com could still respond with a bad entry just as long as it fits the "https://*.steampowered.com" pattern.

If the application does some sort of SSL pinning you may have to MITM the handshake but that's not outside of the realm of possibility for a sophisticated attacker.

I know it's just an example of how something COULD work but I strongly disagree that the following is correct:

> The worst the attacker can do in that scenario is cause the app to see network failures

Also - it's worth noting that all of this DNS talk really makes the whole SSL discussion moot. This is exactly why things like DNSSEC exist. If I'm able to point your traffic wherever you're done.

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

#150

Post by [deleted] »

tptacek wrote: post #124
mtlynch wrote: post #116

Earlier quoted context omitted.

> In your example, I could setup a free Wi-Fi hotspot with a different DNS entry for http://loadbalancer.steam.com , have it go to my local ngixn server with a page that looks exactly like Steam's login, capture their user credentials, and then redirect them to actual Steam. Sorry, I don't think I communicated my hypothetical app clearly. Imagine the sequence is like this: 1. App makes a background HTTP request to ht…

1. Nobody competent would do this in a modern design. 2. Any security engineering team would flag this design. 3. Allowing https:// (anything) .steampowered.com / (anything) allows for arbitrary redirection into any property under that domain, some of which could be user (or customer) controlled. Does that matter on this domain? Who cares? Why have a design where you even have to ask? The first contact with the load…

[deleted]
Post reply on HN