In the previous article "Tutorial on Basics of NIC, MAC and ARP"
[Reference 1], I wrote about some of the basic network terms NIC, IP
Address, MAC & ARP etc.
Here I will explain in depth about ARP Spoofing, how it can be used
to perform local sniffing and possible solutions to protect against
ARP Spoofing is one of the predominent
attacks executed in local network. This attack involves sending fake or
spoofed ARP messages onto a LAN.
It is possible to update a
host's ARP cache with false information via spoofed ARP Replies. This
technique is known as 'ARP Poisoning' and is the basis of more complex
attacks. The most dangerous amongst them is Sniffing . Poisoning can
also help in causing DoS type of attack too but here we will primilarly
focus on Sniffing the network data.
Sniffing is the term used to
describe the reading of all packets on a network segment. This is
relatively easy on a network connected via a hub as ethernet is a
broadcast medium and the attacker would only have to place his NIC in
promiscuous mode to 'sniff' all traffic on that network segment. In a
switched network this is not possible. This is because a switch builds a
table of MAC addresses and their associated ports when the switch is
powered on. When a host transmits an ethernet frame the switch examines
the destination MAC address and routes the frame to the associated port
as given in the switch table. Therefore it is not possible to sniff any
traffic on the network.
There are two methods to sniff traffic in
a switched environment using ARP Poisoning. The first is for the
attacker to send flood of spoofed ARP Replies to the switch. The switch
will process these replies, updating its routing table. If this is done
at a rapid rate the switches table will overflow and the switch will
default to broadcast all traffic to all ports like Hub. The attacker can now
'sniff' all network traffic.
The second method involves a 'man in the
middle' (MITM) style attack. I will explain this technique in detail by
aid of an example. Below is a simple network segment with three hosts in
a switched environment.
The attacker wishes to sniff all traffic
that A sends to B and visa versa. This is currently not possible as the
attacker is connected to the network via a switch. The correct IP
addresses and MAC addresses for each host are as follows:
Firstly the Attacker will poison A's ARP cache with a spoofed ARP
Reply. The ARP reply will tell A that the IP address of B now has a MAC
address of 00:00:00:00:00:04. Once A has processed the ARP Reply its ARP
cache will look like this:
Secondly the Attacker will poison B's ARP cache with a spoofed ARP
Reply. The ARP reply will tell B that the IP address of A now has a MAC
address of 00:00:00:00:00:04. Once B has processed the ARP Reply its ARP
cache will look like this:
Now whenever A sends B an ethernet frame the switch will route it to
the attackers port, this will also be the case whenever B sends A an
ethernet frame. The attacker may now 'sniff' the traffic whilst
forwarding it on to its originally desired host.
The thing to
keep in mind here is that the attacker must perform the two way
poisoning so that it can recieve the packets as well as send it to the
destination. In this way the connection will always be alive between the
two communicating hosts and the attack will perform successfully.
Detection & Mitigation
One of the solution to prevent ARP cache
from being poisoned there by protect against ARP Spoofing, is to add
static IP-MAC entries to the cache. If an ARP cache has been made static
it will not process any ARP Replies received unlike a dynamic ARP cache.
However this is not practical for large networks as the correct
IP address to MAC address association of every host would have to be
present in the cache of every host before it is made static. If one host
changed its MAC address (e.g. after replacing a NIC) all hosts ARP
caches would need to be updated manually. On windows, a login script
could automate this process however it has been reported Windows will
still accept and process ARP Replies even when the ARP cache has been
Other solution, is to use Intrusion Detection
Systems (IDS) to detect ARP Poisoning attacks. You can also use tool,
ArpWatch [Reference 2] to monitor against such ARP spoofing attacks on the local
Here is very good flash demonstration (obtained
from oxid) which will help you to understand entire 'ARP