5 ms·

> MITM is an attack where the attacker secretly relays and possibly alters the communications between two parties who believe that they are directly communicati

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

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

austincheney 7y ago

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

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