"That’s vulnerable to a man in the middle attack!"
You've probably heard this before, but let’s dive into the details of this attack and understand exactly how it works.
Definition
First, a quick definition, a man in the middle (MitM) attack is an attack where the communication which is exchanged between two users is surreptitiously monitored and possibly modified by a third, unauthorized, party. In addition, this third party will be performing this attack in real time (i.e stealing logs or reviewing captured traffic at a later time would not qualify as a MitM)
While a MitM could be performed against any protocol or communication, we will discuss it in relation to HTTP traffic in just a bit.
Requirements for Attack
A MitM attack can be performed in two different ways:
1. The attacker is in control of a router along the normal point of traffic communication between the victim and the server the victim is communicating with.
2.a. The attacker is located on the same broadcast domain (e.g. subnet) as the victim.
2.b. The attacker is located on the same broadcast domain (e.g. subnet) as any of the routing devices used by the victim to route traffic.
We will discuss 2a. This is a likely attack that can be used against your neighbors or the person sitting next to you at a coffee house.
The Attack
A MitM attack will take advantages of weaknesses in network communication protocols in order to convince a host that traffic should be routed through the attacker instead of through the normal router. In essence, the attacker is advertising that they are the router and the client should update their routing records appropriately. This attack is called ARP spoofing.
The (greatly simplified) purpose of ARP (Address Resolution Protocol) is to enable IP address to MAC address translations for hosts. This is required so that the packet can reach their final destined host. (see RFC 826)
By design, ARP does not contain authentication. Therefore, any host can reply to an ARP request or send an unsolicited ARP response to a specific host. These ARP response messages are used by the attacker to instruct the victim’s machine that the appropriate MAC address for a given IP address is now the MAC address of the attacker’s machine. More specifically, the attacker is instructing the victim to overwrite their ARP cache for the IP->MAC entry for the router. Now, the IP address for the router will correspond to the MAC address for the attacker’s machine.
What does this mean? Now, all of the victim’s traffic will be routed through the attacker. Of course, we don’t stop here. In order to allow the traffic to reach the Internet, the attacker must configure his system (or attack tool) to also forward this traffic to the original router. In addition, the attacker performs a similar ARP spoofing attack against the router. This way the router knows to send traffic, that was destined for the victim machine, to our attacker instead. The attacker then forwards on the traffic to the victim. This completes the “chain” and places the attacker “in the middle” of the communication.
Impacts on HTTP
At this point, the attacker has the ability to view and modify any TCP traffic sent to or from the victim machine. HTTP traffic is unencrypted and contains no authentication. Therefore, all HTTP traffic can be trivially monitored/modified by the attacker.
What about HTTPS?
Everything we have talked about thus far is related to getting in the middle of the network communications. This enables the attacker to view most exchanged data, but does not enable the attacker to intercept data exchanged of protocols that implement their own authentication and encryption (e.g. SSH, SSL/TLS)
But, this is where the fun starts. The purpose of HTTPS is to create a secure communication over top of HTTP by the use of SSL or TLS. On its own SSL/TLS can be very effective and secure. However, there are significant problems in the implementation of SSL/TLS which effectively renders it useless. In addition, the browsers handling of SSL/TLS can lead to issues when both HTTPS and HTTP sites are visited by the user.
More devious means are needed to perform a MitM against SSL/TLS. At this point the attacker could attempt to intercept HTTPS traffic by using a custom certificate. This would present a certificate warning message in the user’s browser and likely alert the user to the attack. Luckily for the attacker, most users would ignore the warning and continue – thus exposing all of their data.
Alternatively, the attacker could try and use tools such as SSLstrip to leverage poor application design with regards to SSL/TLS. This could also enable the attacker to obtain the victim’s password over clear text HTTP.
How concerned should you be?
The attack scenario described in 2a can be performed by any user on the same broadcast domain as your machine. This means that anyone sitting in the same coffee house on the wireless network could be an attacker. Also, if you connect directly to your Comcast/RoadRunner/ATT/whatever home connection, then many of your neighbors could also perform this attack against you. And if you use a home router instead of directly plugging the connection into your machine - well, then the attack is still possible via 2b (essentially the same attack).
Really the only reason this isn’t a bigger deal is because of the requirement to be on the same subnet. Right now we have so many other issues, such as XSS, SQL injection, etc, which can all be exploited remotely by attackers. The attackers just sit in their remote locations and destroy web sites from a far. However, the point is this, if an attacker wants to steal YOUR specific bank data then all they need to do is sit next to you at a coffee house or sign up for Internet service in your area.
If you find SSL/TLS attacks interesting, then check out an upcoming talk at Chicago's Thotcon Security Conference on Friday, April 23.
-Michael Coates