This week I was reminded how efficient ARP (Address Resolution Protocol) spoofing attacks might be. A single Android device equipped with offensive tools was enough to fool any device on a network and capture sensitive data. But wait, we are talking about a threat as old as ARP specification from 1982. There aren’t vulnerable networks to this nowadays, right? Wrong.

Based on my past experience, it is rather rare to see a network protected against this technique and I may have some clues why. First, we are not talking about a vulnerability but an intrinsic characteristic from ARP, a layer 2 network protocol responsible for mapping IP addresses to MAC addresses. It is implemented in every single connected device.

Let’s recall how ARP works. When a host need to establish a connection on a local network, it will broadcast the destination IP address and wait for the right machine to reply with its MAC address. To avoid unnecessary traffic, the IP/MAC pair is cached for a limited time on a local the ARP table. This table is dynamically constructed and maintained over time. The ARP table may also be updated through gratuitous announcements whenever a host announces its own MAC address without being asked for. This expected protocol behavior allows for a variety of malicious actions, such as DoS (Denial of Service), session hijacking and MITM (man-in-the-middle) attacks.

Of course, for a malicious host to implement such attacks, it needs to be connected to the network (wired or wireless) and this is a strong reason this threat is underestimated. However, we may have open networks, infected machines and insiders – this threat is authentic.

A Simple Experiment

To check how easily an insider could perform this attack on an unprotected network, we decided to make a quick experiment. We put together a bunch of easily findable Python scripts to perform ARP and DNS Spoofing and a web application on a small lab environment.

The objective was to implement a MITM attack and make a specific host, our victim, believe attacker machine was the network gateway. Additionally, using a simple DNS Spoofing script we would intercept and answer any DNS query to resolve to the IP address of the third component of our lab: a web application asking for basic authentication.  As shown in the following figures.

This simple phishing attack which could successfully capture sensitive information like passwords.

Mitigation

Most of the mitigations for ARP Spoofing attacks are made by network switches using DHCP Snooping and Dynamic ARP Inspection (DAI) techniques. The specific feature names may vary by switch brand, but basically, they allow only authorized ARP announcements to travel over the network. They drop ARP packets coming from hosts that do not match IP/MAC pairs delivered by the DHCP server.

To provide additional protection, especially for mobile devices, it is important to have an endpoint security solution, like host IPS, to discard unsolicited or gratuitous ARP packets.

Although switch and endpoint ARP spoofing protections are not new, implementing them may be another possible reason for not having this mitigation widely deployed. There are some tricks, mainly related to DHCP Snooping and DAI, that should be considered, such as: virtualized or clustering environments to avoid network or service interruptions.

Finally, while writing this diary and performing the experiments, I created a simple project to protect my laptop against ARP Spoofing. Every time I change from a network to another, the script gets the current gateway MAC address and sets it permanently on local ARP table. This way, arbitrary attempts to spoof the gateway MAC address for MITM attacks will be rejected. It currently works on Mac OS and is available on GitHub [1]. Suggestions, pull requests and bug reports are welcome.

References:

[1] https://github.com/morphuslabs/setgatewaymac

--
Renato Marinho
Morphus Labs| LinkedIn | Twitter