This report has been prepared to critically examine the various techniques and protocols for subverting the ARP protocol. By examining present forms of attack, this report will demonstrate how ARP as a protocol can be easily subverted using simple tools that are freely available on the Internet. Using a well established virtual environment, several of the attack techniques will be practically examined, and this report will identify, using an introduction to the ARP protocol, how in the future our networks might be secured.

Introduction

A network of computers requires that the devices have a physical medium which interconnect them, and a Network Interface Card (NIC) at each end that controls communication at the network layer within the ISO-OSI seven-layer model. Each NIC has a unique identifier (physical address) associated with it known as the Media Access Control (MAC). And when connected to a network, each device is given an Internet Protocol address (IP) that identifies a machines connection on a given network segment.

If a device wishes to talk on a network, it needs to send a datagram, a self-contained packet with a header allowing it to be forwarded to its destination. The issue being that the source device needs to discover the destination device so that it can construct the resulting datagram with the right header information.

In its simplest form, Address Resolution Protocol (ARP) provides a mechanism for the first level of communication when two devices wish to talk on a network. When a device wishes to talk to another, ARP broadcasts an ARP request containing the IP address of the device for which it needs the MAC address. All devices on the local network segment receive this broadcast and examine the IP address against their own. When a match is made, only the corresponding machine will reply to the sender of the request with an ARP reply containing its own MAC address. The originating sender places this MAC address in a table mapping it to the IP address it knows. This table is known as the ARP cache and is stored in memory on each device on the network.

Below is a diagram demonstrating the format of an ARP request and reply (as defined by RFC 826 [1]) , where during an ARP request all fields are completed except that of the recipient mac address which is the information being requested (highlighted in green).

The design of this protocol opens up the possibility of ARP spoofing which is often referred to as ARP poisoning allowing an attacker to forge the contents of an ARP request or reply.

This report will outline several techniques (some using examples) that will demonstrate the different types of attack. At the end of the report various countermeasures will be described to prevent these attacks.

Forms of Attack

MAC Flooding

The technique to this attack solely relies on a network switch and its ability to store the MAC address to IP address pairing. Switched hubs use a CAM [2] (content addressable memory) table to store information about the MAC addresses with their associated VLAN (virtual local area network) details (usually they store around 8000 entries).

The attacker exploits this limited memory weakness by sending lots of different packets with different MAC addresses to the switch. The switch then enters a state called fail in open repeating mode where all packets are transmitted on all ports, and the attacker can then sniff the network traffic that would otherwise not be available.

The main tool for such an attack is called MACOF (MAC Over Flow) which is capable of sending thousands of random MAC addresses a second, and providing the CAM table is not flushed (approximately every 5 minutes) the attacker will be able to sniff the traffic.

ARP Poison

This form of attack relies on the time a host operating system uses to refresh its ARP table. Most operating systems will refresh the table every 30 seconds, so the principle of an ARP poison is to insert false information into the ARP table of another host. By inserting this poisoned information its possible to prevent the target host from communicating any further on the network, essentially creating a denial of service.

Man-in-the-Middle

Using a combination of ARP poisoning and packet forwarding, its possible for an attacker to hijack a users session creating a man-in-the-middle attack. This is achieved by poisoning the ARP table of two hosts making them think that the attacker is the other host by simply forwarding on the information destined for the correct host.

This provides the attacker with access to all traffic being sent between target hosts. If, for example, the target client creates a telnet connection to the target server, the attacker will be able to monitor the username and password sent across during that session.

Practical Examples

During the construction of this report, numerous practical examples were used to test the theory behind the different forms of attack. Using a virtualisation environment known as VMware it was possible to reconstruct a virtual network where no real computers would be affected.

The diagram on the next page demonstrates the basic topology of the following key components:

1. Computer 1, known as Alice and
2. Computer 2, known as Bob
3. Computer 3, known as Eve who wishes to eavesdrop on the conversation between Alice and Bob.

The MAC address of each of the network interface cards was altered to match that of the numerical value of the last octet of the IP address. This means that when viewing the ARP cache of a given host, we can easily identify if one is spoofed.

Attached to the end page of this report is a DVD containing the preassembled Alice, Bob and Eve VMware images, with a configuration tutorial in the section named Configuring a VMware Environment. The DVD contains a pre-configured Eve with access to fragrouter amongst many tools.

ARP Poison

Using Eve as the attacker we need a tool that can trick Alice into thinking that Eve is in fact Bob. The tool used in this scenario is called arpd and is an ARP reply daemon that when running will attempt to respond to any ARP requests before the other computers on a given network. After successfully responding to the ARP from a host, it will map the IP address of that host to the MAC address of the attackers computer (Eve). This process is known as poisoning the ARP cache of another host, and can really only be performed in a virtual environment such as the one configured in this example as it could, depending on the machine bring a network to a stand still.

The above command sets the tool to listen on the only network adapter eth0, and also on a range of IP addresses to cover the number of users the attacker wishes to poison.

Now when Alice pings Bob we can see that the command hangs and no data is returned, resulting in the output below:

On Eves system we can see that the ping is being examined and listed:

The output on Eves computer show that when Alice pings Bob, Alices computer does not know who Bob is so sends an ARP request to ascertain the MAC address. At this point we get a race between who will reply first, Eve using a flooding technique, or the legitimate user Bob. As we can see above, the arpd tool is quite efficient at its job and detects the lookup, determines theres no entry for Bob, and then tells Alice that Eve is in fact Bob by altering the ARP reply with the MAC address of Eves machine.

To demonstrate the poisoned ARP cache on Alice, we can run the simple command arp ev that outputs the ARP cache in standard Linux format, listing as much extra information as possible using the verbose (v) argument.

Here we can clearly see that both IP addresses in the cache have the same MAC address, and from our initial configuration we determine that Eves computer is being reported as Bobs. This is confirmed by looking at the ARP cache of Bob. In principle, by poisoning the network, Bob should have no knowledge of the ping attempt, and as a result should still have an empty cache:

For the attacker this yields little use, unless the goal of the attack is to introduce a Denial of Service (DoS) on Alice. The next example will introduce a mechanism for forwarding the traffic received by Eve to the actual destination, thus forming a man-in-the-middle attack.

Man-In-The-Middle

The man-in-the-middle attack requires Eve to be running three applications:

1. the previously described arpd application (or a similar tool like arpredirect)
2. a further application called fragrouter
3. and finally a packet sniffer such as snort

The aim of the man-in-the-middle attack is to transparently observe the communication between Alice and Bob. This is achieved by first poisoning the ARP cache so that any information sent from Alice to Bob (and vice-versa), actually gets sent to Eve (as per previous example). Eve then forwards this information to Bob who believes the information has come directly from Alice. This is achieved using a tool known as fragrouter that runs as a daemon picking up any transmitted packets that have been obtained through the ARP poison and then forward the packets to their correct destination (as determined by the packet).

To demonstrate this, we need to configure the attack as per the ARP poison example, but now on Eve we run fragrouter at the same time as arpd so that we:

What we see here is fragrouter forwarding traffic from Alice, in this case multiple ICMP packets resulting from a ping being forwarded to its correct destination (Bob). When correctly configured you should also see reverse traffic from Bob to Alice.

To demonstrate that this is working, we can examine the ARP cache of Bobs computer and in theory we should see that all of the IP addresses are different, with the MAC address of Alice and Eve being the same. This means that when Bob wishes to reply to a message from Alice, it will be sent through Eve who will subsequently forward the packet to Alice. This can be seen in the diagram below:

This completes the man-in-the-middle attack, with neither party aware that Eve is intercepting the communication. Of course, without being able to view what is being transmitted between Alice and Bob, Eve will have gone to all this trouble for nothing. So by using another tool called Snort, Eve can analyse the packets in transit and store them for later examination using the following simple command:

By saving the data to a file (called dump in this example) we can analyse the output using standard Linux tools such as grep that uses regular expressions to search files for phrases such as pass to pick up on password details such as those transmitted during an FTP session. In this example we can observe both the ARP and ping packets sent from Alice to Bob. You can see that our arpd tool has assigned Bobs IP to that of Eves MAC address (4th and 5th line) followed by the ICMP ping request:

Countermeasures

As previously mentioned in the Introduction, any form of ARP poisoning requires that the attacker is physically located on the local network. That said it is possible for an attacker to get such access through say a VPN (virtual private network) and then be given local access via a remote connection. This implies system administrators need to implement tools and procedures that can detect and prevent such attacks. For a VPN you could give all remote users IP addresses within a separate subnet, with access to a shared resource such as file server that would prevent the rest of the organisations network from being effected. Of course, this would not prevent an attacker performing a denial of service so that remote users could not access the file server.

Depending on the size of the organisation, you have several options for reducing the risk of the ARP protocol being exploited:

1. Implement static ARP tables where each machine at boot is given a list of all the known hosts. These static entries mean that spoofing cannot take place, but this will only work on small networks where a system administrator can physically determine the MAC and IP of every machine.
2. For larger networks you can make the network switches assign specific access points with a specific MAC address. This prevents an attacker from changing the MAC address as the switch has been configured to allow only one trusted computer access to the network. This can also help prevent man-in-the-middle attacks as the network switch will prevent more than one MAC address being mapped to a single machine.
3. Implement a passive ARP monitoring tool such as arpwatch available for both Linux and Windows that will monitor a networks ARP activity maintaining a database of MAC to IP pairings. If a duplicated MAC is found an alert can be configured to inform the system administrator by e-mail.
4. It is possible to use other tools that perform active monitoring such as ettercap. Although ettercap itself can be used to perform ARP spoofing, its also extremely useful for determining if other users are trying to poison the network [3] using its arpcop plugin (a similar tool to arpwatch).
5. Use IDS (intrusion detection systems) to detect when an attack takes place and alert the system administrator; of course this will not prevent the attack.
6. A final option would be to try and configure Secure-ARP (SARP [4]) which uses public key infrastructure (PKI) to create a secure tunnel between clients, ignoring ARP requests from unknown hosts [5]. This process eliminates ARP from the network but introduces further complications of certification authorities and additional expense that only large organisations could implement.

Conclusions

The ARP protocol is a fundamental process within network communication, so there is no fix to the problem except to implement several of the countermeasures previously discussed. I suggest several countermeasures only for lack of a silver bullet solution, but any form of detection tool will be infinitely better than ignorance on the part of a systems administrator.

ARP poisoning is simple to detect, observing the network grinding to a halt, but as the target of the attack only holds its ARP cache data for approximately 30 seconds, the evidence that the attack has taken place is short lived. Of course, for successful and continuous DoS the attacker would need to continually poison the ARP tables of hosts on the network. The process of which allows the system administrator to identify the attacker and remove the suspect machine from the network. You are then reliant on this cache timeout to bring the network back to life after each false entry in the ARP table is removed, and subsequently replaced with correct pairings.

Some network administrators have considered the possibility of removing ARP from the network, but even the Windows kernel has the ARP functions deeply embedded. So, the question that must be asked is how much time and money is the system administrator going to spend on protecting their network?

The most successful countermeasure is to encrypt all network traffic, but at what cost? And to what degree will it impede network performance, if at every stage of communication you need to authenticate with the certificate authority and subsequently check revocation lists?

In conclusion we can see that there are several techniques for detecting when an ARP attack occurs, but without answering the questions regards to Secure ARP and refining how this would work on a small network, it is difficult to draw a conclusion to how we could prevent full exploitation of the ARP protocol.

References

Books

Comer D (2000), Internetworking with TCP/IP Volume 1 [Book] Publisher: Prentice Hall, ISBN: 0 13 018380 6

Teare D (1999), Designing Cisco Networks [Book] Publisher: Cisco Press, ISBN: 1-57870-105-8

Tanenbaum A (1996), Computer Networks [Book] Publisher: Prentice Hall, ISBN: 0-13-394248-1

Siyan K (1998), Inside TCP/IP [Book] Publisher: New Riders, ISBN: 1-56205-714-6

End Notes

[1] RFC 826 (1982) Address Resolution Protocol [Online] Network Working Group [Accessed on 24th Feb 2006] Available from: ftp://ftp.rfc-editor.org/in-notes/rfc826.txt

[2] Cisco (2003) CAM Tables [Online] Cisco [Accessed on 24th Feb 2006] Available from: http://www.cisco.com/warp/public/477/SNMP/cam_snmp.shtml

[3] Aharoni, Mati (2003) EtterCap ARP Spoofing and Beyond [Online] Security Pro News [Accessed on 24th Feb 2006] Available from: http://securitypronews.com/securitypronews-24-20030623EtterCapARPSpoofingandBeyond.html

[4] WP Media (2004) ARP and SARP [Online] WP Media [Accessed on 24th Feb 2006] Available from: http://www.wpmedia.com/arpandsarp.pdf

[5] Geier, Jim (2003) Beware of ARP Attacks [Online] Wi-Fi Planet [Accessed on 24th Feb 2006] Available from: http://www.wi-fiplanet.com/tutorials/article.php/3112991