Arp Cache Poisoning

Thesis Defence for ARP Cache Poisoning

1. Identification of an Intelligent
Attacker in ARP Spoofing
Guided By :
Prof Anish Mathuria
Presented By :
Subhash Kumar Singh
(201011044)
20
th
Nov, DAIICT

2. Outline
●ARP Protocol
●Probe Packet based technique (eg. SDE)
●Importance of identification of attacker
●Proposed Idea
●Results
●Conclusion

3. Basic ARP Protocol

4. ARP Header
Hardware Type(2) Protocol Type(2)
HW Len(1) Pro Len(1)

Opcode(2)
Source Hardware Address(6)
Source Protocol Address(4)
Destination Hardware Address(6)
Destination Protocol Address(4)

5. Rules for Updating ARP Cache
●For creation of new entry - when an ARP
req/rep message arrive at host a new entry is
created if the cache doesn't contain any entry
for the source IP in the received ARP packet.
●Updating an entry - when an ARP req/rep
message arrive at host and the entry for the
source IP in ARP header is present then the
information in the ARP packet updated into
cache and timeout time is renewed.
●Problem : ARP can't verify the sender of ARP
request/ reply packet.

6. Various techniques to secure ARP
Port Security Binding MAC Address to switch port
Enhanced ARP[10] Conflict resolution of MAC address based on voting
S-ARP[6] Signing ARP replies
TARP[7] Centrally issued ticket authentication <IP,MAC>
associations
El-Hajj et al.[3] Uses stateful ARP cache and fuzzy logic
Trabelsi et al.[9] Detection technique using trap ICMP ping packet and
analyze packets to varify the correct <IP,MAC> mapping
Kanamori et al.[1] Uses ARP request packet as confirmation probe packet
Ramachandran et al.[2]Defines types of attacker explicit and used TCP SYN
packet as confirmation probe packet

7. Probe Packet based techniques
●Such technique injects a probe packet in
order to confirm the mapping of IP
address and mac address.
●Probe packet can be anything :
– ARP packets
– ICMP packets
– TCP SYN packets
●E.g. - Spoof Detection Engine (SDE)

8. Working of SDE
[arp.src] <10.100.98.92, 00:00:00:00:00:0B>
ARP Req/Rep
Host A
10.100.98.91
00:00:00:00:00:0A
Host B
10.100.98.92
00:00:00:00:00:0B
If 10.100.98.92 is new entry for ARP cache
then send TCP SYN packet
Otherwise in case of mismatch with ARP
cache, raise the spoof alarm
eth.dst=00:00:00:00:00:0B, IP_dst=10.100.98.92, SYN
TCP SYN packet
eth.src=00:00:00:00:00:0B, IP.src=10.100.98.92, SYN/ACK
TCP SYN/ACK packet
SDE uses TCP SYN packet as probe packet.

9. Attacking Model[2]
●Weak Attacker -
Generate fake packets.
Can't modify protocol stack.
●Strong Attacker-
Generate fake packets.
Can also modify the protocol stack.

10. SDE in Weak Attacking Environment
[arp.src] <10.100.98.92, 00:00:00:00:00:0C>
ARP Req/Rep
Host A
10.100.98.91
00:00:00:00:00:0A
Host B
10.100.98.92
00:00:00:00:00:0B
If 10.100.98.92 is new entry for ARP cache
eth.dst=00:00:00:00:00:0C, IP_dst=10.100.98.92, SYN
TCP SYN packet
eth.src=00:00:00:00:00:0C, IP.src=10.100.98.92, SYN/ACK
Attacker
10.100.98.93
00:00:00:00:00:0C
TCP SYN/ACK packet
10.100.98.92 !=
10.100.98.93 so SYN
packet is silently
dropped at IP layer

11. SDE in Strong Attacker
[arp.src] <10.100.98.92,
00:00:00:00:00:0C>
ARP Req/Rep
Host A
10.100.98.91
00:00:00:00:00:0A
Host B
10.100.98.92
00:00:00:00:00:0B
If 10.100.98.92 is new entry for ARP cache
Attacker
10.100.98.93
00:00:00:00:00:0C
Arp.src<10.100.98.91, 00:00:00:00:00:0A>
Arp.dst<10.100.98.92, 00:00:00:00:00:00>
Arp.src<10.100.98.91, 00:00:00:00:00:0A>
Arp.dst<10.100.98.92, 00:00:00:00:00:00>
Arp.src<10.100.98.92, 00:00:00:00:00:0B>
Arp.dst<10.100.98.91, 00:00:00:00:00:0A>
Arp.src<10.100.98.92, 00:00:00:00:00:0C>
Arp.dst<10.100.98.91, 00:00:00:00:00:0A>
Broadcast ARP Requset for 10.100.98.92
ARP Reply ARP Reply

12. Why the Identification is Important
●Detection of attacker leaves the host
with a set of possible MAC addresses. A
victim can't determine which MAC
should be selected to associate with IP
address.

13. Problem : Limitation of Probe
packet based Detection
Techniques
●A detecting host can not resolve the
correct IP to mac address mapping in
the case of strong attacker, because a
strong attacker can modify the protocol
stack such a way that, he can generate
appropriate response for probe packets.

14. Proposed Idea

15. Enhanced Technique
●Probe Packet based detection
technique.
●ARP request packet as probe packet.
●Correctly identifies the mapping of IP
address and MAC address in both the
environments of attacker (weak and
strong attacker).

16. Assumption
●Attacker can modify his protocol stack. It
is not necessary for attacker to follow
flow sequence of packet in any protocol.
●Attcker is working in promiscuous mode.
●Attacker can't control the network
devices or communication channel.

17. Working of Enhanced Technique
If there is ARP req/reply
from any host
Mismatch in information
of received ARP packet with
ARP chache
or ARP req/reply form
IP that doesn't exist in ARP cache No
Yes
Packet generated form
true host
If source IP has
entry in ARP cache
Go for Broadcast_test()
Verify the mapping present
in cache for that IP
YesNo

18. Verifying the mapping
present in the ARP cache
Generate Broadcast ARP request for
source IP of received ARP packet
any ARP response
is received
Go for Broadcast_test()
Keep the previous mapping in
the ARP cache and refresh its timeout
period
Yes
No

19. Broadcast_test()
Generate broadcast ARP Request
for all possible IP address in LAN
Got two or more
ARP reply from same
MAC address
MAC address of
attacker
Legitimate <IP , MAC>
mapping
NoYes

20. In case of Strong Attacker
[arp.src] <10.100.98.92,
00:00:00:00:00:0C>
ARP Req/Rep
Host A
10.100.98.91
00:00:00:00:00:0A
Host B
10.100.98.92
00:00:00:00:00:0B
If 10.100.98.92 is new entry for ARP cache
Attacker
10.100.98.93
00:00:00:00:00:0C
Arp.src<10.100.98.91, 00:00:00:00:00:0A>
Arp.dst<x.x.x.x, 00:00:00:00:00:00>
Arp.src<10.100.98.91, 00:00:00:00:00:0A>
Arp.dst<x.x.x.x, 00:00:00:00:00:00>
Broadcast ARP Req Broadcast ARP Req
Arp.src<10.100.98.92, 00:00:00:00:00:0B>
Arp.dst<10.100.98.91, 00:00:00:00:00:0A>
Arp.src<10.100.98.92, 00:00:00:00:00:0C>
Arp.dst<10.100.98.91, 00:00:00:00:00:0A>
Arp.src<10.100.98.93, 00:00:00:00:00:0C>
Arp.dst<10.100.98.91, 00:00:00:00:00:0A>
ARP Reply
ARP Reply
X.X.X.X – all possible IP in the LAN

21. Hiding Probe Packets
●Generate the ARP Request traffic
according to calculated LAN parameters
mean (µ) and variance (σ
2
) from a
random MAC address.

22. Scheduling
X = µ + σ * random_fun(0,1)

23. Advantage
●Identify correct mapping in the case of
strong attacker.
●In case, legitimate host is powered off,
attacker can't do poisoning.
●Dynamic changes in mapping of a host
correctly handled.

24. Setup, Experiment and
Results

25. Test Bed
●LAN consist of 20 PC's.
– Gateway.
– Victim (windows XP).
– Attacker (ubuntu 10.10).
●100 Mbps Switched LAN.
●Wireshark.

26. ARP Request traffic generated (In
Internet traffic)
X – axis time in seconds
Y – axis Number of ARP
request packet
Normal ARP Protocol
(a) Normal ARP Protocol
(b) Probe based techniques

27. ARP Request traffic generated (In
Internet traffic)
X – axis time in seconds
Y – axis Number of ARP
request packet
(c) Proposed Idea

28. System Load
(a)System Load in Non-Promiscuous mode (core-2 processor)

29. System Load
(b)System Load in Promiscuous mode (core-2 processor)

30. Conclusion
●The proposed technique can identify the
weak and strong attacker.
●We are paying some traffic overhead but
it is not significant high.
●Proposed technique is backward
compatible.

31. References
●[1]K. Masataka, K. Takashi, and Y. Suguru, “A self-confirming
engine for preventing man-in-the-middle attack(security)(internet
technology iv),” IEICE transactions on communications, vol. 87,
no. 3, pp. 530–538, 2004-03.
●[2]V. Ramachandran and S. Nandi, “Detecting arp spoofing: an
active technique,” in Proceedings of the First international
conference on Information Systems Security, ICISS’05, (Berlin,
Heidelberg), pp. 239–250, Springer-Verlag, 2005.
●[3] W. El-Hajj and Z. Trabelsi, “Using a fuzzy logic controller to
thwart data link layer attacks in ethernet networks,” in WCNC, pp.
2547–2552, 2007.
●[4] W. R. Stevens, TCP/IP Illustrated, Volume 1: The Protocols.
Addison Wesley, 1994.
●[5] C. L. Abad and R. I. Bonilla, “An analysis on the schemes for
detecting and preventing arp cache poisoning attacks,” in
Proceedings of the 27th International Conference on Distributed
Computing Systems Workshops, ICDCSW ’07, (Washington, DC,
USA), pp. 60–, IEEE Computer Society, 2007.

32. Cont..
●[6] D. Bruschi, A. Ornaghi, and E. Rosti, “S-arp: a secure
address resolution protocol,” in Proceedings of the 19th
Annual Computer Security Applications Conference,
ACSAC ’03, (Washington, DC, USA), pp. 66–, IEEE
Computer Society, 2003.
●[7] W. Lootah, W. Enck, and P. McDaniel, “Tarp: Ticket-
based address resolution protocol,” Comput. Netw., vol. 51,
pp. 4322–4337, Oct. 2007.
●[8] Z. Trabelsi and H. Rahmani, “Detection of sniffers in an
ethernet network,” in ISC, pp. 170–182, 2004.
●[9] Z. Trabelsi and K. Shuaib, “Spoofed arp packets
detection in switched lan networks,” in SECRYPT, pp. 40–
47, 2006.
●[10] S. Y. Nam, D. Kim, and J. Kim, “Enhanced arp:
preventing arp poisoning-based man-in-the-middle
attacks,” Comm. Letters., vol. 14, pp. 187–189, Feb. 2010.

33. Cont..
●[11] B. Issac, “Secure arp and secure dhcp protocols to
mitigate security attacks,” I. J. Network Security, vol. 8, no.
2, pp. 107–118, 2009.
●[12] Z. Wang and Y. Zhou, “Monitoring arp attack using
responding time and state arp cache,” in ISNN (4), pp.
701–709, 2009.
●[13] M. V. Tripunitara and P. Dutta, “A middleware approach
to asynchronous and backward compatible detection and
prevention of arp cache poisoning,” in Proceedings of the
15th Annual Computer Security Applications Conference,
ACSAC ’99, (Washington, DC, USA), pp. 303–, IEEE
Computer Society, 1999.
●[14] V. Goyal and R. Tripathy, “An efficient solution to the
arp cache poisoning problem,” in Proceedings of the 10th
Australasian conference on Information Security and
Privacy, ACISP’05, (Berlin, Heidelberg), pp. 40–51,
Springer-Verlag, 2005.

34. Thanking You...

35. In case of Weak Attacker
[arp.src] <10.100.98.92, 00:00:00:00:00:0C>
ARP Req/Rep
Host A
10.100.98.91
00:00:00:00:00:0A
If 10.100.98.92 is new entry for ARP cache
Attacker
10.100.98.93
00:00:00:00:00:0C
Arp.src<10.100.98.91, 00:00:00:00:00:0A>
Arp.dst<x.x.x.x, 00:00:00:00:00:00>
Host B
10.100.98.92
00:00:00:00:00:0B
Broadcast requst for all possible IP
Arp.src<10.100.98.92, 00:00:00:00:00:0C>
Arp.dst<10.100.98.91, 00:00:00:00:00:0A>
ARP Reply
Arp.src<10.100.98.92, 00:00:00:00:00:0B>
Arp.dst<10.100.98.91, 00:00:00:00:00:0A>
ARP Reply
Host IP doesn't
matches with
destination IP in the
received ARP header,
so drop ARP Request
X.X.X.X – all possible IP in the LAN