Presentation is loading. Please wait.

Presentation is loading. Please wait.

A Client Side Defense against Address Resolution Protocol (ARP) Poisoning George Mason University INFS 612, Spring 2013 Group #3 (C. Blair, N. Eisele,

Similar presentations


Presentation on theme: "A Client Side Defense against Address Resolution Protocol (ARP) Poisoning George Mason University INFS 612, Spring 2013 Group #3 (C. Blair, N. Eisele,"— Presentation transcript:

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

2 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?

3 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

4 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 IP- MAC mapping ARP communicates using Requests and Replies ARP Replies are automatically accepted without authentication ARP Poisoning exploits the processing of ARP Replies

5 Normal ARP Exchange Host A Host C Host A wishes to communicate with Host B Host B ARP cache is checked ARP request is sent ARP entry is added ARP reply is sent ARP entry is added

6 ARP Frame Packet 0 bits 32 Hardware TypeProtocol Type Hardware Adr. Len. Protocol Adr. Len. Opcode (1 for Request, 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)

7 ARP Cache Table NeighborLinklayer AddressExpire(O)Expire(I)Netif 10.37.129.255ff:ff:ff:ff:ff:ff(none) vnic1 10.211.55.50:1c:42:74:3e:4829s vnic0 10.211.55.255ff:ff:ff:ff:ff:ff(none) vnic0 192.168.0.118:59:33:9d:5c:6838s en 192.168.0.130:90:a9:b4:46:cbexpired10sen1 192.168.0.1714:d4:fe:f7:e7:eexpired en1 192.168.0.18e0:ca:94:f4:63:a738s en1 192.168.0.1196c:33:a9:63:8d:aaexpired en1 192.168.0.255ff:ff:ff:ff:ff:ff(none) en1 Typical OS X ARP Cache Table

8 ARP Poisoning Host A Attacker Attacker wishes to intercept traffic to and from host A Classic “Man-in-the-Middle” attack Router Gratuitous ARP to Host A saying “I am the router” Gratuitous ARP to router saying “I am Host A” Outbound traffic passes through attacker Inbound traffic also passes through attacker

9 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

10 Accept: Store IP-MAC-Fingerprint information Reply Accepted with fingerprint hash Reject: Fingerprint already in use Reply Rejected, Host must resend Drop: IP already registered Drop Request, most likely spoof Enhanced ARP with Trusted Authority (Hammouda and Trablesi) Host A Host B Router 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 with ARP Request information Verification Request If ok, notifies B, removes A’s request entry, and adds an entry for B’s reply Sends ARP Reply Sends Verification Request, Router removes B’s reply entry and responds Adds Host B’s MAC Address to cache

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

12 Our Proposed Solution 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). DHCP Message Format

13 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 ; } } } }

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

15 Summary ARP was designed to be efficient. Our solution overcomes the weaknesses of other solutions while preserving the original efficiency.

16 Questions


Download ppt "A Client Side Defense against Address Resolution Protocol (ARP) Poisoning George Mason University INFS 612, Spring 2013 Group #3 (C. Blair, N. Eisele,"

Similar presentations


Ads by Google