14-12-2012, 12:34 PM
PREVENTION OF ARP CACHE POISONING BY USING SECURE ARP PROTOCOL
PREVENTION OF ARP CACHE.doc (Size: 50 KB / Downloads: 24)
ABSTRACT
Address resolution refers to the process of dynamically finding the Media Access Control (MAC) address of a computer on a network. The Address Resolution Protocol (ARP) thus provides a dynamic mapping between the two different forms of addresses: the 32- bit Internet Protocol (IP) address and the 48-bit MAC address that the data link layer uses. ARP cache poisoning is the act of introducing a specious IP-to-Ethernet address mapping in another host’s ARP cache. This results in diversion of traffic, either to a different host on the LAN or no host at all. ARP spoofing, also known as the “Man In The Middle” attack can thus be used to compromise the subnet. Even though ARP spoofing is possible only on a LAN it is still a security breach.
INTRODUCTION
IP over Ethernet networks are the most popular Local Area Networks nowadays. They use ARP, the Address Resolution Protocol, to resolve IP addresses into hardware, or MAC (Medium Access Controllers), addresses [12]. All the hosts in the LAN keep a cache of resolved addresses. ARP resolution is invoked when a new IP address has to be resolved or an entry in the cache expires. The ARP poisoning attack consists of maliciously modifying the association between an IP address and its corresponding MAC address.
As for cryptographically protected networks, the use of cryptography at network layer, e.g., by means of Secure Shell (SSH) or Secure Sockets Layer (SSL) does not protect against ARP poisoning, since such an attack is performed at the layer below. By performing ARP poisoning, an attacker forces a host to send packets to a MAC address different from the one of the intended destination, which may allow him/her to eavesdrop on the communication, modify its content, hijack the connection. Furthermore, when performed on two different hosts at the same time, ARP poisoning enables an adversary to launch a .man in the middle. (MITM) attack. With MITM attacks traffic between two hosts is redirected through a third one, which acts as the man in the middle, without the two knowing it. The MITM may simply relay the traffic after inspecting it or modify it before resending it.
In this paper we propose a solution to the ARP poisoning problem based on an extension of the ARP protocol. We introduce a set of functionalities that enable an integrity and authenticity check on the content of ARP replies, using asymmetric cryptography. We call our secure extension to ARP “S-ARP”, Secure ARP.
ARP CACHE POISONING
“Address Resolution Protocol cache poisoning” is the act, by a malicious host on the LAN, of introducing a spurious IP-to-Ethernet address mapping in another host’s ARP cache”
By forging an ARP reply, an attacker may easily change the <IP, MAC> association contained in a host ARP cache. Since each host presumes its local cache to be trustworthy, the poisoned host will send IP packets encapsulated into Ethernet frames with a bogus MAC address as destination. This way the attacker may receive all the frames originally directed to some other host. If also the cache of the real destination host is poisoned, both communication flows are under the attacker's control. The attacker realizes a two way man in the middle, where she can forward the received packets to the correct destination after inspecting and possibly modifying them. The two end points of the connection will not notice the extra hop added by the attacker if the packet TTL is not decremented.
SECURE ARP
Secure ARP extends ARP with an integrity/authentication scheme for ARP replies, to prevent ARP poisoning attacks. Since S-ARP is built on top of ARP, its specification (as for message exchange, timeout, cache) follows the original one for ARP. In order to maintain compatibility with ARP, an additional header is inserted at the end of the protocol standard messages to carry the authentication information. This way, S-ARP messages can also be processed by hosts that do not implement S-ARP, although in a secure ARP LAN all hosts should run S-ARP. Hosts that run the S-ARP protocol will not accept non authenticated messages unless specified in a list of known hosts. On the contrary, hosts that run the classic ARP protocol will be able to accept even authenticated messages. A mixed LAN is not recommended in a production environment because the part running traditional ARP is still subject to ARP poisoning. Furthermore, the list of hosts not running S-ARP must be given to every secured host that has to communicate with an unsecured one. The interoperability with the insecure ARP protocol is given only for extraordinary events and should be always avoided. It is intended to be used only during the transition phase to a full S-ARP enabled LAN.
S-ARP Protocol Overview
S-ARP provides message authentication only. No traffic confidentiality is provided as we believe that such a service should be provided at higher levels in the OSI stack, e.g., by means of IPSec or SSL or specific secure application protocols such as SSH. Furthermore, well configured layer 2 switches operating with S-ARP are sufficient to protect traffic from most of layer 2 attacks1.
S-ARP uses asymmetric cryptography. Any S-ARP enabled host is identified by its own IP address and has a public/ private key pair. A simple certificate provides the binding between the host identity and its public key. Besides the host public key, the certificate contains the host IP address and the MAC address of the Authoritative Key Distributor (AKD), a trusted host acting as key repository. Each host sends its signed certificate containing the public key and the IP address to the AKD, which inserts the public key and the IP address in a local data base, after the network manager's validation.
S-ARP Setup
The first step when setting up a LAN that uses S-ARP is to identify the AKD and distribute through a secure channel its public key and MAC address to all the other hosts. Such an operation may be performed manually when a host is installed on the LAN for the first time. On the other hand, a host that wants to connect to the LAN must first generate a public/private key pair and send its signed certificate to the AKD. Here the correctness of the information provided is verified by the network manager and the host public key together with its IP address is entered in the AKD repository. This operation has to be performed only the first time a host enters the LAN. If a host wants to change its key, it communicates the new key to the AKD by signing the request with the old one. The AKD will update its key and the association is correctly maintained. Section 3.5 explains the protocol behavior when IP addresses are dynamically assigned by a DHCP server. Once connected to the LAN, a host synchronizes its local S-ARP clock with the one received from the AKD.
CONCLUSION
The cause of ARP poisoning is the lack of message authentication, so that any host in the LAN is able to spoof messages pretending to be someone else. We propose an authentication scheme for ARP replies using public key cryptography, which extends ARP to S-ARP. Adding strong authentication to ARP messages resolves the problem, thus denying any attempt of ARP poisoning.