Scenario & disclaimer

In this lab, we disrupt traffic by poisoning a client computers’ ARP-cache. We inject it with a ‘bad’ MAC-address, causing it to redirect traffic to us instead of the gateway.

Disclaimer;
This article is for educational purposes only. Please act responsibly. Always.

[INSERT TOPOLOGY DRAWING HERE]

Theory

By sending ARP-replies, we claim a specific IP is tied to our MAC-address. If we ‘ARP-spoof’ the gateway IP, this will make clients route traffic to us instead of the legitimate router.

Note that no ARP request is required to generate a reply packet. A computer will update it’s ARP-cache when a reply is received regardless of having sent a request first. The ARP-protocol does not validate if a reply was requested. Sending ARP ‘replies’ where no request was made is called sending ‘gratuitous’ or ‘unsolicited’ ARP replies.

Since, we’re not routing for the client by default, ARP-spoofing the gateway IP would interrupt connectivity.

We could simultaneously spoof the client and gateway IP’s by running 2 sessions in sepearate windows, telling the client that we own the gateway IP, while also telling the gateway that we own client IP. Now both ends of the of the flow would send traffic trough us while we forward it to the correct devices. This allows us to inspect traffic and does not cause a noticeable disruption from the client or gateways perspective. Note; routing has to be enabled on our machine for this to work.

Prerequisites;

1. Install dsniff on the attacker machine
   sudo apt install dsniff
   
   
2. Enable IPv4 forwarding on the attacker machine
   -> needed to prevent network interruptions
   udo sysctl -w net.ipv4.ip_forward=1

Practical demo

Scenario 1 ; normal situation

Client perspective

Scenario 2 ; flow interupted

We execute the same steps on the client, however, this time we also start sending spoofed ARP-replies while the client ping is running. You can observe what happens from the both perspectives below.

Client perspective

Hacker perspective

Meanwhile on our hacker machine, we send spoofed ARP replies.
sudo arpspoof -i [Network Interface Name] -t [Target IP] [Host IP]

Once the client receives our ARP packets, it starts directing it’s ping traffic to our machine. If we’d run a packet capture we would see the pings requests arriving at our machine.

Once we stop our session, arpspoof starts ‘cleaning up’, generating ARP packets for the correct router MAC-address.

Conclusion

It is surprisingly easy to make devices send traffic to you, once you are on the same network. Both client devices and network equipment will update their ARP-cache when you send them an ARP “reply”.

When a device has to communicate with another device within a network, the first thing that always happens is requesting the destination device’s MAC-address. The initial ARP request is sent as a broadcast packet, reaching all devices on the network. In theory, only the relevant device ever responds back with it’s MAC-address. However, in practice, anyone can send a reply packet claiming the IP belongs to any arbitrary MAC-address, even when no request is created first.

It would be easy to assume getting a reply on a request you never made would not make sense and computers would ignore this traffic. But this logic check is not built into the ARP protocol.

Finally, remediating a network against ARP-poisoning is relatively easy if you have a switch that supports the necessary features.

Coming soon;

• Remediation: DAI (Dynamic ARP Inspection)
• IPv6 equivalent attacks; unsolicited router and neighbor advertisements