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

131–140 of 162 posts

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

#131

Post by austincheney »

tptacek wrote: post #123
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…

I do not understand the distinction you are trying to make. MITM has nothing in particular to do with certificates, and describes any attack in which Alice Bob, cryptographically or otherwise, and Mallory intercepts and controls communications via Alice Mallory Bob. Essentially every malicious proxy attack is a MITM. The bug here seems to be that the Steam local app relies on an HTTP 80/tcp connection for first conta…

> The bug here seems to be that the Steam local app relies on an HTTP 80/tcp connection for first contact with Steam's backend. That's a legit finding.

I agree that it is a valid finding, but its reported in wildly different terms than what you just described. That is just cause to triage a reported incident as low priority.

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

#132

Post by austincheney »

tgb wrote: post #130
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…

> If the violation occurred over port 80 its a safe bet there is no man in the middle attack. If I were doing security triage and I saw "man in the middle" and anything about HTTP or port 80 I would not consider this a priority ticket. Can you explain this more? Are you just arguing that it's unencrypted and therefore by definition not MITM? I'm skeptical that this is common usage of the term (the Wikipedia article y…

> Are you just arguing that it's unencrypted and therefore by definition not MITM?

That is exactly what I am saying for 2 reasons.

1. If the connection is HTTP instead of HTTPS there is no trust. MITM is trust violation attack, which cannot be present if there is no trust to attack.

2. All kinds of software and hardware redirect traffic under normal operating conditions. That isn't a MITM merely because the path of traffic, or even the end point, is different than expected. For instance a load balancer could route you from an expected location to different physical data center, which is a completely different end point both physically and logically but its not necessarily an attack if you are still where you want to be and both end points trust each other.

The reason why trust is available with HTTPS and not HTTP isn't even because the pipe is encrypted, but because HTTPS uses certificates and HTTP does not. MITM is all about a trust violation. Certificates are not required with HTTPS, but your browser yells at you when a certificate is absent or untrusted.

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

#133

Post by austincheney »

detaro wrote: post #121
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…

The wikipedia article you cite as evidence lists several examples where no cryptography is involved as MITM attacks. As do many other sources. e.g. OWASP: https://owasp.org/www-community/attacks/Man-in-the-middle_at...

> The wikipedia article you cite as evidence lists several examples where no cryptography is involved as MITM attacks.

It only lists one example about key exchange. That is different than certificate exchange, but not for the point of this conversation.

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

#134

Post by tptacek »

austincheney wrote: post #131
tptacek wrote: post #123

Earlier quoted context omitted.

I do not understand the distinction you are trying to make. MITM has nothing in particular to do with certificates, and describes any attack in which Alice Bob, cryptographically or otherwise, and Mallory intercepts and controls communications via Alice Mallory Bob. Essentially every malicious proxy attack is a MITM. The bug here seems to be that the Steam local app relies on an HTTP 80/tcp connection for first conta…

> The bug here seems to be that the Steam local app relies on an HTTP 80/tcp connection for first contact with Steam's backend. That's a legit finding. I agree that it is a valid finding, but its reported in wildly different terms than what you just described. That is just cause to triage a reported incident as low priority.

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

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

#135

Post by austincheney »

infogulch wrote: post #128
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…

> 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. - Wikipedia on MITM 1. The steam client ("The App") thinks that it's communicating with Valve Inc. via store.steampowered.com ("The Store") 2. The App fails to validate that it is actually communicating with The Store by not using https 3.…

> 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 The App and The Store who believe they are communicating with each other"

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 its an impersonation and not a MITM.

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

#136

Post by austincheney »

tptacek wrote: post #134
austincheney wrote: post #131

Earlier quoted context omitted.

> The bug here seems to be that the Steam local app relies on an HTTP 80/tcp connection for first contact with Steam's backend. That's a legit finding. I agree that it is a valid finding, but its reported in wildly different terms than what you just described. That is just cause to triage a reported incident as low priority.

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

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

#137

Post by ngold »

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…

Thank you. This was a bit confusing. It helped that this was the first paragraph.

>This is my first blog, but I felt like this is something I needed to get off my chest after months. If people enjoy this blog post, I will probably do more in the future.

I'm sure this blog will probably learn a hard and fast lesson on writing thanks to your post. This can't be any easy topic to explain. You did a solid job, thank you again.

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

#138

Post by driverdan »

bllguo wrote: post #125
hmage wrote: post #32

Earlier quoted context omitted.

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.

but do they trumpet on twitter that they have an exploit and will release it in 90 days? that's the difference

They have a public issue tracker (issues are withheld from public for 90 days): https://bugs.chromium.org/p/project-zero/issues/list

and a blog: https://googleprojectzero.blogspot.com/

and a Github org: https://github.com/googleprojectzero

and their members do tweet about their findings on their personal accounts.

But no, they don't have an official Twitter account.

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

#139

Post by MaxBarraclough »

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

I don't follow. That's quite obviously not a proper fix.

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

#140

Post by infogulch »

austincheney wrote: post #135
infogulch wrote: post #128

Earlier quoted context omitted.

> 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. - Wikipedia on MITM 1. The steam client ("The App") thinks that it's communicating with Valve Inc. via store.steampowered.com ("The Store") 2. The App fails to validate that it is actually communicating with The Store by not using https 3.…

> 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 its an impersonation and not a MITM.

I don't understand what this means? The Store (store.steampowered.com) believes that the user is anyone who can produce the user's credentials. The App represents the user by holding the user's credentials. The App tries to connect to The Store and believes that the world is thus: The App -> The Store. But The App fails to validate this and can be tricked into the world where: The App -> Attacker -> The Store (this is the MITM). The Store never has any more information than 'Someone with The User's credentials is connecting': Someone (with User's credentials) -> The Store. The Store's picture of the world is identical in both cases, it cannot distinguish a true user from an attacker if both have the user's credentials. This doesn't have anything to do with The Store and everything to do with The App.

Post reply on HN