Identification of an Intelligent Attacker in ARP Spoofing Guided By : Prof Anish Mathuria Presented By : Subhash Kumar Singh (201011044) 20 th Nov, DAIICT
Jun 23, 2015
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