How a Toshiba Copier DoS’d Our Network Using ARP
A few years ago, I ran into an interesting networking problem. Some of our users at a particular site were reporting that they couldn’t connect to the network, and we quickly realized that it appeared to be a DHCP problem, as those users who were complaining couldn’t get an IP address. As we were checking the DHCP service, we realized that Windows XP computers weren’t being affected–it was only Windows 7 users who could not get an IP address. How strange!
I was quite the novice Wireshark user at the time, but since we had been using it in my university classes, I decided to fire it up and check things out from a packet level perspective. Part of the trace file I captured is displayed below and it has had all but the relevant packets removed for the purposes of this article.
Shown here is a single DHCP exchange which resulted in the requesting client failing to hold onto the given IP address. The traffic from the DHCP client, a Dell Windows 7 computer, is colored green, while the traffic from our DHCP server is colored yellow. The gray packet is a response from the gateway for a request for its MAC address originating from our DHCP client. The packet marked in red is the evil packet–it came from the Toshiba copier on the network.
Up until packet 8, everything was going fine. In packet 1, our Windows 7 computer came alive, saw that he was configured for DHCP, and broadcasted a DHCP Discover packet on the network. Our DHCP server checked for an available IP address, found that 10.18.2.7 was free, sent an ARP broadcast to see if any clients were currently using that address, seen in packet 2, and then sent a DHCP Offer to allow our computer to have that address in packet 3. The Request and ACK in subsequent packets 4 and 5 finalized the DHCP process. Packet 6 displays our Windows 7 computer sending an ARP broadcast for the gateway’s MAC address, and packet 7 shows a response for that request from the gateway. In packet 8, a Toshiba copier also wants to know who has 10.18.2.7, and requests that the response be sent to 0.0.0.0, but that isn’t a valid IP address. Our Windows 7 computer gets the sense that something is wrong, and releases his IP address in packet 9. We are kicked off the network!
So, why was this happening? It turns out that the Toshiba copier was plugged into the network, but not configured with an IP address. So, the copier literally had an address of 0.0.0.0, which is bad! In fact, you can’t configure an IP address of 0.0.0.0 on most devices, as its a special reserved address. It happens to be the source IP address of DHCP clients before they receive a real IP address from the DHCP server. My guess is that, for whatever reason, this Toshiba copier likes to immediately update its ARP table whenever a new host is discovered on the network (i.e. whenever a DHCP process is completed). Unfortunately, its ARP request to tell 0.0.0.0 about the MAC address of the new client is read by that new client as a check to see if that IP address is in use. In other words, the new DHCP client thinks another client wants to use the address it just accepted, and so it releases it to avoid an IP address conflict. With this problem consistently occurring, our Windows 7 computer will never get an IP address. It’s worth stating that, in my personal opinion, Toshiba or the NIC manufacturer for the Toshiba copier dropped the ball here, as you shouldn’t be allowed to configure an IP address of 0.0.0.0 in the first place, and it definitely shouldn’t be the default setting out of the box.
I was able to replicate this issue on my personal VMWare test network using Nping, a utility that can generate custom network packets. Since this behavior is present on a virtualized Windows 7 machine, I have to conclude that it is not a response specific to Dell computers/NICs which is what we were using in our environment at the time. In fact, my guess would be that most modern OS’s would have a similar response to this situation. If you see this issue in the future, the immediate fix is to configure a real IP address on the device, physically disconnect the offending device from the network, or shut down the switchport that the device is connected to.