Man in the Middle (MITM) Attacks Explained: ARP Poisoining

It’s been over 3 weeks since Firesheep was released, and yet still there seem to be so many misconceptions about this particular vulnerability.  The most prevalent of these misconceptions is that HTTP Session Hijacking, also known as “sidejacking” is something which is limited to only wireless networks.  And this belief is not limited to just session hijacking attacks.  Somewhere along the way a myth was propagated that wired switched networks are somehow impervious to attacks like these and other similar types of attacks because of the use of collision domains and the inability of an attacker to have unfettered access to the Layer 2 medium.  As I mentioned in my previous article on the Misconceptions About Sidejacking with Firesheep, attacks like these and others are not relegated to strictly wireless networks, and in fact there are many so-called Man-in-the-Middle (MITM) attacks which can be performed on a switched wired network to compromise the imaginary security of a Layer 2 collision domain.

Today we will kick off a series of articles in which we will discuss the different forms of MITM attacks.  MITM attacks come in many forms and essentially allow an attacker to act as a proxy between the victim and any host the victim has established connections with.  It is a form of active eavesdropping in which the attacker is controlling the conversation unbeknownst to the victim.

In this first part, we will discuss and outline a method whereby the Layer 2 network can be compromised, giving an attacker the ability to circumvent the limited protections of a collision domain and thereby observe traffic for which they would normally not have access to.  This is accomplished through an attack known as an ARP Poisoning attack, which is also commonly referred to as an ARP Spoofing attack.

Recall that in switched networks, unique collisions domain are created between each host and the switch.  This is unlike a hub which utilizes a single collision domain for all connected ports.  The primary reason for this behavior in switched networks is to reduce unintended collisions on the medium, however it has an added benefit in that it makes the network more secure from prying eyes.  In a switched network, traffic from one host to another is normally inspected by the switch, and the traffic is only forwarded to the host on the port whose destination MAC address matches that specified in the Ethernet header.  An obvious exception to this behavior is broadcast traffic, which is normally flooded to all ports in the broadcast domain (this normally means all ports on the switch, or if VLANs are being used, all ports in the same VLAN).  In unicast conversations however, sniffing traffic is much more difficult because the traffic is directed towards the appropriate destination and is not seen by hosts which are not part of the conversation.

Now let’s take a look at how the Layer 2 network can be subjugated via an ARP Poisoning attack.  An ARP Poisoning attack can be used to subjugate traffic staying local to the LAN as well as traffic that is going to a remote network.  In this scenario, we will describe traffic that is going off-net, towards some destination off the local network such as an Internet destination.  Under normal circumstances, a host comes online and attempts to associate a Layer 2 MAC address with the Layer 3 address of the default gateway.  The ARP Request is flooded to all ports on the network so that all devices have an opportunity to inspect the ARP Request to determine if their Layer 3 address is the one which is being requested.  In a normal scenario, the device which owns the Layer 3 address will respond with an ARP Reply and indicate the Layer 2 MAC address to associate with that Layer 3 address.

In the example below, we see the host 192.168.1.106 coming online and issuing an ARP Request for the MAC Address of the default gateway 192.168.1.1.  This ARP Request is broadcasted to all hosts on the network.  In this example, the network has not been compromised yet, so the proper ARP Response is issued by the router and sent towards the requesting host.  Through this mechanism, the requesting host now associates the Layer 2 MAC Address 00:11:45:02:0A:68 with the Layer 3 IP Address 192.168.1.1.

Now that we’ve seen how ARP works in a normal scenario, let’s take a quick look at how a Layer 2 switched network could be compromised, and force all off-net traffic to go through an intermediary device, in this case, the attackers machine.  By using a tool such as Ettercap, we can easily spoof these ARP messages across the local network, and fool unsuspecting devices into routing traffic towards the attacker’s machine.

First, we’ll spoof our own MAC address before launching the attack, because this is really the only fingerprint which might otherwise indicate the source of this attack.  A savvy attacker would therefore likely spoof his own MAC address to evade detection.  With the following command, we spoof our MAC address to 00:de:ad:be:ef:01:

BackTrackVM:~ sfouant$ sudo ifconfig en1 ether 00:de:ad:be:ef:01

Now that we’ve spoofed our MAC address, we can move on to the second phase of this attack using the ARP Poisoning tool Ettercap.  The following command will launch an ARP poisoning attack on the en1 interface and essentially poison all hosts on the local network by informing them that the gateway address 192.168.1.1 should now be associated with the MAC address of the attacking host (00:de:ad:be:ef:01).  Please note, a detailed analysis of Ettercap is beyond the scope of this article and interested readers are encouraged to read Irongeek’s excellent tutorial on sniffing.

BackTrackVM:~ sfouant$ sudo ettercap -i en1 -T -q -M ARP /192.168.1.1/ // Password:
ettercap NG-0.7.3 copyright 2001-2004 ALoR & NaGA
Listening on en1... (Ethernet)
   en1 -> 00:DE:AD:BE:EF:01      192.168.1.32       255.255.255.0
SSL dissection needs a valid 'redir_command_on' script in the etter.conf file Privileges dropped to UID 65534 GID 65534...
   0 plugins (disabled by configure...)   39 protocol dissectors   53 ports monitored 7587 mac vendor fingerprint 1698 tcp OS fingerprint 2183 known services
Randomizing 255 hosts for scanning... Scanning the whole netmask for 255 hosts... * |==================================================>| 100.00 %
37 hosts added to the hosts list...
ARP poisoning victims:
 GROUP 1 : 192.168.1.1 00:11:45:02:0A:68
 GROUP 2 : ANY (all the hosts in the list)
Starting Unified sniffing...
Text only Interface activated... Hit 'h' for inline help

Essentially, what we’ve done here is to use Ettercap to send out gratuitous ARPs to all hosts on the network.  Notice that in order for us to observe the full conversation, we must poison not only the victim, but also the router as well.  In the diagram below, you can see that the attacker has sent an ARP Reply to both the router as well as to the victim.  In the case of the ARP Reply to the router, we are telling the router that traffic destined towards the victim should now be sent to the attacker.  Similarly, in the case of the ARP Reply to the victim, we are telling the victim that traffic destined towards the router should likewise be sent to the attacker as well.

Here are the packet captures from the wire so we can see exactly what is taking place.  We see the attacker’s machine sending an ARP Reply to poison the ARP cache of both the victim’s machine as well as the router.

00:40:23.486347 00:de:ad:be:ef:01 > 00:21:6a:6c:9f:ee, ethertype ARP (0x0806), IPv4 (len 4), Reply 192.168.1.1 is-at 00:de:ad:be:ef:01

00:40:23.496628 00:de:ad:be:ef:01 > 00:11:45:02:0a:68, ethertype ARP (0x0806), IPv4 (len 4), Reply 192.168.1.106 is-at 00:de:ad:be:ef:01

And that’s pretty much all there is to it… once the ARP cache of the unsuspecting victims have been poisoned, the attacker has full reign to sniff any non-encrypted traffic to or from those victim machines, in a manner no different than putting a physical tap on the wire.  Attackers may use ARP Poisoning as part of a larger attack, for example, Firesheep could now be run to perform HTTP Session Hijacking when victims visit unsecured websites such as Facebook or Twitter.

The interesting thing to note is that the attacker’s machine has to keep track of a few details in order to make sure it can reach devices on the local network via their actual MAC address.  This is required because the attacker needs to proxy the communication between both the victim as well as the router.   If the attacker’s machine were itself to be poisoned, the attack would not be successful.  Therefore it is imperative that the ARP cache remains intact on the attacker’s machine.  Here we see the actual ARP entries stored on the attacker’s machine.

BackTrackVM:~ sfouant$ netstat -rn | grep default
default 192.168.1.1 UGSc 32 139815 en1
BackTrackVM:~ sfouant$ arp 192.168.1.1
? (192.168.1.1) at 0:11:45:2:a:68 on en1 ifscope [ethernet]
BackTrackVM:~ sfouant$ arp 192.168.1.106
? (192.168.1.106) at 0:21:6a:6c:9f:ee on en1 ifscope [ethernet]

Now that we’ve illustrated how ARP Poisoning works and illustrated it’s usage, you are probably interested to know how we can prevent this type of behavior on a local area network. While there are no foolproof mechanisms which can completely eliminate this threat in existence today, there are several things which can be done to monitor the network and limit what an attacker can do.

The first of these is to use some type of passive monitoring on the network, for example, something along the lines of arpwatch.  Arpwatch is a tool that monitors ARP traffic on a network and generates a log of observed IP to MAC address pairings.  This could be used after the fact to do forensic analysis, or it could be coupled with real-time triggered alerts in the event that something important like the supposed default gateway is observed sending out a new MAC address pairing.

Static ARP entries are another option but in practice this typically proves much too cumbersome to be effective, especially on large network segments with mobile users.

Different switch vendors have also incorporated different countermeasures and methods to protect this type of behavior on their products.  For example, Juniper Networks EX Series Ethernet Switches have a mechanism called Dynamic ARP Inspection, or DAI for short.  DAI tries to prevent ARP spoofing by intercepting ARP packets on untrusted ports and validates them against a DHCP snooping database.  This means that in order to be effective, you must employ DHCP for address assignment in your network.  That being said, often the locations where you want to prevent ARP Poisoning are going to be precisely those locations that employ the use of DHCP, so in practice this is not much of a negating factor.

DAI will check to see if the source MAC address of an ARP packet matches a valid entry in the DHCP snooping database, and if no entry exists, the packet is dropped.  What this means is that a host must get an address assigned via DHCP before it has any opportunity to send any type of ARP packet onto the network.  It’s not foolproof but it is definitely a better option than simply monitoring the network.

[edit ethernet-switching-options]
sfouant@switch# show
secure-access-port {
    interface interface-name {
        dhcp-trusted;
    }
    vlan vlan-name {
        arp-inspection;
        examine-dhcp;
    }
}

Juniper also has a mechanism known as MAC limiting which prevents MAC spoofing by limiting the number of MAC addresses learned on a given access port.  It can also be configured with an explicitly defined allowed MAC addresses for a given access port.  As we can see in the configuration below, we can define a specific MAC address to be allowed on a given interface using the ‘allowed-mac’ statement, or we can limit the number of learned addresses on a particular port through the use of the ‘mac-limit’ statement.  We can also choose to generate an error log, drop the offending packets, or shut the port down when there is a violation of our MAC limiting policy.

[edit ethernet-switching-options]
sfouant@switch# show
secure-access-port {
    interface ge-0/0/2.0 {
        allowed-mac [ 00:1b:c0:5e:53:a0 00:1b:c0:5e:53:a4 ];
    }
    interface ge-0/0/3.0 {
        mac-limit 1 action log;
    }
    interface ge-0/0/4.0 {
        mac-limit 2 action drop;
    }
    interface ge-0/0/5.0 {
        mac-limit 3 action shutdown;
    }
}

None of the above methods are completely foolproof but can certainly raise the bar for an attacker wanting to cause havoc on the local network.  One development which shows promise is a relatively new standard known as IEEE 802.1AE (also known as MACsec) which provides source authentication, data integrity, and encryption of devices on a Layer 2 network.  Not only would this encrypt sensitive data on the so-called “last-mile”, it will also prevent various man-in-the-middle attacks as well as passive wiretapping attempts.  Although MACsec does show promise, adoption by the vendor community has been slow and there aren’t any practical implementations of the technology that are immediately available for widespread deployment.

All in all, Layer 2 switched networks are not nearly as secure as many seem to think, and subjugating the network can be accomplished relatively easy by anyone with even the most basic of computer skills.  Ettercap is one such tool that easily allows a Layer 2 switched network to be compromised by poisoning the ARP cache of unsuspecting victims.  My hope is that this article might help raise awareness of the issues inherent in Layer 2 switched networks, and illustrate just how susceptible they are to compromise.  Please note that I do not condone attacks of this nature and have only written this article to raise awareness.