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

151–160 of 162 posts

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

#151

Post by infogulch »

austincheney wrote: post #147
infogulch wrote: post #140

Earlier quoted context omitted.

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

> MITM is more than impersonation in that it must fool both end points, not just the user, of the connection.

You are correct, this particular implementation of the attack did not demonstrate MITM directly. But it did successfully demonstrate that a MITM attack was possible, because MITM directly follows from the client not validating the authenticity of the server. The fact that this implementation displayed their own page instead of proxying store.steampowered.com and logging the requests is utterly immaterial to vulnerability's viability as a tool for a MITM attacker.

If you're saying that this is not a MITM vulnerability because the vulnerability demo loaded their own page instead of Valve's... well that's a stupid argument, and it doesn't refute anything about the client application being vulnerable to MITM.

> You are insinuating a replay attack

I am not. The statement "The website believes that the user is anyone who can produce the user's credentials." is a universal truism that applies to every service ever created. This has nothing to do with replay.

> Literally all that happened is that the attacker intercepted traffic and redirected it to a different location that is not the intended server.

So literally all that server would have to do is respond with the actual html content from the store, and suddenly you would change your mind about whether this effectively demonstrates a MITM vulnerability? Your arguments are not making sense.

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

#152

Post by mtlynch »

oarsinsync wrote: post #146
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…

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

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

Yeah, that's a good point. That's my mistake in spitballing, but the vulnerability wouldn't exist in an implementation that properly checked the domain.

Again, I 100% agree with you that it's fragile and not a good idea. I wouldn't design a system this way, and I would flag it if I reviewed an app that did this. I was just objecting to the idea that the discovery of any plaintext HTTP request is a bounty-worthy vulnerability.

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

#153

Post by mtlynch »

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…

Hey Thomas, you actually kind of started me in web app security. You interviewed me for Matasano, and when I told you I didn't have experience with web apps, you overnighted me a copy of The Web Application Hacker's Handbook. You ultimately made me an offer, but after difficult deliberation, I ended up joining iSEC. Thanks again for sending me the book! It's been tremendously helpful.

I 100% agree that people shouldn't design systems this way, and if I were still a pentester, I'd write it up if I found it. But if the implementation correctly checked the domain and verified it was https:// (and maybe did some cert pinning), I couldn't justify anything higher than low severity.

We've kind of gone way into the weeds on my made up example, but it was initially in response to this:

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

I just disagree with the idea that any plaintext HTTP request in an app inherently is a vulnerability.

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

#154

Post by tptacek »

mtlynch wrote: post #153
tptacek wrote: post #124

Earlier quoted context omitted.

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…

Hey Thomas, you actually kind of started me in web app security. You interviewed me for Matasano, and when I told you I didn't have experience with web apps, you overnighted me a copy of The Web Application Hacker's Handbook. You ultimately made me an offer, but after difficult deliberation, I ended up joining iSEC. Thanks again for sending me the book! It's been tremendously helpful. I 100% agree that people shouldn…

What a nice comment! And in a thread where I am definitely not at my best (it's been an allergy migraine kind of day). This made my evening; thank you. iSEC was a great team!

I'm more of an absolutist about HTTPS than you are, though. :)

I feel like every once in awhile I need to plow face-first into the brick wall of a friendly comment like this just as a signal to dial it back a bit. It's been a challenging couple weeks. I'll dial it back a bit! Thanks again.

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

#155

Post by britmob »

kaibee wrote: post #14

I know barely anything about encryption, but this reads to me like the parties involved don't understand that public key cryptography defeats MITM attacks (at least as I understand it)?

The vulnerability is that there was no public key encryption, hence allowing a MiTM to redirect the steam app to their own site.

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

#156

Post by tptacek »

peterangular wrote: post #149
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…

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

No, not at all: the same LAN access that allows him to spoof DNS also allows him to spoof the authenticated-data bit in the DNS header to bypass DNSSEC. This is one of the great failings of DNSSEC.

DoH: different story.

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

#157

Post by fulafel »

austincheney wrote: post #148
fulafel wrote: post #120

Earlier quoted context omitted.

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

My comment was just on the misconception of what MITM is.

That being said, I do think the article's documented report clearly demonstrated how the app was vulnerable to MITM even if the PoC didn't implement the attack all the way. And as a word of advice to the vendor, you probably don't want to train all your well meaning vulnerability researcher pals to productise their vulnerability PoCs into production quality exploits, lest they get the temptation to sell them on other types of markets...

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

#158

Post by cwillu »

vageli wrote: post #102
MaxBarraclough wrote: post #21

Earlier quoted context omitted.

The software is vulnerable to a MITM attack. There's no reason it should be.

Frankly, I'm surprised the site didn't respond with a 302 redirect to SSL to avoid this kind of thing entirely (versus relying on client to specify the correct protocol).

The client _must_ use the correct protocol, that's precisely the issue.

An insecure request to switch to a secure protocol would just be elided by an attacker. If the client is coded to expect such a switch and fail if it doesn't happen, that client is at best implementing a more complicated, ad-hoc secure protocol.

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

#159

Post by peterangular »

tptacek wrote: post #156
peterangular wrote: post #149

Earlier quoted context omitted.

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

No, not at all: the same LAN access that allows him to spoof DNS also allows him to spoof the authenticated-data bit in the DNS header to bypass DNSSEC. This is one of the great failings of DNSSEC. DoH: different story.

I'm prefacing this with I'm VERY new to DNSSEC (apologies).

I guess I always assumed that DNSSEC would blow up when changing the destination of the point but have never really dealt with may DNSSEC rollouts outside of light maintenance.

Thanks for a great response, I'm going to formally learn on DNSSEC because this is a good flag that I need better understanding. Also DoH is a new topic to me too so definitely going to "dig" on that as well ;)

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

#160

Post by mekane8 »

Reading stories like this really make me hate these customer service walls we've put up everywhere. Only a couple of times in these exchanges did it seem like there was a functioning, thinking human intelligence on the other end. All of the robo-responses are depressing, including the human-generated ones. And it's even more discouraging when you have to hear about their company's internal chaos and disorganization. Really gives me a low opinion of this HackerOne organization.
Post reply on HN