ARP (Address Resolution Protocol) is used to located equipment within a LAN by the hardware MAC (Media Access Control). A MAC address is a preassigned to the
network hardware. It uses a 48-bit address space, so there is plenty of room to grow.
The 48-bit address space is expressed as 12 hexadecimal digits.The first six are assigned to the manufacture of the network device. For example, on my home Linux workstation, the Ethernet card MAC address is 00:04:61:9E:4A:56. Obtaining your MAC address depends on what operating system you’re running. Under Linux, an ifconfig -awill display the various information, including your MAC address. On BSD-flavored systems, a netstat -in will usually do it.The output from my workstation is shown in Figure 5.9.
Figure 5.9 The MAC Address of the Author’s Workstation
As you can see, the HWaddr field contains my MAC address. As stated earlier, the first six digits reveal the vendor of the hardware. So how do you determine the vendor, you ask? Well, it just so happens that the IEEE (Institute of Electrical and Electronics Engineers) maintains a list of vendors that is freely available at
http://standards.ieee.org/regauth/oui/oui.txt. It is a flat ASCII text file of all vendors and their related MAC prefixes. So, looking up my MAC address in that list, we see that the 00:04:61 prefix belongs to:
0-04-61 (hex) EPOX Computer Co., Ltd.
000461 (base 16) EPOX Computer Co., Ltd.
11F, #346, Chung San Rd.
Sec. 2, Chung Ho City, Taipei Hsien 235 TAIWAN TAIWAN R.O.C.
TAIWAN, REPUBLIC OF CHINA
This is the company that made my network card. While this is all interesting, you might wonder how it ties in to ARP address poisoning. Well, MAC addresses are unique among all networking hardware. With TCP/IP, the MAC address is directly associated with a TCP/IP network address. Without the association,TCP/IP packets have no way of determining how to get data from one network device to another.
All computers on the network keep a listing of which MAC addresses are associated with which TCP/IP addresses.This is known as the systems ARP cache (or ARP table).To display your ARP cache, use arp -an in Linux, or arp -enin BSD-type sys-tems. Both typically work under Linux, as shown in Figure 5.10.
Figure 5.10Display of ARP Cache in Linux
Notice that when I entered arp -en and arp -an, there were only two entries. Did you see what happened when I sent a pingrequest to my Cisco phone
(10.220.0.160) and re-ran the arp -an command? It added the Cisco IP phone’s MAC address into the ARP cache.To obtain this, my local workstation sent out what’s known as an “ARP request.”The ARP request is a network broadcast, meaning the request was sent networkwide.This is done because we don’t know
“where” 10.220.0.160 is. When an ARP request is sent, a packet is sent out saying
“Who has 10.220.0.160?” networkwide. When 10.220.0.160 receives the ARP request, it replies “That’s me. My MAC address is 00:0D:28:08:26:E9.”
The following is a Wireshark dump of an ARP request and reply:
04:04:12.380388 arp who-has 10.220.0.160 tell 10.220.0.30 04:04:12.382889 arp reply 10.220.0.160 is-at 00:0d:28:08:26:e9
As you can see, this is literally what is happening! Now that both sides have their TCP/IP network addresses associated with the MAC, they can start transferring data.
If 10.220.0.30 (my workstation) needs to talk to 10.220.0.160 (my Cisco IP phone), my workstation knows to send the data to the 00:0D:28:08:26:E9 MAC address, which is 10.220.0.160.
The underlying flaw with ARP is that in many cases it’s very “trusting” and was never built with security in mind.The basic principle of ARP poisoning is to send an ARP reply to a target that never requested it. In most situations, the target will blindly update its ARP cache. Using my Cisco IP phone and Linux workstation as an example, I can send a spoofed ARP reply to a target with the Cisco IP phone’s TCP/IP network address, but with my workstation’s MAC address.
For this simple example, I’ll use the arping2 utility
(www.habets.pp.se/synscan/programs.php?prog=arping).This utility works much like the normal ping command but sends ARP requests and ARP replies. My target for this simple example will be my default route, which happens to be another Linux machine (10.220.0.1).The command I’ll issue from my workstation (10.220.0.30) is
# arping2 -S 10.220.0.160 10.220.0.1
This -S option tells arping2 to spoof the address. So my Linux workstation will send an ARP request to 10.220.0.1 informing it that 10.220.0.160 is my worksta-tion’s MAC address. Figure 5.11 shows a screenshot from my Linux gateway.
Figure 5.11 Display from Author’s Linux Gateway
If you look closely at the first time I issue the arp -en command, the MAC address is that of the Cisco IP phone (00:0D:28:08:26:E9).This is before the arping2 spoof command was issued.The second time arp -enis run is after I’ve spoofed with arping2.You might have noticed that the Hwaddresshas changed to my Linux work-station (00:04:61:9E:4A:56). Until the ARP tables get updated, whenever my Linux gateway attempts to communicate with the Cisco phone, it’ll actually be sending packets to my workstation.
This basic example is not very useful other than in causing a very basic tempo-rary DoS (Denial of Service). While I’ll be receiving packets on behalf of the Cisco IP phone, I won’t be able to respond.This is where the Man-in-the-Middle attack comes in.