1 / 16

A Client Side Defense against Address Resolution Protocol (ARP) Poisoning

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

vance
Download Presentation

A Client Side Defense against Address Resolution Protocol (ARP) Poisoning

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

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 wishes to communicate with Host B 1 ARP cache is checked Host A 5 ARP entry is added 2 ARP request is sent 4 ARP reply is sent Host B Host C 3 ARP entry is added

  6. ARP Frame Packet

  7. ARP Cache Table Typical OS X ARP Cache Table

  8. ARP Poisoning Attacker wishes to intercept traffic to and from host AClassic “Man-in-the-Middle” attack Host A 3 Outbound traffic passes through attacker 1 Gratuitous ARP to Host A saying “I am the router” Gratuitous ARP to router saying “I am Host A” 2 Router Attacker Inbound traffic alsopasses through attacker 4

  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. Enhanced ARP with Trusted Authority (Hammouda and Trablesi) 1 Registers with Router using unique 10 byte “fingerprint” Host A 9 3 2 If accepted, stores IP-MAC-fingerprintinformation, replies with hash 1 3 Sends ARP request for Host B withfingerprint fragment 8 2 4 4 Creates ARP Traffic database entry with ARP Request information Router 7 • 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 5 6 Verification Request 6 If ok, notifies B, removes A’s request entry, and adds an entry for B’s reply 5 Host B 7 Sends ARP Reply Sends Verification Request, Router removes B’s reply entry and responds 8 9 Adds Host B’s MAC Address to cache

  11. Our Proposed Solution • Assumptions: • Unsecured LAN • Network must use DHCP • DHCP Server resides on Internet Gateway box • Constraints: • Can not modify Protocol • Can not modify any external machine (host or router)

  12. Our Proposed Solution DHCP Message Format • Process begins at startup or user initiation. • Listens for a network connection and captures all DHCP traffic from Port 68. • If packet is a DHCP Reply, extract the IP and MAC address for own machine and IP address for gateway. • Additionally extract gateway MAC address from sender’s frame source hardware address field. • Delete own ARP cache. • Make static entry in ARP cache with extracted information. • Initiate a gratuitous ARP Reply containing own information at set intervals (default = 500 ms).

  13. Our Proposed Solution //call init() on host start up or manually.init() {booleanDHCPframeFound=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()); PacketTimerarpM = 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

More Related