A Case Study: Inadvertent ARP Spoofing

At a Department of Computer Services in a midwestern university, a room is set aside for making presentations to groups of clients. The room is equipped with a Unix workstation and a $15,000 ceiling-mounted video projector projecting onto a $2,000 eight-foot diameter screen. One day, the workstation needed to be replaced with a newer model. The new workstation came in and was being configured to match the configuration of the workstation in the presentation room. One of the first questions asked during the operating system installation process was the IP address. The technician in charge of configuring the new workstation looked up the IP address of the workstation in the presentation room and entered it into the dialog box.

After a short time, the new workstation was up and running. The systems staff wanted to be sure it was working correctly because it was difficult to fix after it was installed in the presentation room. The new workstation was turned off that night after testing the shutdown procedure to be used by the presenters.

The next morning a presentation started in the presentation room with the old workstation. All was going well until the systems staff decided to resume testing of the new workstation. Shortly after the new workstation booted, the presentation came to a complete halt. The person in charge of the presentation was using the X Window System to demonstrate a program running on a better computer. The workstation in the presentation room had established a TCP/IP connection with the better machine and the presenter was creating the illusion that the program was running on the old workstation.

What had happened was the better computer had created an ARP cache entry for the old workstation when the presenter started the TCP/IP connection. As the presentation progressed, the ongoing IP datagrams from the better computer to the old workstation used the cache entry created at the beginning of the presentation. Several minutes into the presentation the ARP cache entry expired and a new ARP request went out from the better computer. The first time the ARP cache entry expired, the old workstation replied appropriately. The next time the ARP cache expired, however, the new workstation had been started. Both the old and new workstations replied to the computer running the demonstration software. The new workstation’s hardware address ended up in its ARP cache and the new workstation began receiving the IP datagrams sent to the IP address the old and new workstations shared. The new workstation did not know what to do with these datagrams and promptly sent a TCP/IP reset message in reply, resulting in the shutdown of the demonstration program. From initial appearances, the demonstration program just stopped and the old workstation appeared to have been cut off from the network.

Naturally, the presenter was upset. When the system administrator figured out what had gone wrong, the technician who used the IP address of an existing machine learned a valuable lesson: two machines with the same IP address cannot be connected to the network at the same time.

A Case Study: Malicious ARP Spoofing

As mentioned earlier, I work at a university where Computer Science allows its clients (students) temporary access to its computers. These include some Unix workstations using NFS to mount a mission-critical file system. One of these clients has a laptop running Unix. He already knows the IP address of the workstations that NFS mount the mission-critical file systems. This particular user has created a copy of the workstation password file on his laptop and has superuser privileges on his own laptop, which runs Unix with NFS.

One day he is left alone in the room with one of our workstations. He shuts down the workstation and jacks his laptop into our network. After a few minutes the file server’s ARP cache entry for the workstation expires. Then, he launches an attack by telling his workstation to NFS mount our mission-critical file system. The mount daemon on the file server checks the IP address of the machine making this request against the list of authorized IP addresses and finds a match. It then proceeds to send information needed to access the NFS daemon back to the IP address that just made the mount request.

When the mount daemon sends the reply back, the low-level software connecting IP to Ethernet discovers that it does not have an ARP cache entry for this IP address. It puts the reply on hold and makes an ARP broadcast to determine the hardware address to which to send the reply. The attacker’s laptop is the only machine to respond. The low-level software takes the response, caches it, and uses it to take the reply out of the holding bin and send it out the Ethernet interface. The attacker succeeds in accessing the mission-critical file system as if he were a legitimate user of the workstation that he just shut down.

Preventing an ARP Spoof

It is not particularly satisfying to simply detect ARP spoofing, which only identifies a problem after it has already occurred. Although it may not be possible to prevent ARP spoofing entirely, one simple precaution can be taken where it may count the most. The devious thing about an ARP spoof is that the attack is really directed at the machine being deceived, not the machine whose IP address is being taken over. Presumably, the machine or machines being deceived contain data that the ARP spoofer wants to get or modify.

The deception is useful to the ARP spoofer because the legitimate holder of the IP address is trusted in some way by the machine being deceived. Perhaps the trusted machine is allowed to NFS mount file systems, use rlogin, or start a remote shell without being prompted for a password (particularly troublesome for privileged user accounts). Ideally, machines extending such trust should simply not use ARP to identify the hardware addresses of the machines they trust.