=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ARP: Your Ethernet Card's Best Friend by BarKode (barkode@sysfail.org) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This document is meant to be an introduction to the ARP protocol. It assumes that you are somewhat familiar with TCP/IP networking. On the Link Layer of the 7-Layer OSI Network Model, you'll find ARP, standing by itself off in a corner. This seemingly out-of-the-way protocol is actually essential for most network communication to take place, as it translates logical addresses (in this case, IP) to Hardware Addresses. ARP stands for Address Resolution Protocol, and for this document, we'll speak of ARP as it applies to a standard IPv4 TCP/IP network. ARP is responsible for resolving the 48-bit ethernet address associated with your 32-bit IP address. Your ethernet card doesn't care, nor does it even know what its IP address is. It just has a 48-bit address assigned to it, most often hard coded into the firmware. Your IP address however, can change any time, while your ethernet address stays the same. Hence, your IP-based network needs to know how to find which machine to send its IP packets to. ARP is the way. Let's say for this document your ethernet card has a hardware address of 00:00:2b:04:a9:11 and your IP address is 198.162.1.1, and you are on a class C network. When a machine on the network wants to initiate an IP-based connection, it first needs to find out the hardware address of the remote machine. ARP steps in and sends an ARP REQUEST, asking the network who has the IP address it's looking for. Let's say you are trying to connect to 192.168.1.2. Running tcpdump you might see this: 00:00:2b:04:a9:11 ff:ff:ff:ff:ff:ff arp 60: arp who-has 192.168.1.2 tell 192.168.1.1 Let's look at this packet. The first section is our hardware address. The second section is the broadcast hardware address of the network. This packet is sent to every machine listening asking each where this IP is. The third identifies the packet as being an ARP packet. The fourth is the size of the ethernet frame, padded to its minimum 60 bytes. The rest is fairly straightforward, asking "Which machine on this network has 192.168.1.2 assigned to them? Please tell 192.168.1.1 your hardware address." Now let's look at what this packet looks like on the network. Ethernet Header .-------------------------------. |Ethernet Dst|Ethernet Src|Frame| | Address | Address |Type | | | | | `-------------------------------' 6 bytes 6 bytes 2 bytes .--------------------------------------------------------------. | Hard|Prot|Hard|Prot|Op|Sender Eth|Sender|Target Eth|Target IP| | Type|Type|Size|Size| | Address | IP | Address | Address | | | | | | | | | | | `--------------------------------------------------------------' 2 2 1 1 2 6 4 6 4 The numbers below the fields represent the number of bytes in the field. This ARP request is 28 bytes in length. The Ethernet header contains the 48-bit ethernet address of the sender and the recipient, in this case, the recipient being the broadcast address. The 2-byte Frame Type field specifies that this is an ARP request or reply with the value 0x0806. The Hardware Type and Protocol Type fields specify the type of hardware address and type of protocol address, respectively. This would be a 1 for ethernet in this case, and an 0x0800 for for IP addresses, again respectively. Hard Size and Prot Size are related information, containing the size of the hardware address and protocol address contained in the following fields. In this case we have a 48-bit ethernet address (6 bytes) and a 32-bit IP address (4 bytes). The OP field specifies what type of service this packet is. It can be any of the following: 1 - ARP Request 2 - ARP Reply 3 - RARP Request (Reverse ARP, not covered in this article) 4 - RARP Reply For now assume Reverse ARP is a machine asking other machines for it's own IP. Since this field is a request, the target ethernet address is not included, as that is the information we are looking for. When the remote host recieved the broadcast request, it recognizes the IP as being its own, and replies: 00:00:4b:2a:01:04 00:00:2b:04:a9:11 arp 60: arp reply 192.168.1.2 is-at 00:00:4b:2a:01:04 When the machine requesting the information gets this packet, it can now open the connection to the remote machine. This entire process on a 10Mbit network may take about 3ms. The packet sent back is formatted as the first packet, with different values in the fields. 1. The Ethernet header is formed with its own information. 2. The OP type is changed to 2, ARP reply. 3. The source and destination fields are completed with the information as expected, i.e. its own IP and hardware addresses. 4. The packet contains the hardware address of the machine with the IP address originally asked for in the request. But what about machines on other networks accessed through gateways? Well, ARP requests will not be made for machines not located on the local network. Instead, packets will be forwarded to a next-hop router (gateway) for delivery to another network. I recommend running tcpdump on your network often and watch what's going on. This is a good way to get a preliminary look into what's really going on when that light on the hub is blinking. :) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ARP Part II: Hypothetical Hijacking Situations and Denial of Service Attacks by BarKode (barkode@sysfail.org) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This issue we'll delve into ProxyARP, and Gratuitous ARP, and also dig a bit into some hypothetical local ethernet TCP session hijacking situations. I'll be assuming you've read part one, or already know the premise of ARP while you read this article. For this article, let's use the following network map (I suck at ascii drawings). Assume the machines on the top are using a Class C netmask of 255.255.255.0, and that the machines on the bottom are on an 8-IP subnet in the same class C network, using a netmask of 255.255.255.248. 10.10.10.1 10.10.10.2 10.10.10.3 ____________ ____________ _____________ | | | | | | | illusion | | oblivion | | abyss | |__________| |__________| |___________| | | | ethernet --------------------------------------------------------------------------- | ________|________ | Cisco 2514 | | cube | | 10.10.10.253 | |_______________| | | <-- serial dial-up | has ip 10.10.10.250 ______|______ | | | cirrus | |___________| 10.10.10.201 ethernet | --------------------------------------------------------------------------- ______|_____ | | | pulsar | 10.10.10.202 |__________| I) Proxy ARP Proxy ARP is an implementation of ARP on a machine that allows it to answer ARP requests on one network for machines on another one of it's networks. We'll start off like this. Wayne wants to dial in to his corporate network and have access to all of the machines. Wayne has a few machines at home, so he sets himself up an 8-IP netblock (10.10.10.200-208) at work, then goes home and dials into work. The modem at work picks up and establishes a connection, giving an IP address to his machine, we'll say 10.10.10.250. The router at work has been configured to route requests for Wayne's network to Wayne via his dial-up interface. But the other machines on the network don't know that his machine isn't on the local network. As far as the other machines are concerned, his subnet is still covered by their netmask, hence on their local network. So if Illusion needs to send a packet to Pulsar, Illusion is going to look at Pulsar's IP address and consider Pulsar to be on the local network, and make an ARP request. Pulsar doesn't get that ARP request. This is where Proxy ARP comes in. The Cisco router (Cube) is going to get that ARP request, and notice that the IP in question is an IP connected to one of its serial ports. Cube is going to respond and say that Pulsar is located at its own hardware address. Illusion will then start sending packets to Cube, and Cube will forward them to Pulsar. This operation is totally transparent to Illusion. As far as its concerned, Pulsar is sitting next to it on the wire talking back and forth. Gory details? No problem. Illusion sends an ARP request looking for Pulsar. 0:0:b4:03:F2:02 FF:FF:FF:FF:FF:FF ARP 60: arp who-has 10.10.10.202 tell 10.10.10.1 Cube gets the ARP request and responds with its own HW address. 0:0:0c:3b:a3:4e 0:0:b4:03:F2:02 ARP 60: arp reply 10.10.10.202 is-at 0:0:0c:3b:a3:4e Then Illusion starts sending packets to Cube, and Cube forwards them to Pulsar. If you were to then view the ARP table on illusion, you would find that Pulsar and Cube both share the same hardware address. 2) Gratuitous Arp A very important feature of ARP is Gratuitous ARP. Seemingly minor, Gratuitous ARP is essential for several reasons. It happens when a machine asks the network for its own IP address, hence: 0:0:B4:03:F2:02 FF:FF:FF:FF:FF:FF ARP 60: arp who-has 10.10.10.1 tell 10.10.10.1 This accomplishes several things. One being that if there is another machine on the network that has the same IP, it will respond back saying so, and alert the user that there is a duplicate IP on the network. There is another situation. One feature of ARP is that it will automatically update its ARP cache if it recieves a broadcast ARP request from a machine that already has an entry in it's ARP table. More specifically, say you down one interface on a machine, put your ethernet cable into another card, and up that interface. When that interface comes up, the first ARP broadcast it sends will automatically update the arp caches of the machines on the local network with its new hardware address. Same IP, different Hardware address, because it's a different ethernet card. Now, the rest of the machines will start sending data to that hardware address instead of the previous one. That's kind of neat, now isn't it? If you send an ARP request with an IP attached to it in the "tell" field, the rest of the machines on the network will automatically assume you are that IP and send you packets. But of course they will! That's what ARP does! Resolves IP addresses to hardware addresses. Now we get to the part where ARP starts to cause trouble. 3) Denial of service attacks How you ask? Well, the last paragraph back there should give you some ideas. Here's some questions: * What would happen if you wrote a program that replied to every ARP broadcast with its own hardware address? A few things. If you wrote a program that replied to every ARP broadcast with your IP, you'd have machines on the network (especially Windows machines, whoo boy) confused about who's the Real McCoy. If your entry was the latest in a machine's ARP cache, you would get packets destined for machine whose identity you have assumed. Considering this is local ethernet, you'd get the packets anyway, but they'd have the other machine's IP plastered onto your ethernet address. This would cause all sorts of problems as the machines fought about who's who. This is one style of a Denial of Service attack, however it's not very efficient. * How can I use ARP to hijack someone's TCP/IP session? Say Illusion was talking to Abyss with a telnet session, and you wanted to assume Illusion's place in the conversation. You are currently using Oblivion. You could write a program to hijack the connection by somehow (network congestion, crashing Illusion somehow, unplugging it, whatever) getting Illusion off of the network, and assuming its identity by using ARP to tell Abyss that Illusion's IP is now located on Oblivion's hardware address. Abyss can pick up right where it left off and send the next waiting packet, which your program has already been ready to recieve. You are now talking to Abyss via telnet, and the upper-layer protocols never missed a beat. This is not a very technical description of session hijacking. I'm aiming this article at people that aren't extremely familiar with the concept. * How can I use ARP as a Denial of Service attack? One way to use ARP as a DoS attack is to respond to gratuitous ARP requests with any hardware address. Since gratuitous ARP is often sent at bootstrap time, attacking this can cause a variety of problems. Windows NT machines have been known to pop up a dialog box saying "Windows has detected a duplicate IP address at HW address: #:#:#:#:#:#. The interface has been disabled.". NT then proceeds to down the interface until it is brought back up by hand, and the interface sometimes can not be brought back up as long as there is another machine on the network with the same IP. This has happened to me personally before, however since it was years ago I'm not sure what version of NT besides that it was 4.0 that this occured on (Service Packs, etc). Try giving your UNIX machine an IP that's the same as your NT machine, boot your NT machine and check what happens. * How secure is ARP? ARP is about as secure as crotchless underwear on a glass floor. There is no security involved with ARP directly besides ethernet switching (or "Smart Hubs"), which helps prevent sniffing and other problems by knowing what hardware address is coming in on what port on the switch. If you have access to broadcast ARP, you can cause damage to your local ethernet. ARP wasn't designed to be secure. It's a trusted protocol, stateless in design. There is no connected status, it's just broadcast packets and one-packet replies. There's no authentication involved. ******************************************************************************* Conclusion ---------- This is just an introduction to ARP. ARP is a fundamental protocol on networks today. Mapping logical addresses to physical addresses is essential with the protocols we use. As more and more people get onto the internet, and we start to lean towards IPv6, we should be seeing some changes come along in major protocols, ARP included. Steps have been taken to keep ARP in check, such as switching. These steps are nescessary to keep co-locations facilities, ISPs, and businesses' communications a bit more secure. If everyone at a co-location facility was on a big hub, colissions, sniffing and IP spoofing would be a bigger problem. Plugging everyone into a different interface on a router would get expensive, so switching is the way to go. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ARP Part III: Network Attacks and Denial of Service by BarKode (barkode@sysfail.org) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- You glared at part one, chuckled at part two, and now we have part three of the ARP trilogy. Today we learn how all that seemingly boring techno-babble in the first two articles affects the security of your local ethernet, and we'll cover the basics of some network attacks, and the always fun good o' session hijacking. Prerequisites for reading this: 1) You have read part one and two several times and have a good understanding of the content, or are already familiar with ARP. 2) You have some idea about how IP-based networks function. Acknowledging that, take into consideration that while this covers what most would consider intermediate IP networking theory, I'm going to focus this article towards those who probably have only read part one and two and have a basic idea of how IP networks function. Also, know that what we're talking about here is 50% implementation specific and 50% protocol specific. While the general ideas here are sound and are applicable in some way to IP networks of any type, every implementation is slightly different, and you will experience that a method that may work fine on one operating system may not work at all on another. For instance, ARP caching techniques vary from platform to platform, so methods on a Linux machine with static ARP entries compared to a Cisco router are totally different. *************************** (Note: For all these examples, there are no switches, smart hubs, etc., implemented on the network in question.) (Note 2: If you wish to actually do some of what you see here, I suggest grabbing a copy of send_arp, an ARP forging application that's been floating around the net, and I've modified it a bit. It should be on www.sysfail.org soon after this article is published. If not, e-mail me.) Situation 1: You are on a ethernet at a small office. Another employee has picked up a copy of 2600 from the local Barnes and Noble. After spending 3 days OCRing code out of the book, he has managed to compile a copy of teardrop on the only Linux box at the office (the dial-up server, "RAS"). He thinks it's really funny to crash the unpatched print server all day whenever you need to queue up some invoices. Knowing that he's telnetting into the machine and logging in as root, and also knowing that his machine is the only machine in the office that has access to do that, you figure it would be just keen to somehow trick the server into thinking that you are coming from Joe's machine. Situation 1 Low-Down: We need to spoof a connection from "joe" to "server", and we are on "tom". We need to not take "joe" off the network or cause any funny messages to pop up on the screen. Here's our network layout: Full Class C: 192.168.0.x Netmask: 255.255.255.0 ------------------------------------------------------------------------------ | | | | | | | | * * * * Printer Server Tom Joe 192.168.0.5 192.168.0.1 192.168.0.2 192.168.0.3 (Linux) (Linux) (Windows) (0:0:0:0:0:01) (0:0:0:0:0:02) (0:0:0:0:0:03) You have made the intelligent choice to install Linux on your other drive on "tom". Your network is working fine, and you can communicate with all your other machines. Somehow, you need to make "server" think that you are telnetting to it from "joe". You've already sniffed the unencrypted root password "hork" from the local ethernet. Let's take a look at what happens when joe telnets to server. **** 0:0:0:0:0:03 ff:ff:ff:ff:ff:ff 0806 42 arp who-has 192.168.0.1 tell 192.168.0.3 0:0:0:0:0:01 0:0:0:0:0:03 0806 60 arp reply 192.168.0.1 is-at 0:0:0:0:0:01 0:0:0:0:0:03 0:0:0:0:0:01 0800 62: 192.168.0.3.1029 > 192.168.0.1.23: S 21441998:21441998(0) win 8192 (DF) (ttl 128, id 32010) 0:0:0:0:0:01 0:0:0:0:0:03 0800 58: 192.168.0.1.23 > 192.168.0.3.1029: S 2811556923:2811556923(0) ack 2144199 win 32736 (ttl 64, id 175) *** What we have here are four separate packets initializing a telnet session. First packet: ARP request: get HW address of IP to connect to Second packet: ARP reply: Here's the hardware address requested from "server" Third packet: I want to telnet to you, you listening? Fourth packet: Sure thing bro, acking your port 23 request, let's go. We're not concerned about the latter two packets, just the first two. The ARP request/reply pair. If we can somehow convince server that it wants to send packets destined for "joe" to "tom", we're in business. Sounds easy enough, and in a way that's true. But there are several obstacles to overcome. You might say, "let's just assume the IP address of joe." That won't work. You'll have two machines responding to the same IP address, you really don't want that. You don't want a message on either box complaining that there's duplicate IPs on the network either. When your machine sees a packet go by, it checks the hardware address stamped on the ethernet packet header. If it's not a match, the packet isn't for us, and we don't care about it. More specifically, the device driver never looks at the destination IP, just the HW address (of course, there are exceptions where some drivers dig more into the packet for various purposes). This can be taken advantage of in numerous ways, and for ARP attacks, it can really come in handy. If we ifconfig up an interface on "tom" with the IP address of "joe", and tell "server" that "joe"'s IP address is located at "tom"'s Hardware address, then server should send packets destined for "joe" to "tom", and it will also accept packets from "tom" thinking that it's "joe", bypassing the IP-based security implemented on "server". Ok. Read that again. * We tell SERVER that the IP address of JOE is really located at the HARDWARE ADDRESS of TOM. Function: Packets from SERVER to JOE will be encapsulated on the ethernet with headers sending it to TOM instead of JOE (instead of the header including the ethernet address of JOE, it will have TOM'S address instead. This means JOE will ignore the packet while TOM will recieve it. SERVER will not know that TOM isn't JOE, because TOM is talking with JOE's IP). How: We send a hand-crafted ARP packet (reply specifically, it can be a request, but we'll get into that another time. The packet would look like this on the wire: 0:0:0:0:0:02 0:0:0:0:0:01 0806 60 arp reply 192.168.0.3 is-at 0:0:0:0:0:02 TOM SERVER ARPREPLY IP OF JOE HWA OF TOM Now, if you try to telnet to SERVER from TOM, you should be able to connect, and it will allow you to log in as root. But wait! We lit up a message on the Windows box on Joe's desk saying that there's an IP address conflict on the network! Busted! There are several things you must take into account: 1) You need to "ifconfig -arp eth:" and set up static ARP entries and routes when you do this. You don't want that interface speaking ARP to anyone unless you make it but you need it to know where to send packets. 2) Doing this *during* an existing session between JOE and SERVER will cause that connection to drop, unless you work fast. 3) You need to be constantly sending poison ARP to SERVER *and* JOE during your attack. As long as you keep telling both machines where to find (er, where you WANT them to find) each other, they won't *ask*. And the less they ask, the better. Situation 2: I want to hijack joe's session to server. How can this be done using ARP as a tool? First off, remember what we said about accidently cutting off Joe's session earlier? Well now that's exactly what we want to do. During a conversation between JOE and SERVER, you inject poison ARP, telling SERVER that you're JOE, and telling JOE that SERVER is the printer or something. Then, you proceed to send a flood of spoofed ACKs to the SERVER, pushing the sequence numbers out of JOE's acceptable window, and by the time JOE finds out what happened, you've already got his end of the connection, and SERVER hasn't even noticed anything funny (I'm not going to cover the insides of TCP sequence numbers today, that's another article. :) ). How this happens: * JOE is talking to SERVER * TOM assumes JOE's IP address. * TOM sends out an ARP reply unicast to JOE saying SERVER is-at 0:3:1:3:3:7 or something, then immediately send a packet to SERVER saying that JOE is-at 0:0:0:0:0:2 (tom's real HW address) * To be on the safe side, you push the sequence numbers of the session way out of JOE's acceptable range. * JOE is a Windows box and doesn't know what the hell is going on. He's just sending packets looking for SERVER and probably grinding the hard drive or showing a little animated paperclip that says "Click here to learn more about session hijacking" which just points to a broken link on microsoft.com. * Meanwhile, TOM is re-synching the connection to SERVER, and as far as SERVER is concerned, the connection was just broken for a moment, and now is better, and will gladly talk to TOM in the place of JOE, considering that the IP is right and that TOM's HW address maps to that IP in the arp table on SERVER. * JOE is still a Windows box and at this point Windows telnet will bring up a message like "Lost Connection" and probably lock up telnet because it's so poorly coded and has no emulation and... anyway.... * TOM has full control over the connection and SERVER couldn't be happier about it. JOE just sits there and plays a neat screen saver and grinds the hard drive every couple minutes. I will probably be writing an article specifically on this topic, as I'm not going to cover this more specifically in the scope of this article. Situation 3: I just picked up 2600 at Barnes and Noble. I want to be a hacker. My 6th grade computer teacher is a real dork and I want to make the network not work right n stuff. I tried mashed potatos in the power outlets but I got in trouble. What can I do? Well, good news for you. ARP can cause all sorts of problems on a network. If you haven't figured out how this is possible yet, I'm not sure what to tell you, read the article again and maybe you'll think of a way you could make computers on a network not able to talk to each other using ARP. I hope you enjoyed, and should you have any questions, email me. -bk Billy: "Mom! Sally hijacked my irc session and made me say stuff!" References: I. "TCP/IP Illustrated, Volume 1: The Protocols" W. Richard Stevens, January 1994. (Addison-Wesley Professional Computing Series). ISBN:0201633469 II. "Playing redir games with ARP and ICMP" MESSAGE THREAD: document sections reviewed were authored by Yuri Yolobuev