Professional Documents
Culture Documents
By
B Gautam K Varma
ID NO. 2010H112035G
Under the supervision of
Dr. S K Sahay
Assistant Professor, CS & IS Department
CERTIFICATE
This is to certify that the Dissertation entitled, Prevention of ARP Spoofing using
Cryptographic Techniques and submitted by B Gautam K Varma, ID No.2010H112035G in
partial fulfillment of the requirement of BITS G629T Dissertation embodies the work done
by him under my supervision.
Date
II
ABSTRACT
Dissertation Title:
Supervisor:
Dr. S K Sahay
Semester:
Second
Name of Student:
Abstract: Address Resolution Protocol (ARP) is the most important protocol for host
communication within a Local Area Network. ARP Spoofing or Cache Poisoning pose some
serious problems to the protocol by wrongly associating IP addresses to the MAC addresses
of malicious hosts, thus giving way to a wide range of attacks such as Denial of Service
(DoS) attacks and Man In Middle (MiM) attacks. This work looks into the aspects of
prevention of ARP spoofing by different mechanisms which include detection of spoofing
using tools, modification of DHCP protocol and various cryptographic solutions to ensure
authenticity to ARP replies.
III
Table of Contents
Abstract
. iii
Table of Contents . iv
List of Figures v
1. Introduction 1
1.1. The Address Resolution Protocol ... 1
1.2. Message Format of ARP . 2
1.3. Working of ARP . 3
1.4. ARP Spoofing and Cache Poisoning .. 5
2. Cryptographic Techniques in Prevention of ARP Spoofing ..... 7
2.1. Challenge Response Authentication .............................. 7
2.2. One Way Hashes
......................... 9
IV
List of Figures
14
1. Introduction
Local Area Networks running TCP/IP over Ethernet are the most common
networks these days. Each host on such a network is assigned an IP address (32 bits).
Hosts also possess a network interface card (NIC) having a unique physical address (48
bits) also called the MAC address. For the final delivery of any packet destined to some
host, its MAC must be known to the sender. Thus, the Address Resolution
Protocol(ARP) is used to resolve an IP address into a MAC address. Resolved addresses
are kept in a cache so as to avoid unnecessary work for already resolved addresses every
time they are needed. Resolution is invoked only for entries expired or absent from the
cache, otherwise cache entries are used.
Sender Hardware Address: Layer 2 (MAC Address) address of the device sending the
message.
Sender Protocol Address: The protocol address (IP address) of the device sending the
message
Target Hardware Address: Layer 2 (MAC Address) of the intended receiver. This field
is ignored in requests.
Target Protocol Address: The protocol address (IP Address) of the intended receiver.
Step 5: When the targeted device checks the Target Protocol Address, it will find a
match and will generate an Address Resolution Protocol (ARP) reply message. It takes
the Sender Hardware Address and the Sender Protocol Address fields from the Address
Resolution Protocol (ARP) request message and uses these values for the Targeted
Hardware Address and Targeted Protocol Address of the reply message.
Step 6: The destination device will update its Address Resolution Protocol (ARP) cache,
since it need to contact the sender machine soon.
Step 7: Destination device send the Address Resolution Protocol (ARP) reply message
and it will not be a broadcast, but a unicast.
Step 8: The source machine will process the Address Resolution Protocol (ARP) reply
from destination, it store the Sender Hardware Address as the layer 2 address of the
destination.
Step 9: The source machine will update its Address Resolution Protocol (ARP) cache
with the Sender Hardware Address and Sender Protocol Address it received from the
Address Resolution Protocol (ARP) reply message.
Man-in-the-middle (MITM) attacks: By spoofing two hosts in the network at the same
time, an attacker can silently sit in between the two hosts so that they think they are
communicating with each other. This attacker is then able to listen to all the traffic sent
in both directions. This attack can also be performed between any host in the LAN and
an outside host, as the attacker can perform the attack between the host and the default
gateway. With a MITM attack, the attacker can gain access to sensitive information
(e.g., passwords) or he/she can even modify the data being sent, compromising the
datas integrity.
Note that these attacks are not restricted to Ethernet networks. Hosts using
other Layer 2 protocols like 802.11 are also susceptible to ARP poisoning attacks.
offered information, thus proving that it was able to decrypt the challenge. For instance,
in Kerberos, the challenge is an encrypted integer N, while the response is the encrypted
integer N + 1, proving that the other end was able to decrypt the integer N. In other
variations, a hash function operates on a password and a random challenge value to
create a response value.
Such encrypted or hashed exchanges do not directly reveal the password to an
eavesdropper. However, they may supply enough information to allow an eavesdropper
to deduce what the password is, using a dictionary attack or brute-force attack. The use
of information which is randomly generated on each exchange (and where the response
is different from the challenge) guards against the possibility of a replay attack, where a
malicious intermediary simply records the exchanged data and retransmits it at a later
time to fool one end into thinking it has authenticated a new connection attempt from the
other.
Authentication protocols usually employ a cryptographic nonce as the
challenge to ensure that every challenge-response sequence is unique. This protects
against a replay attack. If it is impractical to implement a true nonce, a strong
cryptographically secure pseudorandom number generator and cryptographic hash
function can generate challenges that are highly unlikely to occur more than once. It is
important not to use time-based nonces, as these can weaken servers in different time
zones and servers with inaccurate clocks.
Mutual authentication is performed using a challenge-response handshake in
both directions; the server ensures that the client knows the secret, and the client also
ensures that the server knows the secret, which protects against a rogue server
impersonating the real server.
Preimage resistance:
Given a hash h it should be difficult to find any message M such that h= hash(M)
Second-preimage resistance:
Given an input message m1, it should be difficult to find another input m2 where
m1m2 such that hash(m1) hash(m2). This property is sometimes referred to as
weak collision resistance
Collision resistance:
It should be difficult to find two different messages m1, m2 such that
hash(m1)=hash(m2). Such a pair is called a cryptographic hash collision. This
property is sometimes referred to as strong collision resistance. It requires a hash
value at least twice as long as that required for preimage-resistance, otherwise
collisions may be found by a birthday attack.
The two most commonly used cryptographic hash functions are MD5 and SHA-1. MD5
digests have been widely used in the software world to provide some assurance that a
transferred file has arrived intact. For example, file servers often provide a pre-computed
MD5 (known as Md5sum) checksum for the files, so that a user can compare the
checksum of the downloaded file to it. Unix-based operating systems include MD5 sum
utilities in their distribution packages, whereas Windows users use third-party
applications.
One way hashes can be used to authenticate the ARP replies in the following
way. Here, each host will be having Passcode(PC), PassNo(PN) combinations for every
other host in the network. These pairs are securely distributed among the hosts. The
process of verification is as shown below
10
Step 3: Host 1 challenges Host2 with a Random number and a Pass No. intended
for that particular host.
Step 4: Host2 responds to the challenge by sending the message digest which
includes the random number received, its Pass Code and its MAC address.
Step 5: Host1 computes its own digest from the Pass No., Pass Code information
it has and the MAC address it received earlier.
Step 6: Host1 adds the IP, MAC association to its cache if both the digests are
same; else it will discard the received MAC address.
11
12
One time Passwords can therefore be used authenticate the sender in ARP
implementation scenario. Here, each host will be having Pass Key (PK) list for N no. of
transactions for every other host in the network. These Pass Keys will be used as OTP
for every transaction between two particular hosts. These Pass Key lists will be securely
distributed among hosts initially. By using OTPs, we can successfully avoid replay
attacks. The sequence of authentication is as shown below
13
Step 3: Host 1 challenges Host2 with a Pass No. intended for that particular host.
Step 4: Host2 responds to the challenge by sending the Pass Key (PK) for that
particular Pass No.
Step 5: Host1 verifies the Pass Key received to the Pass Key it has in its list.
Step 6: Host1 adds the IP, MAC association to its cache if both the Pass Keys are
same; else it will discard the received MAC address.
14
It must verify the author and the date and time of the signature.
Digital signatures often use a public key encryption system. Public-key cryptography
refers to a cryptographic system requiring two separate keys, one to lock or encrypt the
plaintext, and one to unlock or decrypt the cypher text. Neither key will do both
functions. One of these keys is published or public and the other is kept private. If the
lock/encryption key is the one published then the system enables private communication
from the public to the unlocking key's owner. If the unlock/decryption key is the one
published then the system serves as a signature verifier of documents locked by the
owner of the private key. Although in this latter case, since encrypting the entire
message is relatively expensive computationally, in practice just a hash of the message is
encrypted for signature verification purposes.
15
16
Step 2: Host2 encrypts it MAC and IP association first with its Private Key and
then the Public Key of Host1.
Step 3: Host1 decrypts the message first with its Private Key and then the Public
Key of Host2
It should be noted that only Host1 will be able to read the correct MAC, IP association
as the initial decryption needs its own Private Key, which is available with only Host1.
Thus digital signatures ensure both confidentiality and integrity.
Several solutions that involve cryptography to authenticate the ARP packets
have been proposed. S-ARP [9] proposes a solution to the ARP poisoning problem
based on an extension of the ARP protocol. It introduces a set of functionalities that
enable an integrity and authenticity check on the content of ARP replies, using
asymmetric cryptography. Secure ARP extends ARP with an integrity/authentication
scheme for ARP replies, to prevent ARP poisoning attacks. In order to maintain
compatibility with ARP, an additional header is inserted at the end of the protocol
17
standard messages to carry the authentication information. This way, S-ARP messages
can also be processed by hosts that do not implement S-ARP.
An 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.
In S-ARP all reply messages are digitally signed by the sender with the
corresponding private key. At the receiving side, the signature is verified using the host
public key. If the public key of the sender host is not present in the receiving host key
ring or the one in the key ring does not verify the signature, the public key of the sender
is requested from the AKD. The AKD sends it to the requesting host in a digitally signed
message. S-ARP adopted the Digital Signature Algorithm (DSA) as the signature
algorithm.
TARP [10] addresses the lack of authenticity in ARP replies by distributing
centrally generated attestations. These attestations, called tickets, authenticate the
association between IP and MAC addresses through statements signed by the Local
Ticket Agent (LTA). Each ticket encodes a validity period represented as a start time
and an expiration time. Of course, the use of time values assumes some form of loose
clock synchronization between the issuing LTA and the validating clients.
To securely perform address resolution using TARP, a host broadcasts an
ARP request. The host with the requested IP address sends a reply, attaching a
previously obtained ticket. The signature on the ticket proves that the LTA issued it, i.e.,
the IP-to-MAC address mapping is valid (or at least was at the time of issuance). The
requesting host receives the ticket, validating it with the LTAs public key. If the
signature is valid, the address association is accepted; otherwise, it is ignored. With the
18
introduction of TARP tickets, an adversary cannot successfully forge a TARP reply and,
therefore, cannot exploit ARP poisoning attacks.
Goyal et al. [11] proposes a solution for the prevention of ARP cache
poisoning based on a combination of digital signatures and one time passwords. This
protocol requires periodic generation of digital signatures, the rate of generation being
independent of the number of ARP requests being received. For this, we identify two
different components of an ARP reply, one is the <IP address, MAC address> mapping
and the recency of the mapping. The first component requires a digital signature since
the <IP, MAC> mapping must be authentic and its authenticity must be publicly
verifiable. The idea of this solution is to use the same digital signature again and again
in ARP replies for a long time.
Here one option could be to trust the ARP reply for recency and the only
check performed on the content of replies would be validation of the digital signature.
But then an attacker could get hold of that digital signature by simply sending an ARP
request to the target system and getting it in reply. It could then wait for the target
19
system to go down or it could crash the target system using known attacks or Denial of
Service attacks. As soon as the target system goes down or gets disconnected from the
network, the attacker could change her MAC address to that of the target system and
thus receive all packets sent to it. Now, even when the target system comes up later, it
cannot claim back its MAC address and has to change it. The attacker may continue to
poison the ARP cache of other hosts using the stored digital signature and thus receive
the packet sent to the target system. Hence it [11] proposes a method to securely indicate
the recency of the mapping indicated in the digital signature. This is done by including a
One Time Password in the ARP reply.
For a host to give an ARP reply, it generates a digital signature S containing
the IP address to MAC address mapping, the local clock time and the tip of a hash chain
used for verifying one time passwords. Now, for the first 20 minutes (cache entry
validity time), the host answers ARP requests by sending S as the ARP reply. For the
next 20 minutes, the host sends S and the first one time password (first link of the hash
chain) as ARP reply and so-on. In general for the ith 20 minute slot, the host sends S and
the (i-1)th one time password as the ARP reply. The sequence of events can be
visualized as follows
Figure 9: Authenticating ARP replies using Digital Signatures and OTP in [11]
20
3. The system alerts on ARP requests that are sent to unicast addresses rather than
broadcast. Although this behavior does not comply with the (now 20 year old)
standard, there are good reasons for it. However, a genuine ARP attack does not
need to unicast ARP requests, so again, this mechanism would fail to detect an
ARP poisoning attack.
4. Snort checks all ARP packets based on a list of IP addresses and MAC addresses
supplied by the administrator. If the source IP address is on the list, the IDS will
read the corresponding MAC address from the list and compare it with the
source MAC address from the ARP packet and Ethernet frame. In case of
discrepancy, Snort issues a warning. This mechanism is only useful for small
networks, as the configuration effort is too high in any other case. There is no
way to use this functionality sensibly when faced with dynamic IP address
assignments (DHCP).
As we can observe from all the four cases, Snorts ability to detect ARP
poisoning is limited, as is the case for all Intrusion Detection Systems.
Arpwatch [4] is an open source tool for Unix platforms that monitors unusual
ARP activities. The computer running Arpwatch reads the address information stored in
each ARP packet that it sees and stores this information in a database. If the data fails to
match previously stored entries, Arpwatch mails an alert to the administrator. The
authors claim that the tool supports SNMP, although we were unable to confirm this in
our lab. Today, many networks use dynamic IP addresses assigned by DHCP (Dynamic
Host Configuration Protocol). In this kind of environment, Arpwatch will return large
numbers of false positives as it notifies users of any changed IP/ MAC mappings.
Note that, when using tools for detecting ARP attacks, by the time the
administrator notices the problem and takes appropriate measures, it may be too late as
the attacker may already have gained access to sensitive information.
22
Ethernet layer to verify whether or not the source MAC addresses in these 2 layers are
similar. An extension of the implementation of the ARP protocol would proceed to do
this verification before accepting any ARP reply packet. Any ARP packet, whose source
MAC addresses in the Ethernet layer is different from the source MAC addresses in the
ARP header, is considered a fake packet and must be discarded.
If the cross layer controller fails to resolve the ambiguity of fake packets, they
are handed over to fuzzy logic control to determine the fake packet. During the network
setup time, each host in the network collects some information about the other hosts it is
communicating with. This information includes 2 numerical values describing the Trust
Level (TL) and Importance (Im) of each host. TL indicates the trust level of the host for
example, highly trusted or not trusted at all. Im indicates the importance of the host. The
collected information is stored locally on host A. Later on, it will be used to classify
certain hosts as attackers or honests. TL and Im are completely dynamic and they adapt
to the network changes. Finally, the value Security Level (SL) is obtained as a function
of TL and Im. The packet with highest SL value among ambiguous packets is retained
and remaining packets will be discarded as fake packets.
But, the mechanism doesnt provide any specific characteristics to determine
the value of TL. This mechanism also fails when legitimate host is shut down from the
time a network boots up and the malicious host starts communicating with the host from
the start.
Some operating systems like Solaris only accept ARP replies after the entry in
the table has expired. This makes it harder for the attacker to poison the cache. Modern
operating systems like Windows and several Linux based systems, accept an ARP reply
whenever they receive one, even if they didn't send the ARP request. This is to ease the
communication in network, but they will be easily prone to spoofing attacks. Static
binding though simple, puts lot of work for the administrator to map the IP and MAC
addresses of several systems in a large network. And also such static binding won't work
in a scenario where addresses are allocated dynamically through a DHCP.
24
Design that inside the DHCP Packet, there is a Certificate that certifies the
matching between MAC Address and Public Key.
Detect whether the IP Address requester is the real MAC Address owner before
delivering the IP Address (checking from Certificate).
Design the system to have DHCP Request-MAC (to substitute ARP Request) by
sending the request directly to DHCP Server instead of enquiring by sending
Broadcast ARP Request to every Host.
Design the system to have DHCP Reply-MAC (to substitute ARP Reply). The
operation is that when a DHCP Reply-MAC appears, it needs to be checked
whether it is from DHCP Server. If it is not from DHCP Server, do not update
the value in ARP Cache.
25
26
4. Conclusion
This work presents the comprehensive view of various solutions that address
the problem of ARP spoofing. Though the usage of different tools to detect ARP
spoofing can be effective up to some level, they dont entirely prevent the problem. By
the time the administrator notices the problem and takes appropriate measures, it may be
too late as the attacker may already have gained access to sensitive information. The
schemes using modification of DHCP protocol and cryptographic techniques prevent the
problem from occurring, but they dont have the ease of implementation. Any new
protocol proposed is not easily backward compatible with existing protocols and
requires changes at every host across the network.
28
4. References
[1]. D. C. Plummer. An ethernet address resolution protocol. RFC 826, 1982.
[2]. T. Demuth and A. Leitner, ARP spoofing and poisoning: Traffic tricks, Linux
Magazine, vol. 56, pp. 2631, Jul. 2005.
[3]. Snort: The open
http://www.snort.org
source
network
intrusion
detection
system,
2006.
29