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.
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.
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.
In my opinion, in the case of security, I think a False Negative should weigh a lot, and thus measures to prevent it should be in place (i.e. not having an intern mindlessly looking through issues and sorting them into buckets).
Of course, the cost of each will depend on your app/company, its industry, its size, and so on.
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.
Additionally the person at hackerone did ask for some clarification around the issue, that's great as it is helping with identification but probably also needs to encompass expressing the problem to make it clearer to read.
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 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.
This incident is just a software defect rather than a security violation from the unexpected use of a reverse proxy: https://en.wikipedia.org/wiki/Reverse_proxy
An unsupported reverse proxy was only possible because the site was transmitting over HTTP instead of HTTPS.
> If that isn't clear to someone
It isn't clear merely because you used the scary term: MITM. A trained security professional performing triage would devalue the security ticket pending further investigation.
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. The "requires physical access" thing seems pretty obviously to be a misapplication of the H1 scope.
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 blog post writeup isn't the best in the world, but the actual H1 submission seems fine.
In order for a MITM attack to occur the attacker must establish trust with both end points, which isn't happening in this case.
"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 getting it wrong.
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.
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...
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 you linked to seems to disagree with you). And this seems a little like saying that you wouldn't be concerned about a privilege-escalation attack since you're inadvertently running everything as root.
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.
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. 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"
I don't know how this could be any less than the definition of a MITM by wikipedia's own standard. That this kind of attack is also related to cryptography is immaterial to the fact that a reverse proxy is a MITM. It doesn't somehow make it not MITM because they weren't using any cryptography, it means that they failed to implement a protocol that sufficiently protects against MITM.
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.
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.
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
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.
e.g. OWASP: https://owasp.org/www-community/attacks/Man-in-the-middle_at...
It only lists one example about key exchange. That is different than certificate exchange, but not for the point of this conversation.
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.
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, 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.
You can't just have a plain text load balancer redirect to https because someone else can intercept you BEFORE that redirect takes place.
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 http://loadbalancer.steam.com
2. Load balancer responds with a URL string like "https://a.steampowered.com"
3. App verifies that the domain ends with "steampowered.com" and starts with "https://"
4. If verification passes, app loads the response URL in the in-app browser
In that case, replacing http://loadbalancer.steam.com with a spoofed page doesn't do anything because the app's internal logic sees the response, not a human user. 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.
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 balancer should be HTTPS.
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.
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.
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.
DoH: different story.
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 ;)
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?
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.
One would still need a justification for that design IMHO, but I don't think it is vulnerable to what you describe.
Immediate things I worry about are around URL parsing.
Is evil.com<insert something here>steampowered.com going to pass as "steampowered.com" when it isn't? Will it handle punycode? All sorts of shit can go wrong when parsing a URL, and it's a real world problem when people implement the mitigation you're describing[0].
https://labs.detectify.com/2016/07/27/how-i-made-lastpass-gi...
This is just for starters. I think if I were being paid to think about it I'd probably be able to come up with some more. Can I mess with DNS? Can I inject some other malicious payload into the page, to take advantage of other vulns? etc etc etc
I would be extremely wary of this technique as a real boundary rather than just an assertion in code.
But you're trading an easy solution (only use https://) for several points of failures (validate potentially untrusted input all along the chain).
> verifies that the response has the steampowered.com domain
An attacker is going to look for any exploits on steampowered.com (open redirect, xss, etc.). So now your domain name check is insufficient, you also need to make sure that all of steampowered.com is secure (which, odds are, is managed by multiple teams).