Division Zero (Div0). Copyright © 2011-2018

All rights reserved.

ARP Poisoning using Ettercap-NG

9 Apr 2012

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).

  1. 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.

  2. Using ARP (Address Resolution Protocol), the client broadcast to its entire network a ARP query packet containing the web server's IP address.

  3. 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.

  4. 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.

 Unified Sniffing

 Scan for Hosts

 Available Victims

 Since I want to monitor all communications between the client and web server, I will have to poison both hosts.

 Selecting Targets

 Selected Targets

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.

Tags:

Share on Facebook
Share on Twitter
Please reload

RECENT POST

September 5, 2017

Please reload

CATEGORIES
Please reload

TAGS
RSS
RSS Feed