When an IP packet is sent from one host to another in a local area network, the destination IP address must be resolved to a MAC address for transmission via the data link layer. When another host's IP address is known, and its MAC address is needed, a broadcast packet is sent out on the local network. This packet is known as an ARP request. The destination machine with the IP in the ARP request then responds with an ARP reply that contains the MAC address for that IP.
ARP is a stateless protocol. Network hosts will automatically cache any ARP replies they receive, regardless of whether network hosts requested them. Even ARP entries that have not yet expired will be overwritten when a new ARP reply packet is received. There is no method in the ARP protocol by which a host can authenticate the peer from which the packet originated. This behavior is the vulnerability that allows ARP spoofing to occur[1].
An ARP spoofing also knows as ARP cache poisoning is a technique by which an attacker sends (spoofed) Address Resolution Protocol (ARP) messages onto a local area network. Generally, the aim is to associate the attacker's MAC address with the IP address of another host, such as the default gateway, causing any traffic meant for that IP address to be sent to the attacker instead.
The ARP spoofing attack can only be used on networks that use ARP, and requires attacker have direct access to the local network segment to be attacked. ARP only works with 32-bit IP addresses in the older IPv4 standard. The newer IPv6 protocol uses a different protocol, Neighbor Discovery Protocol (NDP), which is secure and uses cryptographic keys to verify host identities. However, since most of the Internet still uses the older IPv4 protocol, ARP remains in wide use [2].
Let's demonstrate an ARP cache poisoning attack on the network shown in Figure 1. Our goal is to poison the ARP cache of PC1 and the default gateway - router R1, by matching the IP address of both hosts with the MAC address of Kali Linux. As a result, an attacker connected to switch S2 can intercept the traffic between PC1 and R1 and forward it, so there is still a connection between PC and R1.
Figure 1 - Network Topology
To practice Python and Scapy scripting, I wrote a script called arp_mitm.py. The script can be used for ARP cache poisoning of two hosts in LAN in order to conduct Man-in-the-Middle attack. The arguments to the script are the name of the attacker (Kali) Ethernet interface, the IP address of the victim, and the IP address of the default gateway.
$ sudo python3 interface_name victim_ip gateway_ip
Press Ctrl-C to end the attack. The script captures the key combination and sends a sequence of ARP packets to populate ARP cache of the victim and the router with correct MAC addresses.
1. PC1 and R1 ARP Caches Before ARP Poisoning Attack
The ARP cache of PC1 before ARP poisoning attack is shown in Figure 2. The IP address 192.168.10.254 configured on the Gi0/0 interface of R1 is associated with the MAC address of the Gi0/0 interface of R1 - 0C:90:88:7F:00:00.
Figure 2 - PC1 ARP Cache Before ARP Poisoning Attack
Likewise, the IP address of PC1 192.168.10.1, which is associated with the MAC address of the PC1 interface eth0 - 0c:3b:f2:b1:00:00 (Figure 3), is inserted into the ARP cache of the R1.
Figure 3 - R1 ARP Cache Before ARP Poisoning Attack
2. PC1 and R1 ARP Caches After ARP Poisoning Attack
Let's start poisoning attack by running script arp_mitm.py. with the following arguments:
$ sudo python3 eth0 192.168.10.1 192.168.10.254
Figure 4 - ARP Spoofing Attack with Python Script
The attack seems to work because PC1 now associates the IP address of R1 - 192.168.10.254 with the MAC address of the Kali interface - 0C:C0:1E:EE:00:00 (Figure 5).
Figure 5 - PC1 ARP Cache Poisoned with MAC of Kali
Similarly, R1 assigns the IP address of PC1 - 192.168.10.1 to the MAC address of the attacker's Kali Linux system - 0C:C0:1E:EE:00:00 (Figure 6). Note that the attacker's MAC address is assigned to both the IP address of PC1 and the attacker's IP address - 192.168.10.50. Normally, the same MAC should not appear multiple times in the device's ARP table; this is evidence that the cache is poisoned.
Figure 6 - R1 ARP Cache Poisoned with MAC of Kali
To test if there is a connection between PC1 and R1 during the ongoing ARP spoofing attack, we start pinging from 192.168.10.1 to 192.168.10.254 (Figure 7).
root@PC1:/home/tc# ping 192.168.10.254
Figure 7 - Checking Connectivity between PC1 and R1 During ARP Spoofing Attack
We also run tcpdump on Kali to check if the attacker is indeed intercepting traffic (Figure 8).
$ sudo tcpdump -i eth0 host 192.168.10.1 and 192.168.10.254
Figure 8 - Capturing Traffic Between PC1 and R1 on Kali Linux
Intercepted ICMP requests sent from PC1 to R1 are highlighted with a green box. The red box shows spoofed ARP responses sent from Kali to PC1 and R1. The ICMP responses from R1 to PC1 are also shown in Figure 8.