A Client Side Defense
against Address
Resolution Protocol
(ARP) Poisoning
George Mason University
INFS 612, Spring 2013
Group #3 (C. Blair, N. Eisele, N. Rehman, T. Troy)
Topics
• Abstract
• ARP Introduction
• Problem
• Related Research Works
• Pros / Cons of Other Solutions
• Our Proposed Solution
• Pseudo-code
• Pros / Cons of Our Solution
• Summary
• Questions?
Abstract
• ARP Poisoning can cause loss of privacy
and security vulnerabilities
• Many scholarly works were researched,
key weakness were highlighted in their
research
• Within our constrained scope, our solution
to ARP Poisoning overcomes the
weaknesses of previously researched
solutions
ARP Introduction
• ARP is used on local Ethernet networks to map an IP
address to a MAC address
• ARP was first created in the early 80s, intended as an
efficient address resolution mechanism (security was not
a priority)
• Each host maintains their own ARP table which stores IPMAC mapping
• ARP communicates using Requests and Replies
• ARP Replies are automatically accepted without
authentication
• ARP Poisoning exploits the processing of ARP Replies
Normal ARP Exchange
Host A wishes to communicate with Host B
Host A
ARP cache is checked
ARP entry is added
ARP request is sent
ARP reply is sent
Host B
Host C
ARP entry is added
ARP Frame Packet
0
bits
32
Hardware Type
Protocol Type
Hardware Protocol Opcode (1 for Request,
Adr. Len.
Adr. Len.
2 for Reply)
Src. MAC (bytes 1-4)
Src. MAC (bytes 5-6)
Src. IP (bytes 1-2)
Src. IP (bytes 3-4)
Dest. MAC (bytes 1-2)
Dest. MAC (bytes 3-6)
Dest. IP (bytes 1-4)
ARP Cache Table
Typical OS X ARP Cache Table
Neighbor
Linklayer Address
Expire(O)
Expire(I)
Netif
10.37.129.255
ff:ff:ff:ff:ff:ff
(none)
(none)
vnic1
10.211.55.5
0:1c:42:74:3e:48
29s
29s
vnic0
10.211.55.255
ff:ff:ff:ff:ff:ff
(none)
(none)
vnic0
192.168.0.1
18:59:33:9d:5c:68
38s
38s
en
192.168.0.13
0:90:a9:b4:46:cb
expired
10s
en1
192.168.0.17
14:d4:fe:f7:e7:e
expired
expired
en1
192.168.0.18
e0:ca:94:f4:63:a7
38s
38s
en1
192.168.0.119
6c:33:a9:63:8d:aa
expired
expired
en1
192.168.0.255
ff:ff:ff:ff:ff:ff
(none)
(none)
en1
ARP Poisoning
Attacker wishes to intercept traffic to and from host A
Classic “Man-in-the-Middle” attack
Host A
Outbound traffic passes
through attacker
Router
Attacker
Inbound traffic also
passes through attacker
Gratuitous ARP to Host A
saying “I am the router”
Gratuitous ARP to router
saying “I am Host A”
Secure Server (Gouda)
• Add secure server to Ethernet
• Add Invite-Accept and Request-Reply protocols
• Protocols use:
 Timeouts to counter message loss
 Shared secrets to counter message modification
 Nonces to counter message replays
• Cons:
 Requires adding an additional secure server
and backup server
 Requires two additional protocols
 Additional communication traffic
 Permanent entries are restrictive
Enhanced ARP with Trusted Authority
(Hammouda and Trablesi)
Host A
Host B
Registers with Router using unique
10 byte “fingerprint”
If accepted, stores IP-MAC-fingerprint
information, replies with hash
Sends ARP request for Host B with
fingerprint fragment
Creates ARP Traffic database entry
Router
with ARP Request information
• Accept: Store IP-MAC-Fingerprint information
Verification
ReplyRequest
Accepted with fingerprint hash
• Reject: Fingerprint
already
in use A’s request entry,
If ok, notifies
B, removes
Reply
Rejected,
Host
must resend
and adds
an entry
for B’s
reply
• Drop: IP already registered
Sends ARP
Reply
Drop
Request, most likely spoof
Sends Verification Request, Router
removes B’s reply entry and responds
Adds Host B’s MAC Address to cache
Our Proposed Solution
• Assumptions:
1. Unsecured LAN
2. Network must use DHCP
3. DHCP Server resides on Internet Gateway box
• Constraints:
1. Can not modify Protocol
2. Can not modify any external machine (host
or router)
Our Proposed Solution
DHCP Message Format
1. Process begins at startup or user initiation.
2. Listens for a network connection and captures all DHCP
traffic from Port 68.
3. If packet is a DHCP Reply, extract the IP and MAC address for
own machine and IP address for gateway.
4. Additionally extract gateway MAC address from sender’s
frame source hardware address field.
5. Delete own ARP cache.
6. Make static entry in ARP cache with extracted information.
7. Initiate a gratuitous ARP Reply containing own information
at set intervals (default = 500 ms).
Our Proposed Solution
//call init() on host start up or manually.
init() {
boolean DHCPframeFound=false ;
Frame cFrame = new frame();
while(networkInterfaceExists) {
while(!DHCPframeFound) {
cFrame.cDHCP = UDPpacket_listener(port 68);
if (cDHCP.isDHCP_reply) {
System.delete_ARPtable();
System.addARP(STATIC, cDHCP.getGtwyIP(),cFrame.getGtwyMAC());
PacketTimer arpM = create_message_repeater(500);
arpM.sendGratuitousARP(NetIface.IP, NetIface.MAC);
DHCPframeFound=true ;
}
}
}
}
Pros & Cons
Pros:
•No additional hardware needed.
•No administrative costs.
•Theoretically easy to develop and distribute.
•Minimal computer resources required.
•Scalable.
Cons:
•Can only be used in a DHCP network.
•Requires DHCP server on the same machine as internet
gateway.
•Extra network traffic.
•Does not secure peer-to-peer communication.
•Gateway may not allow gratuitous ARP.
• A race condition could exist if an attacker continuously
attempts to poison the internet gateway’s cache with the
host’s IP and the attacker’s MAC.
Summary
• ARP was designed to be efficient.
• Our solution overcomes the weaknesses of
other solutions while preserving the
original efficiency.
Questions