Towards Layer 2 Authentication: Preventing Attacks based on Address Resolution Protocol Spoofing

Transcription

1 Towards Layer 2 Authentication: Preventing Attacks based on Address Resolution Protocol Spoofing Sean H. Whalen Department of Computer Science, University of California, Davis, USA, cs.ucdavis.edu Abstract The Address Resolution Protocol provides network clients with a mapping between Layer 2 (MAC) and Layer 3 (IP) addresses. By sending forged ARP replies, attackers can launch a range of devastating attacks on virtually any Ethernet network. No widely applicable solutions exist. In this paper I discuss a novel approach to the problem, and describe its implementation in a Java-based virtual networking environment. 1. Introduction The Address Resolution Protocol (ARP) and Reverse ARP (RARP) provide Ethernet networks with a mechanism for mapping between Layer 2 (MAC) and Layer 3 (IP) addressing [1]. This mapping is essential for network operation. Applications communicate using Layer 3 addresses, but application level data is encapsulated inside a Layer 2 header before physical transmission. The switch uses the Layer 2 destination address from this header to determine the correct physical port for transmission (see Figure 1). Before a client can transmit a frame on the network, this destination address must be discovered using the only information the client currently has: a Layer 3 address. with the remote IP it wants to communicate with. If an entry exists, the current mapping is used. If an entry does not exist, an ARP request is broadcast to the local network, asking If you are IP address x.x.x.x, send me your MAC. Remote clients receive the request, and transmit an ARP reply containing their MAC if they are assigned the IP specified in the request. Forging the Layer 2 address in an ARP reply forms the basis for ARP spoofing attacks. A client will update its cache regardless of whether it has sent a prior request. The transmission of an ARP reply without reception of a request is called gratuitous ARP, and is commonly performed on device startup. ARP replies are implicitly trusted, gratuitous or not. Not only do libraries such as libnet [2] facilitate creation of forged frames and packets, but the hardware addresses of network devices are userdefinable in all major operating systems. Trust in any network address is misplaced. This paper aims to explore a possible solution to ARP spoofing. I have developed a virtual networking environment in Java which simulates a switched environment, with a configurable number of clients. Simulation requires no physical resources and enables faster development cycles, at the risk of incorrect models invalidating results. I later plan to implement the solution in an open source operating system to demonstrate its real-world effectiveness. Figure 1: Relevant ARP frame headers Every client maintains an ARP cache. An entry in the cache consists of an IP (known) and MAC (discovered) address. Before transmission of a frame, a client checks its cache for an entry associated Page 1 of 5 I have previously outlined in detail the operation of ARP spoofing in [3]. Sniffing on switches, LAN-wide denial of service, man in the middle, and connection hijacking are all made possible by abusing ARP. Tools like Ettercap [4] have made these attacks trivial to perform by even those with little networking knowledge. 2. Prevention ARP-based attacks are not easily prevented in current architectures. There are a handful of actions often recommended for mitigation. The first of these is employing static ARP, which renders entries in an ARP cache immutable. This is currently the only true

2 defense, but is impractical. Windows machines ignore the static flag and always update the cache. In addition, handling static entries for each client in a network is unfeasible for all but the smallest networks. An administrator must deploy new entries to every machine on the network when a new client is connected, or when a NIC is replaced. Furthermore, this prevents the use of some DHCP configurations which frequently change MAC/IP associations during lease renewal. The second recommended action is enabling port security on the switch. Also known as MAC binding, this is a feature of high-end switches which ties a physical port to a MAC address. This fixed address can be manually set by the administrator to a range of one or more addresses, or can be auto-configured by the switch during the first frame transmission on the port. These port/address associations are stored in Content Addressable Memory (CAM) tables [5], a hardware-based reverse lookup device. A change in the transmitter s MAC address can result in port shutdown, or other actions as configured by the administrator. However, port security is far from ubiquitous and does nothing to prevent ARP spoofing [6] (see Figure 2). Consider a man-in-the-middle attack as presented in [3]. An attacker X only needs to convince victim A to deliver frames meant for B to X, and vice versa for victim B. When sending forged ARP replies to achieve this, at no time must X forge its MAC address only the cache of the clients is manipulated. Port security validates the source MAC in the frame header, but ARP frames contain an additional source MAC field in the data payload, and it is this field that clients use to populate their caches [1]. It should be said, however, that port security does prevent other attacks mentioned in [3] such as MAC flooding and cloning, and becomes essential to the solutions I present in this paper. Without the prevention of MAC flooding, there is no use defending against ARP attacks when 100 lines of Perl can force a switch into broadcast mode [7]. Thirdly, virtual LANs (VLANs) create network boundaries which ARP traffic cannot cross, limiting the number of clients susceptible to attack. However, VLANs are not always an option and have their own set of vulnerabilities as detailed in [8]. Lastly, Arpwatch (as mentioned in [3]) allows notification of MAC/IP changes via . From experience, visually monitoring these alerts is a process prone to false positives and false negatives. Still, detection is an important step in mitigation. 3. Authenticating Layer 2 Layer 2 authentication must be approached with practicality in mind. Solutions involving hardware changes to the switch are not realistic outside of a virtual environment, and would require significant reinvestment for businesses. Changes to the client, however, only involve patching the kernel for open source systems or binary patches for closed source platforms. Cryptography requires thoughtful design. The addition of any dependency such as a key server adds a point of failure. PKI increases demands on bandwidth and processing power, both of which may be scarce in a network. It is with the above considerations in mind that I approach the problem. Figure 2: Port security fails to stop ARP spoofing Consider a machine receiving a gratuitous ARP reply. ARP is a stateless protocol, and cannot distinguish between a gratuitous reply and a reply that followed a request. If a client only accepts replies within N seconds of a request, the scope of the problem is reduced to resolving conflicting replies within this Page 2 of 5

3 interval. I propose a small degree of statefulness in ARP to achieve this reduction. Next, consider this multiple-reply conflict. A client sends a request and receives more than one reply within an N second window, both claiming ownership of the same IP (see Figure 3). Which reply can be trusted? What if one, both, or no hosts are lying? Solaris implements such a window but accepts the first reply, resulting in a race condition [9]. Without an independent authority, a client cannot make an educated decision regarding trust. Figure 3: Client cannot decide which reply to trust However, there is an entity on most networks which maintains an authoritative map between Layer 2 and Layer 3 addresses: the DHCP server. I propose using a modified DHCP server to resolve conflicting ARP replies (see Figure 4). A public and private key pair is generated for the server during installation. The public key is distributed with the address lease. When a client requires conflict resolution it consults the DHCP server, sending the IP in question and a random sequence number from 0 to 2^63-1. The server generates and signs a response. The client checks the sequence number and verifies the signature with the server s public key. If the sequence number does not match, the response is deemed a replay attack and is discarded. Figure 4: Conflict resolved by consulting server This is a simpler but cryptographically stronger approach than that taken in RFC3118, Authentication for DHCP Messages [10]. A 3118-compliant DHCP server will be used as the basis for real-world implementation. The server should be locked down on a dedicated machine, ignoring ARP frames (ifconfig arp on some platforms) and using the frame s non-payload source MAC for lease replies. 4. Implementation The virtual networking environment is written in Java. The actors in the network are a Switch, a DhcpServer, and multiple Client objects. Each runs on a separate thread, initialized by a driver class named L2Auth. The driver class sets the stage for attack, and initiates an infinite loop of client-generated traffic. Each client contains an internal ProtocolStack class which handles transmission of frames, while the main thread infinitely loops in a ServerSocket.accept() / frame processing cycle. All frames extend an abstract Frame class. These include ConnectFrame, DataFrame, ArpReply, ArpResponse, DhcpRequest, DhcpResponse, ResolutionRequest, and ResolutionResponse. Classes only contain fields relevant to the simulation, and are not necessarily RFC-compliant. Frames are transmitted over virtual wires, which I implement with real sockets. A SwitchPort class exists for each client connected to the Switch. When a client thread starts, it sends a ConnectFrame to the switch containing the IP and port of the real socket it listens on. The switch maintains a hash table of MAC/SwitchPort associations to enable delivery, analogous to a CAM table in a real switch. The virtual switch implements port security by checking the source MAC of all transmitted frames against the MAC used in the initial ConnectFrame. Clients immediately request an address from the DHCP server. The server returns a free address along with its public key, storing the MAC/IP association in a hash table. Clients send an ArpRequest before transmitting to a host for the first time. A Timer object allows reception of ArpResponse objects for 1 second after the request is sent. If multiple replies are received in this window, a ResolutionRequest is sent to the DHCP server. A side effect of this window is a fixed delay for each ARP request, but is necessary to prevent race conditions and can be fine-tuned to prevent noticeable delays. An entry in the ARP cache is made after a ResolutionResponse is received and its signature Page 3 of 5

4 verified. If a conflict is not resolved, the frame is dropped to prevent transmission to the attacker. Conflicts should always be resolvable if the DHCP server is available. The DHCP server uses the java.security package to generate a 1024-byte RSA key pair. This key length is adequate for proof of concept. Digital signatures use SHA-1/RSA [11]. The DHCP server signs the data portion of all ResolutionResponse frames using its private key. The receiving client verifies the signature using the public key obtained from the DhcpResponse frame. One client is configured as an attacker by the L2Auth driver. A client in attack mode selects two clients on the network and attempts to poison their ARP caches before performing a man-in-the-middle attack. Output for each client is logged to a file, to ease verification of the attack. Using this solution, the attacker is no longer able to poison caches with gratuitous replies. In addition, forged replies transmitted within a client s ARP request window create recognizable conflicts, and a cryptographically verifiable conflict resolution prevents the attacker s forged reply from entering into a client s cache. This solution does not address the possibility of an attacker gaining physical access to a switch or performing a denial of service on a network client or DHCP server, both of which are outside the scope of Layer 2 authentication. Source code is available from [12]. 5. Summary and Future Work Measures against ARP spoofing are essential for securing a local area network. The first step in preventing ARP-based attacks is port security, without which any client can force a switch into broadcast mode and commence sniffing. A client cannot decide on its own which remote client to trust in the event that two ARP replies are received for the same ARP request. ARP is made semi-stateful by creating a window for accepting replies. A modified DHCP server resolves any conflicts occurring within this window and signs all responses to prevent forging resolution replies. The public key used for verification is distributed alongside client address leases. The final result is the ability to authenticate a Layer 2/Layer 3 address mapping. This approach is driven by the desire for a softwareonly solution which is as compatible as possible with existing standards. The implementation exists inside a Java-based virtual networking environment, written to speed development. Attacks based on ARP spoofing were successfully prevented in the simulation. Future work involves implementation on a Linux or BSD system, and modification of a RFC3118-compliant DHCP server. Future work could address the problem in the switch hardware. Handling of ARP replies could be delegated to the switch by extending the CAM table to include IP addresses. External ARP replies could be dropped, making the switch the trusted authority for Layer 2/Layer 3 address mapping. An alternative approach to using an ARP window involves consulting the DHCP server for all ARP requests, at the cost of increased load and dependence on the server. This eliminates the possibility of duplicate replies since only the server can produce a valid signature. This would also prevent an attacker from sending a forged reply to victim B unchallenged by performing a DoS on victim A. A final idea for a simplified solution has clients use the source MAC from the frame header, and not the ARP header, to populate their cache. Since port security shuts down a port if the source MAC changes, an attacker could no longer poison caches. This approach could cause issues with certain networks, such as those using Proxy ARP [13]. Thanks to Sophie Engle for providing figures. References [1] D. Plummer, RFC826: An Ethernet Address Resolution Protocol, IETF [Online document], Nov. 1982, Available HTTP: [2] [3] S. Whalen, An Introduction to ARP Spoofing, Node99 [Online document], Apr. 2001, Available HTTP: [4] [5] A. Stemmer, CAMs Enhance Network Performance, System Design [Online document], Jan. 98, Available HTTP: Page 4 of 5

5 html [6] [7] exploits/macof.sniff.dos.switched.txt [8] S. Convery, Hacking Layer 2: Fun With Ethernet Switches, Blackhat [Online document], 2002, Available HTTP: [9] K. Watson, Solaris Operating Environment Network Settings for Security, Sun [Online document], Dec. 2000, Available HTTP: [10] R. Droms, W. Arbaugh, RFC3118: Authentication for DHCP Messages, IETF [Online document], Jun. 2001, Available HTTP: [11] FIPS PUB 180-1: Secure Hash Standard, NIST [Online document], Apr. 1995, Available HTTP: [12] [13] Cisco Proxy ARP, Cisco [Online document], Mar. 2003, Available HTTP: Page 5 of 5