3 ms·

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

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

fulafel 7y ago
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 getting it wrong.
- wizzwizz4 7y ago
  But here, there's no communication with store.steampowered.com. I mean, there could be— oh, yeah, getting it now. That's much worse than I thought it was; you could extract money from the account via gifts without even getting the user to re-enter their bank details.
- austincheney 7y ago
  > "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 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.
  - fulafel 7y ago
    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...
detaro 7y ago
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_attack https://owasp.org/www-community/attacks/Man-in-the-middle_at...
- austincheney 7y ago
  > 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.
tptacek 7y ago
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 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.
- austincheney 7y ago
  > 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.
  - tptacek 7y ago
    "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.
    - austincheney 7y ago
      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.
      - tptacek 7y ago
        Oh, I see the point you're making. Yeah, that's true. Sorry!
infogulch 7y ago
> 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.
tgb 7y ago
> 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 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.
- austincheney 7y ago
  > 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.

fulafel 7y ago

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 getting it wrong.

wizzwizz4 7y ago
But here, there's no communication with store.steampowered.com. I mean, there could be— oh, yeah, getting it now. That's much worse than I thought it was; you could extract money from the account via gifts without even getting the user to re-enter their bank details.
austincheney 7y ago
> "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 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.
- fulafel 7y ago
  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...

detaro 7y ago

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_attack https://owasp.org/www-community/attacks/Man-in-the-middle_at...

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

tptacek 7y ago

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

austincheney 7y ago
> 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.
- tptacek 7y ago
  "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.
  - austincheney 7y ago
    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.
    - tptacek 7y ago
      Oh, I see the point you're making. Yeah, that's true. Sorry!

infogulch 7y ago

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

tgb 7y ago

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

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