The Middleman Problem

One of the most famous network attacks is known as the On-path, or the Man-in-the- Middle (MitM) attack, in which a malicious actor attempts to trick network devices into routing their data through them. There are a plethora of methods one could employ to achieve this goal, which we will discuss in this article. However, it is also important to note how these methods have adapted to increased security and how you can remain vigilant. ARP Spoofing

The most common, classical method of MitM attacks in wired networks is called ARP Spoofing. This technique works because before a device wants to communicate with another device within the same network, it first needs to know the MAC address of that device.

You may wonder about the difference between a MAC and an IP address. Although the specifics are not strictly needed for this article, you can think of an IP address as who we want to send the data to (e.g., Bob), and the MAC address as where on the local network to physically deliver the data. For example, if Bob was outside of our network at the IP address 8.8.8.8, the MAC address we would specify would be our router’s (e.g., AA:BB:CC:DD:EE:FF), which would then route the data out of our network and to Bob. So, let’s say we have two devices on a network that want to communicate. Device 1 could broadcast a request for Device 2’s MAC address to the entire network: ‘Who has (Device 2’s IP address)? Tell (Device 1)’. This is called an Address Resolution Protocol (ARP) request as it is attempting to resolve an IP address to a MAC address. To clarify, it is broadcasting to all machines on the network, asking, ‘If this is your IP address, tell me your MAC address so we can communicate.’ Device 2 will see this request and will respond with its MAC address: ‘(Device 2’s IP address) is at (MAC address)’.

ARP request/reply diagram

As you can see, Device 1 broadcasts an ARP request to the network. Device 2 then sees this broadcast and realizes that it is their IP address. As a result, Device 2 sends an ARP reply. Device 1 will then store Device 2’s IP address and MAC address inside a table called an ARP table. This ensures that in the future, Device 1 knows that Device 2 resolves to a specific MAC address without having to constantly ask before communicating.

However, since this Address Resolution Protocol request (the request for the MAC address) is being broadcasted to the **ENTIRE ** network, it becomes trivial for a malicious actor to simply step in and pretend to be Device 2. This becomes much worse when Device 2 is a router.

Let’s now simulate this with three virtual machines:

• Device 1: A normal user with IP address 192.168.100.10
• Device 2: The Router with IP address 192.168.100.1
• Device 3: A malicious actor with IP address 192.168.100.50

Now, the goal of the malicious actor is to make the User believe that this actor is, in fact, the router (Device 2), as well as making the router believe that this actor is, in fact, the user (Device 1). In this way, the actor (Device 3) can sit in between both Device 1 and Device 2, forwarding the data between the two devices while secretly being able to inspect the contents.

ARP Spoofing Setup Diagram

You can see this illustrated in real time below:

As shown, the malicious actor first broadcasts ARP requests to the network to find out the MAC addresses of both the User and the Router. The User and the Router both reply with their MAC addresses, seen in the third and fourth line. Once the malicious actor has obtained these MAC addresses, they then send a forged ARP reply to the User claiming that the Router’s IP address belongs to them (line 5) and likewise sends a forged reply to the Router claiming that the User’s IP address also belongs to them (line 6).

We can see in the figure below that the User’s ARP table has now changed such that the Router’s IP address resolves to the attacker’s MAC address: ARP Table Change/Attack Process Diagram

So, what does this actually mean for our User? Well, let’s say our User now wants to communicate with Bob, who is outside our network. To do this, the User needs to send their data to the router, which requires a destination MAC address. The User will look through its ARP table to resolve the Router’s IP address to a MAC address and resolves it to the Attacker’s MAC address instead of the Router’s, therefore forwarding the data meant for Bob to the Attacker. The Attacker can then view or manipulate the data before forwarding it to the router, which will then route the data to Bob. When the router receives Bob’s response, it will go through its ARP table to resolve the User’s IP address in order to forward the response to the user. However, due to our attack, the User’s IP address resolves to the Attacker’s MAC address, therefore forwarding data meant for the User to the Attacker.

Of course, there are dozens of other ways one could research in which an Attacker could make themselves ‘the middleman’ of a network, including MAC flooding, rogue DHCP, DNS cache poisoning, evil twin, etc. However, the main caveat of a lot of these attacks in the modern world is that, although your data is being routed through a malicious device, as long as you are using encrypted protocols (which are the default), the attacker is not actually able to see any of your data. The reason why MitM was done in the past was that HTTP, FTP, and other non-encrypted protocols were in common use, and therefore data was being sent around the internet in plain text. This, of course, is unthinkable in the modern world and is one of the reasons why browsers always use HTTPS, the encrypted version of HTTP, ensured by a security policy called HSTS (HTTP Strict Transport Security), which forces web browsers to connect to a website exclusively over the protected HTTPS protocol.

So, if these classical attacks have been rendered mostly useless at the hands of encrypted protocols, how can attackers continue to utilize man-in-the-middle style attacks to steal data? Well, one of the most popular modern methods is called AitM or Adversary-in-the Middle attack.

Adversary in the Middle

The focus in classical MitM methods has been to try to intercept traffic on the wire itself, but this no longer works as HTTPS now secures data while it is in transit. However, AitM focuses on becoming a Proxy between the victim’s browser and a genuine website. A proxy is simply a device that sits between you and another website, forwarding your requests and the website’s responses back and forth.

The important aspect of this attack is that when a user connects to a website, a session is created between the client and the server. The server issues a session token (a short identifier) that the browser sends on each request. As long as the token is valid, you stay logged in even if you close and reopen the page.

If an Attacker can convince a user to visit the attacker’s phishing (impersonation) domain, the browser will establish a valid encrypted session with that domain. This will stop the browser from flagging any concerns to the user. In order to establish an HTTPS session between two devices, a certificate verifying the ownership of the domain is necessary. This is no obstacle for the Attacker because the domain does in fact belong to them. As a result, the Victim will not suspect anything.

Here’s an example:

• Target website: login.microsoftonline.com
• Phishing website (made by attacker): microsoft.not-a-phishing-site.com

The Attacker sets up a domain called microsoft.not-a-phishing-site.com and points it to their proxy server, which will fetch and forward pages from the real site (login.microsoftonline.com) to the victim. Popular tools to perform this include Evilginx2 or Muraena. This means when the Victim accesses the phishing link, they will be interacting with the real Microsoft.com because our site is just a proxy between the two.

The Victim clicks on the phishing link (from a phishing email or text) which takes them to microsoft.not-a-phishing-site.com and serves them the login page from login.microsoftonline.com.

The victim then kindly enters their Username and Password and completes the multi factor authentication for the attacker. The victim’s credentials are also then intercepted (e.g., below) by the attacker before forwarding them to the official site.

The proxy returns the legitimate site to the victim with an active session. The victim is now logged in as normal and sees nothing suspicious.

After a successful login by the user, the real site issues a session token. That token is what proves to the site that the browser is already authenticated. The proxy captures this token, and the attacker can now dump the session tokens in their terminal and replay the session in their own browser and gain access without performing the login or MFA themselves.

Here is what the phishing site would look like to the victim:

In this fake scenario, I have made the URL a clear giveaway, but if the URL was similar, it would be difficult for a normal user to notice any difference. One of the main hardships involved in this method is that the attacker needs to get the User to click on their phishing site instead of using the legitimate website. This is usually done by sending what are known as phishing emails, pretending to be a certain company or website asking a user to reset their credentials. Sometimes it can be very difficult for Users to discern between legitimate emails and phishing emails, for example, this AMEX phishing email:

Furthermore, Phishing sites can even use characters that look the same to humans but actually point to different characters in computer translation protocols. For example, the normal Latin ‘a’ vs. the Cyrillic ‘а’, which are identical but still classed as different by your computer.

So, ‘apple.com’ (with a Cyrillic ‘а’) looks identical to ‘apple.com’ but is a different domain. Attackers who exploit this are performing what is called a Homograph attack. You can bypass this trick by simply typing up the website yourself instead of clicking on email links.

The significance of Adversary-in-the-Middle attacks is that they exploit user trust rather than encrypted protocols: by tricking users into authenticating to a phishing proxy, attackers can completely bypass Multi-Factor Authentication instead of trying to decrypt data on the wire. This is what makes AitM an evolution of the classical MitM and something that is still feared today.