Understanding Address Resolution Protocol Attacks Copyright (c) 2006 cijfer <cijfer@netti!fi> All rights reserved.

Table of Contents 1 About this paper 2 Introduction to ARP 2.1 What does ARP mean? 2.2 The purpose of ARP cache 2.3 How ARP works 2.4 Protocol flaws 3 ARP attack methods 3.1 Terms & definitions 3.2 Connection hijacking & interception 3.3 Connection resetting 3.4 Man in the middle 3.5 Packet sniffing 3.6 Denial of service 4 References & links 4.1 Documents 4.2 Software & programs 5 Greets 1 About this paper In this particular paper, i will be discussing accordingly a basic introduction to understanding Address Resolution Protocol (ARP) as well as several methods of attack. These methods . in no specific order . include detailed explanations for hijacking and resetting a users connection and/or session, man in the middle attacks, packet sniffing on switched environments, and denial of service attacks (DoS). Concluding the introduction and other sections, i will give several links to documents, software, and such to help aid in further reference of ARP. 2 Introduction to ARP 2.1 What does ARP mean? Address Resolution Protocol (ARP) . a stateless protocol . was designed to map Internet Protocol addresses (IP) to their associated Media Access Control (MAC) addresses. This being said, by mapping a 32 bit IP address to an associated 48 bit MAC address via attached Ethernet devices, a communication between local nodes can be made. On a majority of operating systems . such as Linux, FreeBSD, and other UNIX based operating systems, and even including Windows . the "arp" program is present. This program can be used to display and/or modify ARP cache entries. By simply running "arp -na" in your terminal, a list of current entries in the local ARP cache will show. This includes IP addresses, hardware types, MAC (HWaddress) addresses, flag masks, associated NIC interfaces, and link types (output may vary depending on system).

An example of the "arp" utility's output would look like the following: Windows: > arp -a Interface: 192.168.1.100 .- 0x10003 Internet Address Physical Address 192.168.1.1 00-13-10-23-9a-53

Type dynamic

Linux: $ arp -na ? (192.168.1.1) at 00:90:B1:DC:F8:C0 [ether] on eth0 FreeBSD: $ arp -na ? (192.168.1.1) at 00:00:0c:3e:4d:49 on bge0 You will notice also that on the Windows example, the Type for that particular entry is labeled as "dynamic". Dynamic entries in the ARP cache are eligible to be purged from the cache. This is avoidable if the entry is labeled as static or permanent which is self explanatory by its name. I will get into static ARP entries near the end of this paper. 2.2 The purpose of ARP cache As stated in section 2.1, the Address Resolution Protocol was designed to map IP addresses to MAC addresses. ARP uses a cache to keep track of these addresses in a table known as the ARP cache. The ARP cache . like any other cache . has data stored only temporarily. The average amount of time that data is stored in this cache, is normally between 1 minute to 10 minutes. The Time to Live (TTL) however can be much greater than that, such as with Cisco routers, which have an estimate TTL of 4 hours. Each system has a different TTL period until non-permanent data is cleared - Previous cache entries which are obsolete and not used waste space and have no purpose being there. Therefore, entries are either updated or purged from the cache completely. As stated, the ARP cache has a job to maintain ARP replies and data. To reduce the amount of ARP cache entries, the ARP cache updates with the newly received IP addresses and corresponding MAC address. It does this as a method of reducing network traffic. If i were to map the hardware address of another node on my local network, the ARP cache holds its entry in the cache so i do not have to continuously map it out during my communication. 2.3 How ARP works Specifically for Internet Protocol Version 4 (IPv4), ARP maps IP addresses between the Network layer and Data Link layer of the Open System Interconnection (OSI) model. The Data Link layer is split into two sublayers, The Media Access Control layer, and the Logical Link Control layer. The MAC layer has the power to control access to data flow and whether or not transmission is permitted. The Logical

Link Control layer's job however is to control frame synchronization, packet flow (like MAC), and error checking throughout data packets. These two sublayers work together to create the Data Link layer. The next step for successful packet transmission is the most important. Transmission itself. The Network layer provides the switching and routing by transmitting data between nodes on a network. Not only is packet transmission a part of this layer, but also addressing, internetworking, error handling, and packet sequencing. This layer ensures that each packet is sent accordingly to their final destinations without errors and possible collision. For a more complete and thorough explanation of how address resolution works, and protocol specifics, please consult RFC 826 (David C. Plummer, 1982). RFC 826 was written in 1982 by C. Plummer, and is considered to be outdated and complicated material to the neophytes. Consult the end of this paper in section 5.1 for links to papers regarding ARP, MAC, and further discussions on ARP based attacks. 2.4 Protocol flaws ARP's main flaw is in its cache. Knowing that it is possible for ARP to update existing entries as well as add to the cache, this leads one to believe that forged replies can be made, which result in ARP cache poisoning attacks. I will discuss each type of attack in section 3 as well as terms and definitions reviewed in section 3.1. 3 ARP attack methods 3.1 Terms & definitions A. ARP Cache Poisoning Broadcasting forged ARP replies on a local network. In a sense, "fooling" nodes on the network. This can be done because ARP lacks authentication features, thus blindly accepting any request and reply that is received or sent. B. MAC Address Flooding An ARP cache poisoning attack that is mainly used in switched environments. By flooding a switch with fake MAC addresses, a switch is overloaded. Because of this, it broadcasts all network traffic to every connected node. This outcome is referred to as "broadcast mode" because, all traffic passing through the switch is broadcasted out like a Hub would do. This then can result in sniffing all network traffic. 3.2 Connection hijacking & interception Packet or connection hijacking and interception is the act in which any connected client can be victimized into getting their connection manipulated in a way that it is possible to take complete control over. Those whom may be vulnerable to this type of attack, usually connect to servers and computers via unencrypted protocols

such as Telnet or Rlogin. This can result in sniffing, as well as connection hijacking and interception. 3.3 Connection resetting The name explains itself very well. When we are resetting a client's connection, we are cutting their connection to the system. This can be easily done using specially crafted code to do so. Luckily, we have wonderful software that was made to aid us in doing so. One piece of code that is extremely easy to use to do this, is within the DSniff collection. To pull this off, we're going to use 'tcpkill'. TCPKill's usage is similar to that of TCPDump, both using BPF (Berkeley Packet Filters). Cause: 1. tcpkill 2. tcpkill 3. tcpkill 4. tcpkill 5. tcpkill Effect: 1. Kill 2. Kill 3. Kill 4. Kill 5. Kill -9 -9 -9 -9 -9 port ftp &>/dev/null host 192.168.10.30 &>/dev/null port 53 and port 8000 &>/dev/null net 192.168.10 &>/dev/null net 192.168.10 and port 22 &>/dev/null attempting to access port 21 (ftp) matching the IP '192.168.10.30' attempting to access port 53 and 8000 192.168.10.* (192.168.10.0/24) 192.168.10.* accessing port 22

connections connections connections connections connections

TCPKill is mainly used to continously keep the connection of the client cut. By simply killing the 'tcpkill' process after use, will allow the connection to become available again. If not, then the remote client will cease to be able to connect. 3.4 Man in the middle One of the more prominent ways of attacking another user in order to hijack their traffic, is by means of a Man In The Middle (MITM) attack. Unlike the other attacks, a MITM is more a packet manipulation attack which in the end however does result in packet redirection to the attacker . all traffic will get sent to the attacker doing the MITM attack. This attack however is specific. As opposed to MAC Address Flooding or other attacks against a router/switch, the MITM attack is against a victim, and also can be done outside of a switched environment. Thus meaning, an attack can be executed against a person on the other side of the country . to be more thorough. Downsides of a MITM attack is the fact that the victim must be connected via an unencrypted protocol. Utilities such as Telnet, and Rlogin can be attacked via MITM attacks. There also is the possibility of executing a MITM attack against encrypted protocols . such as SSH - but I will not get into that in this paper. A MITM attack could be of great use on operating systems such as SunOS/Solaris and IRIX, due to the fact that one of

the main modes of connection to these operating systems happens to be Telnet and Rlogin. Rarely do i see the older versions of these operating systems using SSH. A basic MITM attack consists of an attacker, victim and the target/destination that the victim is communicating with. Using a visual representation of this attack would be a lot more confusing, so I'm just going to subtly explain what is occurring when doing this specific attack. But before i begin explaining that, we need to do one thing: Enable IP forwarding if not already default. Linux: # echo 1 > /proc/sys/net/ipv4/ip_forward Other: # sysctl -w net.inet.ip.forwarding=1 -ORedit /etc/sysctl.conf To double check whether or not IP forwarding is enabled, you can simply do the following commands: Linux: # cat /proc/sys/net/ipv4/ip_forward Other: # sysctl -A | grep net.inet.ip.forwarding If the value is set to "1", then IP forwarding is enabled. Continuing on, we're going to do this also using third party utilities. A suggestion for easy usage would be using the "arpspoof" utility by Dug Song within his DSniff package. One of the good reasons about the "arpspoof" utility, is the fact that its extremely simple to use and requires only two arguments. Information needed in order to use it, is the Victim's IP address, and the Target/Destination IP address that Victim is trying to authenticate with. With these two IP addresses, we can continue with our MITM attack. A simple example of what "arpspoof" will do is as followed: 1. Communicate with Victim saying that you're Destination. 2. Communicate with Destination saying that you're Victim. This can be easily done by using the following syntax via "arpspoof" and two open terminal windows. But before i get into that, i just want to make clear about the example IP addresses being used: Setup: Attacker (IP: 2.2.2.2) Victim (IP: 1.1.1.1) <-> Target (IP: 0.0.0.0) Term A: # arpspoof -t 1.1.1.1 0.0.0.0 &>/dev/null & # arpspoof -t 0.0.0.0 1.1.1.1 &>/dev/null &

Term B: # dsniff | less -OR# ngrep host 1.1.1.1 | less -OR# tcpdump host 1.1.1.1 and not arp | less If everything went successfully, then by using one of the three optional programs in Term B, you should be able to sniff all traffic that is being sent between Victim and the Target/Destination. If at all something did not go as planned, then there could be several reasons. One reason could be that the Victim has static ARP tables . which deny the overwriting of entries within the ARP cache table. Another possible reason could be a detection system of some sort such as ARPWatch which is an ethernet/ip monitoring system. As a reminder, this specific MITM attack will not work on encrypted protocols . explained in this section at paragraph 2. 3.5 Packet sniffing Sniffing on a Local Area Network (LAN) is quite easy if the network is segmented via a hub, rather than a switch. The sole difference, is that a switch is organized when sending packets, thus entitled "switch" because it switches packets between destinations respectively. A hub on the other hand broadcasts packets throughout the entire network blindly and freely without any specific destination. It is of course possible to sniff on a switched environment by performing a MAC flood attack. This is vaguely explained in section 3.1b on MAC Address Flooding. As a result of the MAC flood, the switch will act as a hub, and allow the entire network to be sniffed. This gives you a chance to use any sort of sniffing software available to you to use against the network, and gather packets. A few popular sniffing software and programs include: DSniff by Dug Song, LinSniffer (one popular version is LinSniffer 0.666 by humble of rhino9), PHoss by FX and Ettercap by Alberto Ornaghi, and Marco Valleri. Example output from PHoss: [root@genii sniff]# ./PHoss PHoss (Phenoelit's own security sniffer) (c) 1999 by Phenoelit (http://www.phenoelit.de) $Revision: 1.13 $ >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Source: 192.168.1.100:40895 Destination: 72.14.0.99:80 Protocol: HTTP Data: asrtrin:manheim >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Source: 192.168.1.105:46537 Destination: 72.14.0.99:21 Protocol: FTP Data: buddy:holly

[...] Example output from TCPDump 3.9.4 (output is not identical): [root@genii sniff]# tcpdump -vvX port 21 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes [...] 00:45:40.370082 IP (tos 0x0, ttl 111, id 43980, offset 0, flags [DF], proto: TCP (6), length: 57) localhost.pirhana > localhost.ftp: P, cksum 0x434b (correct), 1:18(17) ack 38 win 17483 4500 0039 abcc 4000 6f06 79e6 44ad 954f E..9..@.o.y.D..O 5056 bbb9 11f9 0015 6595 ed3d 6f7f 82e1 PV......e..=o... 5018 444b 434b 0000 5553 4552 206d 7975 P.DKCK..USER.myu 7365 726e 616d 650d 0a sername.. [...] Note that we now have a username, which is 'myusername'. [...] 00:45:42.467487 IP (tos 0x0, ttl 111, id 43985, offset 0, flags [DF], proto: TCP (6), length: 57) localhost.pirhana > localhost.ftp: P, cksum 0x3e34 (correct), 18:35(17) ack 72 win 17449 4500 0039 abd1 4000 6f06 79e1 44ad 954f E..9..@.o.y.D..O 5056 bbb9 11f9 0015 6595 ed4e 6f7f 8303 PV......e..No... 5018 4429 3e34 0000 5041 5353 206d 7970 P.D)>4..PASS.myp 6173 7377 6f72 640d 0a assword.. [...] And now a password, which is 'mypassword'. But is this login a valid one? [...] 00:45:42.473412 IP (tos 0x0, ttl 64, id 53228, offset 0, flags [DF], proto: TCP (6), length: 62) localhost.ftp > localhost.pirhana: P, cksum 0xae1b (correct), 72:94(22) ack 35 win 5840 4500 003e cfec 4000 4006 84c1 5056 bbb9 E..>..@.@...PV.. 44ad 954f 0015 11f9 6f7f 8303 6595 ed5f D..O....o...e.._ 5018 16d0 ae1b 0000 3533 3020 4c6f 6769 P.......530.Logi 6e20 696e 636f 7272 6563 742e 0d0a n.incorrect... [...] It was not :(. But we'll know when we get a valid one :)). 3.6 Denial of service Denial of service is just lame. Try not to do it unless you absolutely must unless for penetration testing. Denial of service is self explanatory. Denial of service attacks can occur when large amounts of unsolicited packets are targeted against a specific host and/or optionally on specific ports. This may result in the remote node to panic and close the port (denying its service), or even shutting down the entire system - possibly a reboot. As explained in section 3.1b, MAC Address Flooding can be

considered a Denial of service attack. The main idea of the MAC flood, is to generate enough packet data to send toward a switch, attempting to make it panic. This of course will cause the switch to drop into broadcast mode and broadcast all packet data. This however did not result in a crash, or the service to be dropped, but to be overloaded. For further information on MAC Address Flooding, please read back to section 3.1B on its definition. 4 References & links 4.1 Documents 1. http://ietf.org/rfc/rfc826.txt 2. http://networksorcery.com/enp/protocol/arp.htm 3. http://man.he.net/?topic=arp&section=all 4.2 Software & programs 1. 2. 3. 4. 5. 6. 7. 8. ARP0c2 Dsniff Ettercap Hunt Ngrep PHoss Shijack Tcpdump http://phenoelit.de/arpoc/ http://monkey.org/~dugsong/dsniff/ http://ettercap.sourceforge.net/ http://packetstormsecurity.org/sniffers/hunt/ http://ngrep.sourceforge.net/ http://phenoelit.de/phoss/docu.html http://securiteam.com/tools/5QP0P0K40M.html http://tcpdump.org/

5 Greets x80, thank you for proof reading. _EOF_