ARP spoofing and poisoning

Traffic Tricks

By Thomas Demuth, Achim Leitner

www.sxc.hu

Curiousity, revenge, industrial espionage are all reasons why insiders attack systems on their own network. Statistics show that 70 to 80 percent of all attacks originate on the internal network [1]. Admins have a hard time preventing these internal attacks because protecting the internal network is a lot more difficult than protecting against external attack.

One of the most formidable forms of internal attack is known as ARP spoofing. ARP spoofing puts an attacker in a position to sniff and manipulate local traffic. So-called man-in-the-middle attacks are easy to perform, and thanks to sophisticated software, even attackers with little knowledge of networking stand a good chance of succeeding.

How ARP Works

The ARP protocol was published in November 1982 by David C. Plummer as RFC 826 [2]. As IT security was not an important factor back in 1982, the aim was simply to provide functionality. ARP maps IP addresses to MAC addresses. If client C needs to send a packet to server S, it needs to know the MAC address of S if both machines are on the same subnet. Even if S resides in a different network, C still needs a MAC address - in this case, the address of the next router that will forward the packet. The router takes care of everything else.

To ascertain the MAC address, C broadcasts an ARP request to all the machines on the local network, asking "Who has the IP address a.b.c.d?" The computer with the matching number replies and tells the client its MAC address (Figure 1).

Figure 1: The client uses ARP to ascertain the MAC address of the server on the LAN before sending a packet to that server. The "Who has..." request is broadcast to all machines on the LAN. The node with the requested address responds directly to the querying machine.

As shown in Figure 2, an ARP packet is carried as the payload in an Ethernet frame. To allow this to happen, a value of 0x8006 is set in the frame header type field - this tells the target to expect an ARP packet.

Figure 2: An ARP packet is transmitted as the payload of the Ethernet frame. The fields with the type and length of the addresses in each packet are followed by the source and target data.

As it would be far too expensive to broadcast an ARP request and wait for the response before sending data, each IP stack has an ARP table, also known as an ARP cache (Figure 3). The cache contains a table with IP addresses and corresponding MAC addresses. The table can hold static entries (i.e., those generated by the user) and dynamic entries (those learned from the ARP protocol). Dynamic entries are often valid for a short period only, typically just a few minutes.

Figure 3: The ARP table on a Linux system with one incomplete entry, one static entry, and two dynamic entries (Flag C: complete, M: static).

Addressing Attacks on the LAN

As ARP makes no attempt to protect itself against spoofed packets, it is vulnerable to a series of attacks. The most common types are MAC spoofing, MAC flooding, and ARP spoofing.

MAC spoofing involves the attacker using a spoofed MAC source address. This technique makes sense if privileges are linked to a MAC address. Many WLAN (Wireless LAN) operators put the MAC addresses of authorized users in an access control list. This is a weak security measure that is easy to avoid. The attacker only needs to know and spoof a privileged address while the machine used by the legitimate user with this address is down. MAC spoofing is useful for attackers who want to protect their identity.

There is a good way of preventing this on wired networks: many switches enable port security. The switch only learns each MAC address once, and then stores this address permanently. From this point onward, the switch will not accept any other source MAC address on the mapped port. This mechanism is effective against MAC spoofing attacks. On the downside, admins need to reconfigure the switch whenever they change the network.

Port security can also protect your network against another kind of attack. MAC flooding attacks are designed to take down a switch's port security mappings. In contrast to hubs, switches use CAM (Content Addressable Memory) tables, which specify the port behind each active MAC address on the switch. The switch will only send packets via the port that leads to the target machine.

Attackers can disable this function by flooding the switch with addresses - the CAM table can only hold a limited number of entries. If the attack succeeds, the switch is reduced to working like a hub, and that makes communication visible across all ports.

ARP Table Poisoning

The third attack is not as easy to detect, and there are no simple countermeasures. The attack is based on ARP spoofing, where the attacker deliberately transmits fake ARP packets. ARP poisoning is a specific type of ARP spoofing that aims to manipulate (poison) the ARP tables on other machines.

As operating systems tend not to check if an ARP reply really is the answer to an ARP request sent previously, the address information from the reply is cached. On Windows systems attackers can even modify entries explicitly declared as static by users.

Doing so allows an attacker to monitor the dialog between a client and a server, and, as the man in the middle, to manipulate that dialog. The man in the middle manipulates the server entry in the client's ARP cache, making the client believe that the attacker's own MAC address is actually the server address. The same trick is also played on the server.

If the client wants to talk to the server, it will check its poisoned ARP table and send the packet to the attacker's MAC address. This allows the attacker to read and modify the packet before forwarding it to the server. The server then assumes that the packet was sent directly by the client. The server reply again goes to the attacker, who forwards it to the client. If the server resides on a different subnet, the attacker can simply launch the attack against the router.

Of course, it goes without saying that an attacker could cause a denial of service by simply discarding any re-routed packets. To manipulate data, the attacker simply needs to forward different data than he or she receives. Attackers can trivially collect passwords, as the port number will allow them to guess the protocol used and identify the user credentials based on this knowledge.

Caution even with SSL and SSH

Encrypted connections are not automatically immune, as various ARP tools demonstrate. These programs are now available for various operating systems (see the box titled "ARP Exploit Tools"). Besides ARP poisoning functionality, they include client and server implementations for SSL (Secure Socket Layer), TLS (Transport Layer Security), SSH (Secure Shell), or PPTP (Point to Point Tunneling Protocol).

On accessing the SSL web server, the browser warns the user that something is wrong with the certificate for this connection. But many users do not understand the significance of the warning and just ignore it. The fact that many web servers use a self generated or elapsed certificate means that the warning is quite familiar to users; in fact, it just tends to provoke a click and ignore effect. A bug in some Internet Explorer versions makes it possible to attack SSL connections without the browser even displaying a warning.

The attack on SSH follows a similar pattern (Figure 4). If the client already knows the server-side host key, it will issue a clear warning (Figure 5). But many users and admins will still ignore the warning, assuming that someone has changed the SSH key on the server. Few protocols or implementations are immune. (IPsec is one exception. IPsec refuses to work if something goes wrong with the authentication process.)

Figure 4: Ettercap waiting for a connection between 192.168.1.120 add 192.168.1.124 (source and destination, top left). The tool can trivially sniff telnet and FTP. It uses a man in the middle attack on SSHv1 to decrypt the connection.

Figure 5: During the Ettercap attack (Figure 4), the client (odo in this case) receives a fake host key from the server. The key is from the attacker and not from the requested server (bashir). If the user chooses to ignore the warning, the connection can be sniffed.

Because of this problem, almost any kind of internal communication is vulnerable. There are even script kiddie tools that can grab passwords for over 50 protocols. As these attacks run at ARP level and typically only IP access is logged, today's attackers can feel quite safe that nobody will notice what they are up to.

Preventing ARP Attacks

One approach for preventing ARP attacks would be to prevent downloading and execution of external software, although this rule is extremely difficult to enforce. Admins would need to restrict the use of the Internet connection. HTTP, HTTPS, FTP, and email make it easy for an attacker to smuggle malware onto the internal network. Admins would also need to outlaw the use of removable media such as floppies or CDs, as well as mobile devices such as notebooks or PDAs. Due to the serious usability restrictions, this solution is typically impracticable.

If you use Linux on your internal network and do not allow your users root privileges, you can avoid most attacks from the outset: users need root privileges to send spoofed ARP packets. However, as an admin, you have no real way of preventing users from booting their machines from CD or attaching their laptops to the network.

Static ARP entries can help to prevent ARP attacks, but most admins will want to avoid the enormous effort involved in manually assigning addresses for all but the most critical machines (routers and servers). And Microsoft operating systems allow attackers to poison even manually assigned ARP entries, removing any protection this might give you.

This approach only makes sense in small networks, as the number of ARP entries grows proportionally to the square on the number of network adapters. In other words, you would need 9900 entries for a hundred systems (99 for each system). This involves enormous administrative effort, especially if you need to troubleshoot problems on the network.

Keeping a Watchful Eye

Arpwatch [4] is an open source tool for Unix platforms that monitors unusual ARP activities. The computer running Arpwatch reads the address information stored in each ARP packet that it sees and stores this information in a database. If the data fails to match previously stored entries, Arpwatch mails an alert to the administrator. The authors claim that the tool supports SNMP, although we were unable to confirm this in our lab.

Today, many networks use dynamic IP addresses assigned by DHCP (Dynamic Host Configuration Protocol). In this kind of environment, Arpwatch will return large numbers of false positives as it notifies users of any changed IP/MAC mappings.

ARP-Guard [5], a fairly new product by ISL, works within the framework of a sensor management architecture. Multiple sensors monitor ARP information and forward this information to the management system, which analyzes messages and alerts administrators in case of an attack. The architecture means that ARP-Guard will scale well from small to large networks, and the web-based management interface is something that command-line challenged admins will appreciate.

ARP-Guard has LAN and SNMP sensors. The LAN sensor works just like Arpwatch or any IDS system, analyzing any ARP packets that the sensor sees. In contrast to this, the SNMP sensor uses SNMP to connect to existing devices and query their ARP tables.

Intrusion Detection Systems (see the box titled "Snort and ARP") are also capable of detecting ARP attacks, but these systems are more typically deployed at network borders. For many businesses, it is simply not worth deploying an IDS on the internal network. Additionally, employees might resent the IDS system administrator playing Big Brother on the network. The administrator can see all the traffic on the network and thus monitor access by staff. The usefulness of this approach is also questionable, as many IDS systems simply ignore the ARP protocol. And finally, the whole system would collapse faced with ARP poisoning attacks in combination with dynamically assigned IP addresses.

Cryptography Can Help

Wherever cryptographic protocols (IPsec above all) ensure the confidentiality, authenticity and integrity of data, ARP attacks are reduced to mere denial of service attacks. Any attempt to sniff or manipulate data will fail. However, it may be a long while before IPsec and other crypto-protocols are set up and correctly configured on internal networks.

One group or researchers suggests replacing ARP with a more secure version [7]. S-ARP relies on cryptography, a CA (Certifcation Authority), and digitally signed ARP messages. However, it is questionable whether the effort is really worthwhile: IPsec provides far more protection with a similar overhead, whereas S-ARP only protects ARP. The only thing S-ARP has going in its favor is that it means less CPU load on the systems.

Other Prevention Techniques

Some firewalls and router manufacturers maintain that their products are capable of detecting ARP spoofing attacks, but this is not strictly true as these systems can only detect and log modifications to their own ARP tables and have no way of knowing whether the change has a legitimate cause.

Dividing the network into a large number of subnets and assigning a small number of users to each subnet can help to limit exposure to ARP attacks. Manageable switches, which allow administrators to manage network traffic, give protection against ARP attacks and serve as a boon to traffic management as well. On the downside, a manageable switch is expensive, adds administrative overhead, and may have the effect of breaking some applications.

Some developers attempt to add protection to the IP stack on the terminal devices. The Antidote patch [8] tells a Linux machine to send a request to the previous MAC address before changing an ARP entry. The machine will only change the entry if the request to the previous address is not answered. Again, this approach does not give you any real protection against sabotage. The attacker simply needs to ensure that the attack occurs when the machine with the previous MAC address is down or unreachable. In the case of many high availability or load balancing solutions, the patch can actually cause communication to these systems to fail.

Another approach to protecting yourself against ARP poisoning is to prevent reassignment of existing MAC-IP mappings. The Anticap patch [9] implements this behavior for Linux, FreeBSD, and NetBSD. Solaris has a similar option, which requires a timer to expire before applying a change. This behavior is freely configurable, however, a solution such as the Anticap patch only protects systems that are permanently up - attackers would have no trouble spoofing new entries once the cached entries expire.

Linux with kernel 2.4 or newer no longer reacts to unsolicited ARP replies. Unfortunately, this mechanism is easy to circumvent, as the Ettercap readme file explains. The kernel always has to process ARP requests. As the kernel is passed a combination of IP address and MAC address (for the source), it proactively adds this data to its ARP cache. So the attacker only needs to send a spoofed ARP request. Ettercap sends a combined ARP request and reply, and any system will respond to one of these techniques.

Protection built into the IP stack is powerless to prevent ARP spoofing. If an attacker responds to an ARP request more quickly than the machine to which the request is addressed, the attacker wins the race and the attacker's address is added to the ARP table.

No Protection

Today's techniques can't give you complete protection against ARP attacks, but you can arm yourself with IDS and specialized ARP manipulation sensors to detect most manipulation attempts. To be completely secure, you need to deploy IPsec consistently on your network. Ignoring the issue is not a good option unless you can genuinely trust every user with access to your LAN.