3 ms·

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

> 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 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://en.wikipedia.org/wiki/IP_address_spoofing * https://www.techopedia.com/definition/4020/masquerade-attack https://www.techopedia.com/definition/4020/masquerade-attack

infogulch 7y ago
> 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.

infogulch 7y ago

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