arp cache poisoning

Identification of an Intelligent Attacker in ARP Spoofing

Guided By :Prof Anish Mathuria

Presented By :Subhash Kumar Singh(201011044)

20th Nov, DAIICT

Outline

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

Basic ARP Protocol

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)

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.

Various techniques to secure ARPPort 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

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)

Working of SDE

[arp.src] <10.100.98.92, 00:00:00:00:00:0B>

ARP Req/RepHost A

10.100.98.9100: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 packetOtherwise 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.

Attacking Model[2]

● Weak Attacker - Generate fake packets. Can't modify protocol stack.

● Strong Attacker- Generate fake packets. Can also modify the protocol stack.

SDE in Weak Attacking Environment

[arp.src] <10.100.98.92, 00:00:00:00:00:0C>

ARP Req/RepHost A

10.100.98.9100: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

SDE in Strong Attacker

[arp.src] <10.100.98.92, 00:00:00:00:00:0C>

ARP Req/RepHost A

10.100.98.9100: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

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.

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.

Proposed Idea

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

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.

Working of Enhanced Technique

If there is ARP req/replyfrom any host

Mismatch in informationof received ARP packet with

ARP chacheor ARP req/reply form

IP that doesn't exist in ARP cache NoYes

Packet generated formtrue host

If source IP hasentry in ARP cache

Go for Broadcast_test()Verify the mapping present

in cache for that IP

YesNo

Verifying the mapping present in the ARP cache

Generate Broadcast ARP request for source IP of received ARP packet

any ARP responseis received

Go for Broadcast_test()

Keep the previous mapping in the ARP cache and refresh its timeout

period

YesNo

Broadcast_test()

Generate broadcast ARP Requestfor all possible IP address in LAN

Got two or moreARP reply from same

MAC address

MAC address of attacker

Legitimate <IP , MAC>mapping

NoYes

In case of Strong Attacker

[arp.src] <10.100.98.92, 00:00:00:00:00:0C>

ARP Req/RepHost A

10.100.98.9100: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

Hiding Probe Packets

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

Scheduling

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

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.

Setup, Experiment and Results

Test Bed

● LAN consist of 20 PC's.

– Gateway.

– Victim (windows XP).

– Attacker (ubuntu 10.10).● 100 Mbps Switched LAN.● Wireshark.

ARP Request traffic generated (In Internet traffic)

X – axis time in secondsY – axis Number of ARP request packet

Normal ARP Protocol

(a) Normal ARP Protocol

(b) Probe based techniques

ARP Request traffic generated (In Internet traffic)

X – axis time in secondsY – axis Number of ARP request packet

(c) Proposed Idea

System Load

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

System Load

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

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.

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.

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.

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.

Thanking You...

In case of Weak Attacker

[arp.src] <10.100.98.92, 00:00:00:00:00:0C>

ARP Req/RepHost A

10.100.98.9100: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