Many Internet users know that devices/machines on networks are identified using IP addresses. But if you're familiar with the ISO/IEC 7498 OSI model, you'll know that the recipient's IP address (OSI Layer 3) has to be enveloped with the MAC address of the recipient (OSI 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 an 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 to the client with its MAC address.
Using an ARP module, the ARP table, the client now caches the logical-to-physical address mapping. The client will map the MAC address to the IP address on its ARP table for Layer 2 enveloping.
ARP Poisoning/Spoofing
Security was not thought of in the design of this 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 is usually performed by poisoning the ARP cache record of the gateway, or even the gateway itself.
ARP Poisoning In Action
In my network, I have three machines:
The Ubuntu client knows the MAC address of the web server.
And vice versa.
For my demo scenario, I will be poisoning the ARP cache record of both the Ubuntu client and web server so I can monitor all communications between the 2 machines. 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 discover the list of machines I can perform ARP poisoning on.
Step 1: Load the sniffing module:
Step 2: Scan for hosts:
Step 3: Since I want to monitor all communications between the Ubuntu client and web server, I will have to poison both machines:
Now, the ARP cache of the Ubuntu client is poisoned:
And so is the web server's:
I can now view all communications between my two machines. 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. However, there are many tools available that aid system administrators to perform such a tedious task.
Shared by Emil Tan, Skipper & Co-Founder of Div0.
Comments