Address Resolution Protocol, better known as ARP, is very common traffic on today's computer networks. Each computer (including switches and routers) maintains an ARP cache. This ARP cache contains a list of unique MAC addresses (Media Access Code) mapped to specific IP addresses. This table or cache is populated as the computer requests information from other computers on the same subnet. ARP traffic comes in two forms- ARP Requests and ARP Replies. One computer on the subnet with the IP address of 192.168.2.12 might ask "who has 192.168.2.3 tell 192.168.2.12", because they have a packet of information that needs to be routed to them. This ARP Request is broadcasted throughout the subnet, and every single machine receives it and reads it. However, when the machine with the IP address 192.168.2.3 receives the broadcasted request, he transmits back an ARP Reply, which is a unicast packet, in which he tells 192.168.2.12 that he is at a certain MAC address. With this knowledge, the machine at 192.168.2.12 can successfully send the machine at 192.168.2.3 the packet, and store his MAC address in his ARP table for future reference.


Why is it important:

Network engineers would argue that living a life without the Address Resolution Protocol would be like living a life without oxygen... It's that essential. Even though a machine may be assigned an IP address statically or via DHCP, other computers on the subnet won't be aware of which machine currently has a certain IP address. In a network where IP addresses are randomly handed out to different machines via DHCP, there is no telling who has what IP address. In order to successfully transfer traffic, one must know the specific IP address of a certain machine so that the packets can be effectively routed to the right location. The router at the right location can then forward the packet based on its ARP table to the computer in the network with the MAC address that matches the IP address specified by the sender. ARP replies and requests enable computers on the same subnet to communicate with each other and share their IP information with each other. ARP works at Layer 2 of the OSI model, and therefore is not reliant on the Internet Protocol (IP), which operates at Layer 3. This is important, because it is the reason why ARP Requests are broadcasted throughout the subnet instead of being sent directly to a computer with a specific IP address.


So what is the problem?

The problem is that computers and routers build ARP tables without actually verifying the data. If an ARP reply is received, the computer trusts the sender and adds it to the table. Lets say for example that an attacking computer, with an IP address of 192.168.2.10, sends an ARP reply to a router on a subnet, with an IP address of 192.168.2.1, which tells the router that the attacking computer has the IP address of 192.168.2.3. Immediately, the router's ARP table is updated, and 192.168.2.3 is mapped to the MAC address of the attacking computer! Now there are two IP addresses in the router's ARP table that are mapped to the same MAC address, which is usual behavior, and is not necessarily suspicious. This produces a disasterous effect, because the router routes all incoming traffic destined for the computer who's IP address is 192.168.2.3 to the attacking computer who is pretending to be at 192.168.2.3! Obviously, it would be easy to detect that something mysterious is going on in the network at this point, since the computer who's IP address is 192.168.2.3 won't be receiving any data. However, if the attacking computer, who's IP address is still 192.168.2.10 were to forward all of the traffic destined for 192.168.2.3 to the computer who's IP address is 192.168.2.3, the attack becomes more difficult to detect. Still however, one could easily tell that in fact, all the traffic was in fact coming from 192.168.2.10 and not the router's IP address, which would raise suspicion. In order to mask this, the attacker needs to send yet another ARP reply out, this time destined to the victim's IP address. The victim's computer blindly accepts this ARP reply as 100% valid, and thus gets tricked into thinking that the computer with the IP address of 192.168.2.10 is in fact the router with the IP address of 192.168.2.1! This type of attack is called a man-in-the-middle attack, since the attacker's computer is monitoring all of the traffic passing in between two machines. If the attacker is careful about who he is poisonning, it can be very difficult to detect. On a large network, where machines are constantly being added and removed, and IP addresses are randomly being assigned via DHCP, a man-in-the-middle attack can be virtually impossible to detect. This is because of a lack of record keeping. Because entries in the ARP table expire after a given amount of time, attackers tend to constantly simulate ARP replies destined to their victim's IP addresses. This can lead to ARP flooding, which results in network congestion.


How difficult is it to detect?

I have found that the easiest way to detect MAC address spoofing is by monitoring ARP transmissions. Occasionally, a computer at a certain IP address might spit out several ARP replies in a very short time span, just to let others know that they are there, which is normal behavior. However, if ARP replies are coming in consistenly at a relatively constant rate from a single source, it might be worth investigating. Being familiar with the network on which you operate also greatly helps. MAC addresses usually stay the same, so if you notice that your corporate router is now associated with a new MAC address, it might be worth asking about. Your network engineers most likely just upgraded a piece of hardware, but still, they will be grateful that you are an aware employee.


How can I avoid it?

The best way to avoid most types of attacks is to remain offline. However, that is not all that practical. The next best way to avoid being spoofed is by setting up a static ARP table, which means you assign specific IP addresses to specific MAC addresses. However, as you can imagine in a large network environment using DHCP, this method is not practical either. You could require that everyone on the subnet register their MAC address and assign them a specific IP address, but this requires a lot of management.


How can I protect myself from it?

As far as I am concerned, protecting oneself from ARP abuse is difficult. You do have the option of setting up a static ARP table, which you populate yourself, rather than just relying on ARP replies your computer receives. Static ARP tables take time to build, require careful typing, and are prone to being outdated should an IP address be assigned to a different MAC address. It might make sense to make a static ARP entry to link your router's MAC address (which you have visually confirmed) to your default router's IP address, assuming that most of the traffic you send over the network consists of at least one hop. I have read, but am unable to confirm, that even if you do set up a static ARP table in Windows XP, it can be easily overwritten by ARP replies that contain different information. This obviously is a vulnerablity.


HERE IS A LINK TO MY ARP WATCHER PROGRAM WRITTEN IN PYTHON!




This website was designed using GNU Emacs 21.2.1