As we all know, the function of the ARP protocol is to translate an IP address to its corresponding MAC address. By doing so, the devices are able to communicate effectively in a LAN-based network. Any device that wishes to get connected with the other device on the same network requires the MAC address of the other hosts. Every OS maintains a list of communicating devices that can be populated in the terminal window using the arp –a command. The same command is used on every platform. We have also seen the ARP requests and reply packets that are used by the devices connected to the local network to gain the MAC addresses of other devices.
For instance, I have a local network too, which is being governed by the router (gateway) located at 192.168.1.1, and there are 3 devices connected to it. The following table lists all the required information specific to the devices connected, which we will use later:
|
Device |
IP Address |
MAC Address |
|---|---|---|
|
Router (default gateway) |
192.168.1.1 |
D0:5B:A8:07:73:6C |
|
Apple (victim) |
192.168.1.103 |
D8:BB:2C:B9:53:EC |
|
Windows server (victim) |
192.168.1.109 |
00:0C:29:B3:CB:B6 |
|
Kali Linux (attacker) |
192.168.1.106 |
00:0C:29:5D:A7:F7 |
This preceding information is listed in the ARP cache of every host connected to the local network. You must be thinking exactly how this is being populated in the local cache. Whenever any device intends to communicate with the other device, the requesting device sends a broadcast to the whole subnet. Then, the device to which the IP address belongs replies with it's MAC address using a unicast packet. For example, if the Apple machine wishes to communicate with the Windows machine located at 192.168.1.109, Apple will send a broadcast asking for the Windows MAC address stating Who has 192.168.1.109? Tell 192.168.1.103. Then, as soon as the Windows machine gets to know about the request, the ARP reply unicast packet stating 192.168.1.109 is at 00:0C:29:B3:CB:B6 will be broadcasted. This is how the process works.
The preceding packets transfer will only happen if the Apple machine has the Windows MAC address in it's local cache. After searching in the local cache, the request is sent to the default gateway. If the default gateway knows about it, an ARP reply packet is sent by the gateway itself. If not, then the request will be forwarded to the subnet from where the destination PC will reply with the physical address using a unicast packet. After this, the conversation can happen using TCP/IP.
ARP poisoning is used to poison the local cache of the victim that enables the attacker to sniff the data that is travelling between the two victims. The attacker intercepts the traffic and then forwards it to the other side. Refer to the following illustration:
We can poison the local ARP cache of both the victims and can achieve the same. There is one more thing you need to configure: IP forwarding on Kali so that your attacking machine would be able to transfer the traffic back and forth without any loss or without letting the victims get suspicious. Follow these steps to achieve ARP poisoning:
- First, configure IP forwarding using the
echo '1' > /proc/sys/net/ipv4/ip_forwardcommand. - Once this is configured, you can go ahead and send unsolicited ARP reply packets to both the victims for poisoning the cache. Before we poison it, let's take a look at how they look in normal form, for both the victim machines:
Figure 7.4: Windows server cache
To populate entries in
linux arpcache use similar commands; refer to the following screenshot for reference.
Figure 7.5: Apple cache
- Now, let's start sending unsolicited ARP reply packets to the Windows server machine that Apple machine is located at
00:0C:29:5D:A7:F7. The same packet would be sent to the Apple machine that the Windows server machine is located at00:0C:29:5D:A7:F7. If you notice, the MAC address specified in the packets sent to the Windows and Apple machines belongs to Kali (the attacker). Refer to the following screenshot to check out the command I used for the spoofing fake MAC addresses:
Figure 7.6: ARP reply packets sent to the Windows server on behalf of the Apple device
Figure 7.7: ARP reply packets sent to Apple device on behalf of the Windows server
Using a one-liner command with few parameters, we were able to poison the victim's cache by sending numerous ARP reply packets.
- The traffic generated due to the preceding command was also captured at the same time. Let's see how it looks. Refer to the following screenshot:
- Once multiple number of such packets are received by both of the victims, they will start believing it and accordingly will update the cache. Let's have a look at both the machine caches to verify this. Refer to the following screenshots:
Figure 7.8: Poisoned window's cache
Figure 7.9: Poisoned Apple's cache
- Now, whatever traffic is sent between these two devices will be forwarded through the attacking box. For verification purposes, I turned off the Windows server machine and tried sending ICMP packets from the Apple machine. Refer to the following output shown for the ICMP destination host unreachable replies coming from
192.168.1.106(Kali):
The preceding output assures that the packets are being forwarded through
192.168.1.106, hence making our ARP poisoning attack a success. - Now, the question is how to secure yourself from such attacks. The best thing I would suggest is to make manual entries for the device's MAC address in the local cache of the communicating client. This will definitely ignore unsolicited ARP reply packets while modifying the local cache. Refer to the following screenshot:
Figure 7.10: Adding a static entry to local ARP cache
Once you add a static entry in every possible host in your network, it won't be possible then to modify the local cache using the arp spoof tool. Similarly, for HTTPS traffic, you can use the SSL strip tool available online in order to sniff secure traffic.