Understanding Man-in-the-Middle Attacks – ARP Cache Poisoning (Part 1)

The first part of an article series on some of the most widely used forms of MITM attacks, including ARP Cache Poisoning, DNS Spoofing, HTTP session hijacking, passing the hash and more. 

Introduction

One of the most prevalent network attacks used against individuals and large organizations alike are man-in-the-middle (MITM) attacks. Considered an active eavesdropping attack, MITM works by establishing connections to victim machines and relaying messages between them. In cases like these, one victim believes it is communicating directly with another victim, when in reality the communication flows through the host performing the attack. The end result is that the attacking host can not only intercept sensitive data, but can also inject and manipulate a data stream to gain further control of its victims.

In this series of articles we will examine some of the most widely used forms of MITM attacks including ARP cache poisoning, DNS spoofing, HTTP session hijacking, passing the hash, and more. As you will mostly find in the real world, most victim machines are Windows-based hosts. That being the case, this series of articles will focus entirely on MITM exploitation of hosts running versions of Windows. When possible, attacks will also be performed from Windows based hosts. In cases when there are no tools available for the attack being presented we will be utilizing Backtrack Linux 4, downloadable as a live-CD or a virtual machine from here.

ARP Cache Poisoning

In the first article of this series we will take a look at ARP cache poisoning. One of the oldest forms of modern MITM attack, ARP cache poisoning (sometimes also known as ARP Poison Routing) allows an attacker on the same subnet as its victims to eavesdrop on all network traffic between the victims. I’ve deliberately chosen this as the first attack to examine because it is one of the simplest to execute but is considered one of the most effective once implemented by attackers.

Normal ARP Communication

The ARP protocol was designed out of necessity to facilitate the translation of addresses between the second and third layers of the OSI model. The second layer, or data-link layer, uses MAC addresses so that hardware devices can communicate to each other directly on a small scale. The third layer, or network layer, uses IP addresses (most commonly) to create large scalable networks that can communicate across the globe. The data link layer deals directly with devices connected together where as the network layer deals with devices that are directly connected AND indirectly connected. Each layer has its own addressing scheme, and they must work together in order to make network communication happen. For this very reason, ARP was created with RFC 826, “An Ethernet Address Resolution Protocol”.

Figure 1: The ARP Communication Process

The nitty gritty of ARP operation is centered around two packets, an ARP request and an ARP reply. The purpose of the request and reply are to locate the hardware MAC address associated with a given IP address so that traffic can reach its destination on a network. The request packet is sent to every device on the network segment and says “Hey, my IP address is XX.XX.XX.XX, and my MAC address is XX:XX:XX:XX:XX:XX. I need to send something to whoever has the IP address XX.XX.XX.XX, but I don’t know what their hardware address is. Will whoever has this IP address please respond back with their MAC address?” The response would come in the ARP reply packet and effectively provide this answer, “Hey transmitting device. I am who you are looking for with the IP address of XX.XX.XX.XX. My MAC address is XX:XX:XX:XX:XX:XX.” Once this is completed the transmitting device will update its ARP cache table and the devices are able to communicate with one another.

Poisoning the Cache

ARP cache poisoning takes advantage of the insecure nature of the ARP protocol. Unlike protocols such as DNS that can be configured to only accept secured dynamic updates, devices using ARP will accept updates at any time. This means that any device can send an ARP reply packet to another host and force that host to update its ARP cache with the new value. Sending an ARP reply when no request has been generated is called sending a gratuitous ARP. When malicious intent is present the result of a few well placed gratuitous ARP packets used in this manner can result in hosts who think they are communicating with one host, but in reality are communicating with a listening attacker.

Figure 2: Intercepting Communication with ARP Cache Poisoning

Using Cain & Abel

Let us take the given scenario and take it from theory to reality. There are a few different tools that will perform the necessary steps to poison the ARP cache of victim machines. We will use the popular security tool Cain & Abel from Oxid.it. Cain & Abel does quite a few things beyond ARP cache poisoning and is a very useful tool to have in your arsenal. The installation of the tool is pretty clear cut so I won’t go through that here.

Before beginning you need to collect some additional information. This includes the network interface you wish you to use for the attack, and the two IP addresses of your communicating victims.

When you first open Cain & Abel, you will notice a series of tabs near the top of the window. For our purposes, we’ll be working in the Sniffer tab. When you click this tab, you will see an empty table. In order to fill this table you will need to activate the program’s built-in sniffer and scan your network for hosts.

Figure 3: Cain and Abel’s Sniffer Tab

Click the second icon on the toolbar, which resembles a network card. The first time you do this you will be asked to select the interface you wish to sniff. This interface should be the one that is connected to the network you will be performing your ARP cache poisoning on. Once you’ve selected this interface, click OK to activate Cain & Abel’s built-in sniffer. At this point the toolbar icon resembling a network card should be depressed. If it isn’t, do so now. To build a list of available hosts on your network, click the icon that resembles a plus (+) symbol on the main toolbar, and click OK.

Figure 4: Scanning for Hosts

The once-empty grid should now be filled with a list of all the hosts on your attached network, along with their MAC addresses, IP addresses, and vendor identifying information. This is the list you will work from when setting up your ARP cache poisoning.

At the bottom of the program window, you will see a set of tabs that will take you to other windows under the Sniffer heading. Now that you have built your host list, you will be working from the APR tab. Switch to the APR window by clicking the tab.

Once in the APR window, you are presented with two empty tables: an upper and a lower one. Once you set them up, the upper table will show the devices involved in your ARP cache poisoning, and the lower table will show all communication between your poisoned machines.

Continue setting up your ARP poisoning by clicking the icon resembling the plus (+) symbol on the program’s standard toolbar. The window that appears has two selection columns side by side. On the left side, you will see a list of all available hosts on your network. Click the IP address of one of your victims. This will result in the right window showing a list of all hosts in the network, omitting the IP address you just selected. In the right window, click the IP address of the other victim, and click OK.

Figure 5: Selecting Victim Hosts for Poisoning

The IP addresses of both devices should now be listed in the upper table in the main application window. To complete the process, click the yellow-and-black radiation symbol on the standard toolbar. This will activate Cain & Abel’s ARP cache poisoning features and allow your analyzing system to be the middleman for all communications between the two victims. If you are curious to see what is happening behind the scenes try installing Wireshark and listen to the interface when you enable poisoning. You will see a flurry of ARP traffic to both hosts and immediately begin seeing the communication between them.

Figure 6: ARP Traffic Injection

When you are finished, simply click the yellow-and-black radiation symbol again to stop ARP cache poisoning.

Defending Against ARP Cache Poisoning

Looking at ARP cache poisoning from the defenders standpoint we are at a bit of a disadvantage. The ARP process happens in the background with very little ability to be controlled directly by us. There is no catch all solution, but proactive and reactive stances can be taken if you are concerned about ARP cache poisoning on your network.

Securing the LAN

ARP Cache Poisoning is only a viable attack technique when attempting to intercept traffic between two hosts on the same local area network. The only reason you would have to fear this is if a local device on your network has been compromised, a trusted user has malicious intent, or someone has managed to plug an un-trusted device into the network. Although we too often focus the entirety of our security efforts on the network perimeter, defending against internal threats and having a good internal security posture can help eliminate the fear of the attack mentioned here.

Hard Coding the ARP Cache

One way to protect against the unsecured dynamic nature of ARP requests and replies is to make the process a little less…dynamic. This is an option because Windows-based hosts allow for the addition of static entries into the ARP cache. You can view the ARP cache of a Windows host by opening a command prompt and type the command arp –a.

Figure 7: Viewing the ARP Cache

You can add entries to this list by using the command, arp –s .

In cases where your network configuration does not change often, it is entirely feasible to make a listing of static ARP entries and deploy them to clients via an automated script. This will ensure that devices will always rely on their local ARP cache rather than relying on ARP requests and replies.

Monitoring ARP Traffic with a Third Party Program

The last option for defending against ARP cache poisoning is a reactive approach that involves monitoring the network traffic of hosts. This can be done with a few different intrusion detection systems (such as Snort) or through downloadable utilities designed specifically for this purpose (such as xARP). This may be feasible when you are only concerned about a single host, but can be a bit cumbersome to deal with when concerned with entire network segments.

ARP Cache Poisoning is a great introduction into the world of passive man-in-the-middle attacks because it’s very simple to execute, is a very real threat on modern networks, and is difficult to detect and defend against. In the next article in this series we will focus on name resolution and the concept of DNS spoofing.