For many Internet users, we know that machines on a network are identified using IP addresses. But for some of us who are familiar with the ISO/IEC 7498 OSI model, we know there's one more step after enveloping a network packet with the recipient's IP address (layer 3). The network packet has to be enveloped with the MAC address of the recipient (layer 2) before sending it out into the network.
How Sender Determine its Recipient's MAC Address
In this example, we have two machines, a client machine (192.168.1.10) wants to send a network packet to a web server (192.168.1.2).
The client knows the web server's IP address, but it needs to know the MAC address of the web server before it can send any datagram over.
Using ARP (Address Resolution Protocol), the client broadcast to its entire network a ARP query packet containing the web server's IP address.
When the machine of the IP address stated in the ARP query packet receives it (i.e. the web server), it will reply the client with its MAC address.
Using an ARP module, ARP table, the client now caches the logical-to-physical address mapping. The client will use the MAC address as mapped to the IP address in its ARP table for layer 2 enveloping.
ARP Poisoning / Spoofing
Security is not thought of in the design of the protocol. ARP requests and replies are not authenticated. A malicious machine can poison the ARP table of the requestor by replying that the IP address as stated in the ARP query packet belongs to him/her. The moment the ARP table is poisoned, all network packets addressing to the supposedly-intended recipient will be routed to the malicious machine.
"A malicious user may leverage ARP spoofing to perform a man-in-the-middle or denial-of-service attack on other users on the network". To maximise the damage, ARP-spoofing are usually performed by poisoning the ARP cache record of the gateway, or even the gateway itself.
Demonstrating ARP Poisoning
In my network, I have three machines:
Ubuntu Client's ARP Cache
Web Server's ARP Cache
For my demonstration scenario, I will be poisoning the ARP cache records of both the client machine and network server so I can monitor all communications between the two host. On my attacking machine (running Backtrack 5 R2), I will be using Ettercap-NG to perform the ARP poisoning.
After Ettercap-NG has been started, I'll have to perform a simple network reconnaissance to load the list of devices I can perform ARP poisoning on.
Scan for Hosts
Since I want to monitor all communications between the client and web server, I will have to poison both hosts.
Launch ARP Poisoning
By now, ARP cache of both client machine and web server have been poisoned.
Ubuntu Client's ARP Cache Poisoned
Web Server's ARP Cache Poisoned
I can now view all network packets between my two victims. For example, when the client machine access the web page hosted by the web server,
I can view the HTTP request and response:
Defending against ARP Poisoning
This malicious man-in-the-middle attack can be performed in less than 5 minutes. So how can we defend against it? System administrators will have to keep a close look at the ARP cache of their devices. There are many tools available that aid system administrators to perform such tedious task.