Prevention of ARP Spoofing using Cryptographic Techniques

8/10/2019 Prevention of ARP Spoofing using Cryptographic Techniques

1/34

Prevention of ARP Spoofing using Cryptographic Techniques

Submitted in partial fulfillment of the requirements of

BITS G629 Dissertation

By

B Gautam K Varma

ID NO. 2010H112035G

Under the supervision of

Dr. S K Sahay

Assistant Professor, CS & IS Department

BIRLA INSTITUTE OF TECHNOLOGY AND SCIENCE, PILANI

K. K. BIRLA GOA CAMPUS

APRIL 2012


2/34

II

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 Signature of the Supervisor

Dr. S K Sahay

Assistant Professor, CS & IS Department


3/34

III

ABSTRACT

Dissertation Title: Prevention of ARP Spoofing using Cryptographic Techniques

Supervisor: Dr. S K Sahay

Semester: Second Year: 20112012

Name of Student: B Gautam K Varma ID No.: 2010H112035G

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.


4/34

IV

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

2.3. One Time Passwords ...... 11

2.4. Digital Signatures ............... 14

3. Other Methods in Securing ARP ..................................................................... 21

3.1. Detection using Tools .............................................................................. 21

3.2. Static Binding and Stateful Cache ........................................................... 23

3.3. Modification of the DHCP ...................................................................... 25

4. Conclusion . 28

References .. 29


5/34

V

List of Figures

Figure 1: ARP Message Format ............................................................................ 2

Figure 2: ARP Multicast request and Unicast Reply ............................................ 4

Figure 3: Using Hash Function to authenticate ARP replies ................................ 10

Figure 4: S/KEY based OTP ................................................................................. 13

Figure 5: Using OTP to authenticate ARP replies ............................................... 14

Figure 6: Digital Signatures using public key encryption .................................... 16

Figure 7: Using Digital Signatures to authenticate ARP replies .......................... 17

Figure 8: Authenticating ARP replies using tickets ......... 19

Figure 9: Authenticating ARP replies using Digital Signatures and OTP ... 20


6/34

1

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.

1.1 The Address Resolution Protocol:

Hosts and applications in a network work with domain names which are

converted to the IP address by a DNS server. But once packets containing application

data arrive on the local Ethernet network of the host, they can be transmitted only if the

MAC address present in the NIC of the destination host is known to the switch. Thus a

conversion is needed from IP addresses to MAC addresses and vice versa. This

conversion is done by the Address Resolution Protocol or ARP in short [1].

ARP works as follows. When a host needs to send an IP datagram as an

Ethernet frame to another host whose MAC address it does not know, it broadcasts a

request for the MAC address associated with the IP address of the destination. Every

host on the subnet receives the request and checks if the IP address in the request is

bound to one of its network interfaces. If this is the case, the host with the matching IP

address sends a unicast reply to the sender of the request with the pair. Every host maintains a table of pairs, called theARP cache,

based on the replies it received, in order to minimize the number of requests sent on the

network. No request is made if the pair of interest is already present in the

cache. ARP cache entries have a typical lifetime of 20 minutes, after which the entry

should be refreshed.


7/34

2

1.2 Message format of ARP:

The format of ARP message is as follows

Figure 1: ARP Message Format

Following are the fields in the Address Resolution Protocol (ARP) Message Format.

Hardware Type: Hardware Type field in the Address Resolution Protocol (ARP)Message specifies the type of hardware used for the local network transmitting theAddress Resolution Protocol (ARP) message. The value for Ethernet is 1. The size of

this field is 2 bytes.

Protocol Type: Each protocol is assigned a number used in this field. IPv4 is 2048

Hardware Address Length: Hardware Address Length in the Address Resolution

Protocol (ARP) Message is length in bytes of a hardware (MAC) address. Ethernet

addresses are 6 bytes long.

Protocol Address Length: Length in bytes of a logical address. IPv4 addresses are 4

bytes long.

Opcode: Opcode field in the Address Resolution Protocol (ARP) Message specifies the

nature of the ARP message. 1 for ARP request and 2 for ARP reply.


8/34

3

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.

1.3 Working of ARP:

The following steps are involved in the working of Address Resolution Protocol

Step 1: When a source device wants to communicate with another device, source device

checks its Address Resolution Protocol (ARP) cache to find it already has a resolved

MAC address of the destination device. If it is there, it will use that address for

communication. To view your Local Address Resolution Protocol (ARP) cache, Open

Command Prompt and type command "arp -a" (Without double quotes using Windows

Operating Systems).

Step 2: If ARP resolution is not there in local cache, the source machine will generate anAddress Resolution Protocol (ARP) request message, it puts its own data link layer

address as the Sender Hardware Address and its own IP address as the Sender Protocol

Address. It fills the destination IP address as the Target Protocol Address. The Target

Hardware Address will be left blank, since the machine is trying to find that.

Step 3: The source broadcast the Address Resolution Protocol (ARP) request message to

the local network.

Step 4: The message is received by each device on the LAN since it is a broadcast. Each

device compare the Target Protocol Address (IP Address of the machine to which the

source is trying to communicate) with its own Protocol Address (IP Address). Those

who do not match will drop the packet without any action.


9/34

4

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.

Figure 2: ARP Multicast request and Unicast Reply


10/34

5

1.4 ARP Spoofing and Cache Poisoning:

ARP Spoofing or ARP Cache Poisoning is the technique in which a hosts

cache is modified to add an incorrect IP, MAC mapping to its 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.

In an ARP spoofing, the attacker sends ARP replies with fake

mappings, in an attempt to poison the ARP cache of other host(s) on the network. For

example, if the attacker wants to impersonate host X so that host Y sends data destined

to X to the attacker instead, the attacker can send an ARP reply indicating that the host

with the IP x.x.x.x has the MAC mm:mm:mm:mm:mm:mm (the MAC address of the

attacker). Since ARP is an stateless protocol, the receiver will gladly update its ARP

cache with the pairing received. Furthermore, some operating systems may

even update static cache entries with information received from unsolicited ARP

replies[2].

Even if ARP is configured to be stateful, an attacker can still perform an ARP

spoofing attack by sending a fake ICMP (Internet Control Message Protocol) echo

request to Y indicating it comes from X, but using the MAC address of the attacker.Depending on the implementation, the operating system can either use the

pairing inferred from the received Ethernet frame and ICMP packet, or it can issue an

ARP request to learn the mapping (before sending the ICMP echo reply). In the latter

case, the attacker can instantly reply to the ARP request, poisoning the cache.

The ARP poisoning attacks just described are often used as part of other serious attacks:

DoS attacks: An attacker can poison an ARP table of a host so that every packet that thehost sends is sent to the attacker instead of its real destination. In this way, the attacker

blocks the communication from the host being attacked.

Host impersonation: Instead of just dropping the packets received from the host being

attacked, the attacker can respond, impersonating any host in the network.


11/34

6

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.


12/34

7

2. Cryptographic Techniques in Prevention of ARP

Spoofing

The main problem with Address Resolution Protocol (ARP) is that, in its

unmodified implementation, it accepts the ARP replies from sender without

authenticating the message. Hence, an attacker will be able to send its own malicious

reply and host accepting it, resulting in the poisoning of its cache or ARP spoofing.

Cryptographic techniques like Hashing, Digital Signatures and One Time

Passwords (OTP) can be used along with challenge response protocols to authenticate

the reply received from a particular host. Thus the host will be able to differentiate

between a legitimate host and malicious host hence preventing itself from ARP attacks.

2.1 Challenge Response Authentication:

Challenge-response authentication is a family of protocols in which one party

presents a question ("challenge") and another party must provide a valid answer

("response") to be authenticated. The most common example of a challenge response

system is the password authentication. The server challenges the user to provide with the

correct user name and password, the client responds with the right answer, which is the

correct password. In simple terms, Challenge-Response Authentication (CRA) [12] is a

method for proving your identity over an insecure medium without giving any

information out to eavesdroppers that may enable them to identify themselves as you.

Non-cryptographic authentication is sufficient in a scenario where nobody is

likely to be eavesdropping on the communication channel to observe the password being

entered. So, the insecure channel problem is to be addressed, One way this is done

involves using the password as the encryption key to transmit some randomly-generated

information as the challenge, whereupon the other end must return as its response a

similarly-encrypted value which is some predetermined function of the originally-


13/34

8

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


14/34

9

2.2. One way Hashes:

A cryptographic hash function is an algorithm that takes an arbitrary block of

data and returns a fixed-size bit string, the (cryptographic) hash value, such that a

change to the data will definitely change the hash value. The data to be encoded is often

called the message digest. The ideal cryptographic hash function has four main or

significant properties:

It is easy to compute the hash value for any given message

It is infeasible to generate a message that has a given hash

It is infeasible to modify a message without changing the hash

It is infeasible to find two different messages with the same hash

A cryptographic hash function must be able to withstand all known types of

cryptanalytic attack. As a minimum, it must have the following properties:

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


15/34

10

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

Figure 3: Using Hash Function to authenticate ARP replies


16/34

11

Step 1: MAC request is broadcasted in the network by Host1

Step 2: Host2 unicastly replies to Host1 with its MAC address

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.

2.2. One Time Passwords (OTP):

A one-time password (OTP) is a password that is valid for only one login

session or transaction. One-time password systems are designed to counter Replay

Attacks and Key Loggers. Replay attack involves eavesdropping on network

connections to obtain authentication information such as the login IDs and passwords of

legitimate users. Once this information is captured, it can be used at a later time to gain

access to the system. The one time password system uses a secret pass-phrase to

generate a sequence of one-time (single use) passwords, each used only for one

transaction. With this system, the user's secret pass-phrase never needs to cross the

network during authentication. So, if a potential intruder manages to record an OTP that

was already used to log into a service or to conduct a transaction, he or she will not be

able to use it again since it will be no longer valid.

Several tools are available to generate One Time Passwords. Some of them

developed for Unix like systems are OTPW developed by Markus Kuhn which generates

completely random OTPs based on several system variables. Other such tool is OPIE

(One time Passwords In Everything) - An S/Key based authentication system.


17/34

12

S/KEY is also a one-time password system developed for authentication to

Unix-like operating systems, especially from untrusted public computers on which one

does not want to type the actual password. S/KEY serves the functionality to thwart any

possible replay attack by making user to use a one-time password for login, so that any

eavesdropping gives useless password information for the attacker as that information is

used for only one time. Added security is provided by the property that no secret

information need be stored on any system, including the host being protected.

S/KEY is also sometimes referred to as Lamport's scheme, after its author,

Leslie Lamport. With the widespread use of computers running SSH and other

cryptographic protocols that can secure an entire session, not just the password, S/KEY

is falling into disuse. SecurID is a related one-time password scheme that still seeswidespread use because, unlike S/KEY, it provides two-factor authentication by

requiring a physical token that cannot be easily reproduced.

There are two sides to the operation of the S/KEY one-time password system.

On the client side, the appropriate one-time password must be generated. On the host

side, the server must verify the one-time password and permit the secure changing of the

user's secret pass-phrase. An S/KEY system client passes the user's secret pass-phrase

through multiple applications of a secure hash function to produce a one-time password.

On each use, the number of applications is reduced by one. Thus a unique sequence of

passwords is generated. The S/KEY system host verifies the one-time password by

making one pass though the secure hash function and comparing the result with the

previous one-time password.


18/34

13

Figure 4 : S/KEY based OTP

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


19/34

14

Figure 5: Using OTP to authenticate ARP replies


Step 2: Host2 unicastly replies to Host1 with its MAC address

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.


20/34

15

2.3. Digital Signatures:

A digital signature is a cryptographic scheme for demonstrating the

authenticity of a digital message or document. A valid digital signature gives a recipient

reason to believe that the message was created by a known sender, and that it was not

altered in transit. Digital signatures can be used to authenticate the source of messages.

When ownership of a digital signature secret key is bound to a specific user, a valid

signature shows that the message was sent by that user. Digital signatures also ensure

integrity of the message, because any change in the message after signature will

invalidate the signature. Non-repudiation, or more specifically non-repudiation of origin,

is an important aspect of digital signatures. By this property an entity that has signed

some information cannot at a later time deny having signed it.

In situations where there is not complete trust between sender and receiver,

something more than authentication is needed. The most attractive solution to this

problem is the digital signature. The digital signature is analogous to the handwritten

signature. It must have the following properties:

It must verify the author and the date and time of the signature.

It must to authenticate the contents at the time of the signature. It must be verifiable by third parties, to resolve disputes.

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.


21/34

16

Figure 6: Digital Signatures using public key encryption

RSA is the best known, and by far the most widely used general public key

encryption algorithm, and was first published by Rivest, Shamir & Adleman of MIT. It

is the most widely accepted and implemented general-purpose approach to public-key

encryption. It is based on exponentiation in a finite (Galois) field over integers modulo a

prime, using large integers (eg. 1024 bits). Its security is due to the cost of factoring

large numbers.

Digitally signed replies can be exchanged between the hosts to ensure

confidentiality and authenticity. Therefore digital signatures can be used in ARP request

reply scenario to authenticate the ARP replies. One way of doing it is to use asymmetric

cryptography technique. One such case is mentioned here. Each host will be having its

own Public Key (PU) and Private Key (PR) and also the Public Keys of all other hosts

which are distributed securely initially.


22/34

17

Figure 7: Using Digital Signatures to authenticate ARP replies

The sequence of authentication is as follows


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


23/34

18

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 distributingcentrally 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


24/34

19

introduction of TARP tickets, an adversary cannot successfully forge a TARP reply and,

therefore, cannot exploit ARP poisoning attacks.

Figure 8: Authenticating ARP replies using tickets in TARP [10]

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 mapping

and the recency of the mapping. The first component requires a digital signature since

the 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


25/34

20

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 chainused 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 ith20 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]


26/34

21

3. Other Methods in Securing ARP

Various other schemes are proposed in securing the Address Resolution

Protocol against ARP Spoofing or Cache Poisoning. These schemes can be categorically

divided into 3 groups.

1. Detection using Tools

2. Static Binding and Stateful Cache

3. Modification of DHCP

3.1 Detection using Tools:

Specialized tools like Snort[3] and arpwatch[4] are used to snoop the network

and report abnormalities to the administrator. These tools are very lightweight and

widely available, but it depends on the network administrator being able to differentiate

between non-malicious events and ARP cache poisoning attacks, and also on his/her

ability to take appropriate and timely measures when an attack occurs.

Snort is a prominent example of a network IDS. The Intrusion Detection

System helps administrators detect attacks on the network at an early stage so they can

launch countermeasures. Snort has an Arpspoof preprocessor with four detection

mechanisms:

1. For each ARP request it detects, the Arpspoof preprocessor validates the source

address in the Ethernet frame against the source address in the ARP packet. If

these two addresses do not match, it issues a warning. ARP poisoning does not

imply using different addresses in these fields, which means that the attack

would go unnoticed.2. For ARP replies, a comparison of the source and target addresses is performed. If

one of these address pairs does not match, Snort issues a warning. Again, this

will not detect ARP poisoning, although it does catch Proxy ARPon the other

hand, this technique is typically legitimate and involves one machine answering

ARP requests on behalf of another machine.


27/34

22

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.


28/34

23

3.2 Static Binding and Stateful Cache:

Static binding of the IP address and the MAC address in the ARP cache and

not modifying them is the most obvious solution to the ARP Spoof problem. But, this

doesn't work for a dynamic network where systems are allotted with different IP

addresses by the DHCP server every time the network is rebooted. Various

implementations of ARP have different 'cache holding times', meaning the time after

which a particular is invalid is different in different implementations. Such

timings can be in a range of 20 minutes to even few seconds.

ARP is a stateless protocol, it means when a host receives an ARP reply, the

stateless ARP cache will update the corresponding entry if it exists already in the ARP

cache. However, the stateful ARP cache will not update the corresponding entry unless

an ARP request has been generated before for that entry, even if the entry exists already

in the cache.

Zouheir et al. [5] discusses a new mechanism to prevent ARP spoofing. This

mechanism uses a stateful ARP cache and a Fuzzy Logic controller along with Cross

layer Controller to prevent malicious hosts from corrupting other hosts ARP caches

with fake entries. The mechanism is based on the use of a stateful ARP cache. Whenhost A generates an ARP request to get the MAC address of host B, an entry is created

in its stateful ARP cache, with the status of Waiting. Host A waits for an ARP reply,

within a predefined timeout. If an ARP reply comes, then host A waits another timeout

in order to collect other possible ARP replies sent by other hosts in the network. If host

A receives more than one ARP reply, then this means that most likely more than one

host has replied. Therefore, among those hosts, only one host is an honest host, which is

host B. The others are probably malicious hosts, performing ARP cache poisoning attack

to corrupt the ARP cache of host A.

This[5] mechanism also uses cross layer controller and fuzzy based cache to

identify the legitimate packets from fake packets. The normal ARP protocol

implementation does not make any cross layer control between the ARP layer and the


29/34

24

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


30/34

25

3.3 Modification of the DHCP:

Much research has gone into using the DHCP server in the network to

somehow mitigate the ARP Spoof attack. Some of them are mentioned below.

Pansa et al. [6] presents a design of architecture and protocols for the LAN

security preventing the process of MAC Address spoofing, ARP Spoof and MITM. Each

Network Card is designed to have a Certificate, a Private Key and a Public Key, all of

which are issued by the product vendor. A certificate is in a form of software-data which

may be available in the Card Network package, or can be downloaded from a vendor

websites. A Certificate will certify MAC Address value. DHCP is re-designed to

authenticate Network Cards before delivering IP Addresses. DHCP Server also assigned

to be the MAC-IP database center which stores the data about matching between

MAC Address and IP Address.

The following changes are proposed to the design of new DHCP protocol in this[6] work

DHCP must be added more function concerning answering the question in

resolving IP Address to MAC Address by using the existing data.

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 DHCP Request-MAC to have a Certificate which certifies the

matching between MAC Address and Public Key.

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.


31/34

26

Craig et al. [7] develops a unified framework to secure prominent networking

protocols within a single domain. It begins with a secure version of the DHCP protocol,

which has the additional feature of providing each host with a certificate. It then

leverages these certificates to secure ARP, prevent spoofing within the domain. In doing

so, it develops an incrementally deployable public key infrastructure which can later be

leveraged to support inter-domain authentication.

This proposed scheme[7] secures ARP by adding operations to the protocol.

Under this scheme, an end host transmits the regular ARP request as is done today.

However, when replying to an ARP request, it must include the certificate it obtained

from the DHCP server showing the IP and MAC binding. The requester can then verify

the certificate to confirm that the response given by the responder is accurate. Clientswould reject ARP responses that lack valid certificates.

Their modifications to ARP create a secure association between a given MAC

and IP address, preventing a host from spoofing only its MAC or its IP address.

However, the host could spoof both the MAC and IP address of another valid host. This

can be prevented in two ways: by proving authenticity in each packet or leveraging

DHCP snooping. To prove authenticity at connection establishment, a client may begin a

Diffie-Hellman exchange and sign its values. The server would then sign a message with

its own DH value. In subsequent messages, the client and server may simply use a nonce

and the secret key derived from the DH exchange to construct a message authentication

code and embed this code in the body of each message, allowing the other client to

verify its authenticity.

Some switches today employ DHCP snooping to prevent ARP cache

poisoning and IP spoofing. Essentially, such switches monitor DHCP traffic to create

allowable MAC address and IP bindings, and associate them with individual switch

ports. When a packet arriving on an interface does not match the binding, the packet is

discarded. Though effective, providing authenticity of each message incurs an additional

overhead at the end-hosts.


32/34

27

Secure Unicast Address Resolution Protocol (S-UARP) [8] extends DHCP

thus creating a new protocol which will have a DHCP+ server in the network, which not

only allocated dynamic IP addresses to the hosts, but also stores the IP, MAC

associations of each host. So, whenever a host wants to communicate with another host,

it unicastly asks the DHCP+ server for the MAC address of the receiver host.

This is a centralized protocol unlike the decentralized approach in normal

ARP. A simple example showing how the new S-UARP protocol works is mentioned in

the work[8].

1. When a host A wants to communicate to host B, it sends a S-UARP request

packet (unicast packet) to the DHCP+ server (which answers the S-UARP

packets), instead of sending a broadcast to all. It assumes that the secret hashing

key (KSA) is distributed between the client and the server, using private-public

key mechanism or any other secure mechanism.

2. The DHCP+ server encrypts the response message using DES with cipher block

chaining. Use the CBC residue (that is the last block output by CBC process) as

a message integrity code (MIC). This MIC would act as a checksum. The

plaintext message plus the MIC would be transmitted to the host (receiver) or A.

3.

Once the UARP response is received, host A checks for validity by using its

secret key. The receiver (Host A) encrypts the plaintext S-UARP_res using DES

that it received with the shared secret key and does the hashing process to

produce similar MIC sent by the server. Finally, the host A sends an encrypted

acknowledgment (ACK)KSA to the server. ACK contains the timestamp

generated by the host A to ensure that the message is fresh and is not a replay.

The new S-UARP protocol is more efficient in reducing broadcast congestion in

network, since the S-UARP request is unicast and directed to only DHCP+ server. The

protocol is also more secure and it is quite difficult for an attacker to do ARP poisoning

attack. Especially it is protected against message integrity attacks (when ARP packet

content can be modified by attacker) and masquerading attacks (when new ARP bogus

packet injection can be done by attacker).


33/34

28

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.


34/34

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, LinuxMagazine, vol. 56, pp. 2631, Jul. 2005.

[3]. Snort: The open source network intrusion detection system, 2006.

http://www.snort.org

[4]. arpwatch, the ethernet monitor program :ftp://ftp.ee.lbl.gov/arpwatch.tar.gz

[5]. Zouheir Trabelsi, Wassim El-Hajj: Preventing ARP Attacks using a Fuzzy-BasedStateful ARP Cache

[6]. Detchasit Pansa and Thawatchai Chomsiri Architecture and Protocols for SecureLAN by Using a Software-level Certificate and Cancellation of ARP Protocol

[7]. Craig A. Shue, Andrew Kalafut, Minaxi Gupta - A Unified Approach to Intra-

Domain Security

[8]. Biju Issac and Lawan A. Mohammed - Secure Unicast Address Resolution Protocol

(S-UARP) by Extending DHCP

[9]. D. Bruschi, A. Ornaghi, E. Rosti - S-ARP: a Secure Address Resolution Protocol

[10]. Wesam Lootah, William Enck , Patrick McDaniel - TARP: Ticket-based address

resolution protocol

[11]. Vipul Goyal and Rohit Tripathy - An Efficient Solution to the ARP Cache

Poisoning Problem

[12]. Challenge Response Authentication

http://fanaticmedia.com/infosecurity/archive/June10/TECH%20FOCUS.htm
http://www.snort.org/http://www.snort.org/ftp://ftp.ee.lbl.gov/arpwatch.tar.gzftp://ftp.ee.lbl.gov/arpwatch.tar.gzftp://ftp.ee.lbl.gov/arpwatch.tar.gzhttp://fanaticmedia.com/infosecurity/archive/June10/TECH%20FOCUS.htmhttp://fanaticmedia.com/infosecurity/archive/June10/TECH%20FOCUS.htmhttp://fanaticmedia.com/infosecurity/archive/June10/TECH%20FOCUS.htmftp://ftp.ee.lbl.gov/arpwatch.tar.gzhttp://www.snort.org/

Prevention of ARP Spoofing using Cryptographic Techniques

Documents

Transcript of Prevention of ARP Spoofing using Cryptographic Techniques