DHCP and Resulting Theoretical Attacks

Hey Hey,

I'm sure that you all can add to this, but I'll lay out the basics for you and a few theoretical ways to disrupt DHCP.

You all know how DHCP works right? You plug into a port that's linked somewhere to a DHCP Server and you are assigned an IP Address and other vital information. Now... do you understand the down and dirty of it? For those of you that want a more technical explanation. I'll refer you to RFC 2131: DHCP. In all it's might and glory, DHCP is nothing more than an extension to BOOTP if you really want to simplify things, however I'm not going to get into an explanation of BOOTP.

I'm extremely lazy and don't feel like typing out what a DHCP Message looks like, so I'm stealing the outline from the RFC listed above. Remember that this message is transported using UDP and is encapsulated in a frame.
Code:
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Operation    | Hardware Type | Hardware Len  |   Hop Count   |
   +---------------+---------------+---------------+---------------+
   |                         Transaction ID                        |
   +-------------------------------+-------------------------------+
   |Seconds Since Process Start    |           Flags               |
   +-------------------------------+-------------------------------+
   |           Client IP Address (Used During Renewal)             |
   +---------------------------------------------------------------+
   |                   Your (Client) IP Address                    |
   +---------------------------------------------------------------+
   |                      Server IP Address                        |
   +---------------------------------------------------------------+
   |                     Gateway IP Address                        |
   +---------------------------------------------------------------+
   |                                                               |
   |                   Client Hardware Address                     |
   |                                                               |
   |                                                               |
   +---------------------------------------------------------------+
   |                                                               |
   |                       Server Hostname                         |
   +---------------------------------------------------------------+
   |                                                               |
   |                            Filename                           |
   +---------------------------------------------------------------+
   |                                                               |
   |               DHCP Options (Including Messages)               |
   +---------------------------------------------------------------+
One day, I'll make my own pretty tables like that. In the mean time, those of you that browse to the RFC will notice they actually have shorter versions in their table fields. That's because I've expanded upon them to give you a better idea of what I'm talking about.I'm not going into detail on all the fields. I'll mention two things though.The first is that there are two used values for the Operation Field... 1 and 2. 1 is BOOTREQUEST and this is used when the client sends a message to the server. 2 is BOOTREPLY and this is used when the server sends a message to the client.The second is that the Gateway IP Address is used when you are doing DHCP Relay (DHCP Server is located on another subnet... which would otherwise cause problems since routers don't forward broadcasts). If you want more information on the packet itself, I suggest you read the RFC.

Now back to where we started. So you've plugged into your network and your DHCP Server gave you an IP Address... but exactly what went on during that process? Obtaining an IP Address and the related information is actually a 5-Step process (Assuming all goes well). There are actually 8 DHCP Messages... which are located in the DHCP Options field of the packet. There are a few common points for these steps, which I would prefer to mention here, rather than continuously repeat. The DHCP Options field ALWAYS begins with the same byte sequence. This sequence is 4 octets containing the following decimal values - 99 130 83 99. Another thing to remember is the ports used for communication. The client (your computer) always sends packets to Destination Port 67/UDP. The server will respond to the client using Destination Port 68/UDP The 5-Step process is as follows:

Step 1. DHCPDISCOVER. You have plugged in your computer and the settings tell it to ask a server for an IP Address. This results in a DHCP packet with the DHCP Options field set to DHCPDISCOVER. During a DHCPDISCOVER a broadcast is sent out. Basically your computer says "I need an IP Address, who can give me one." There are two other times a DHCPDISCOVER will take place. If a computer wants to renew it's lease (Windows computers do this when the DHCP Lease has reached 50% (unicast to the current DHCP Server) of it's time and then again at 87.5% (broadcast to any listening DHCP Server). The other time it will do this is if the 5-step process fails during one of the other steps.

Step 2. DHCPOFFER. The various DHCP Servers on your network have heard your request and they reply with a set of configuration data that you can use. (Standard Information includes IP Address, Subnet Mask, Gateway and DNS Servers). This is a unicast as opposed to your clients broadcast.

Step 3. DHCPREQUEST. Your computer accepts an offer (traditionally the first offer it receives) and sends out a broadcast, telling the server it has accepted the offer. The reason for the broadcast at this point, is so that other DHCP Servers will see it and they will drop the addresses they have offered back into the DHCP Pool (You have declined their offers).

Step 4. DHCPACK. Just like any other Acknowledgement with computers. The Server says "Yes, you understood the information I gave you.. go ahead and start using it." Your computer uses the information that was supplied in the DHCPOFFER.

Step 5. DHCPRELEASE. When you are done using the IP Address, you tell the server and release your DHCP Lease. This let's the server put the address back into the DHCP Pool. You may notice that when you simply power off your computer, and don't first release the IP Address manually, that you tend to get your same IP Address when you plug back in if it's in the near future. The reason for this is that Windows (and at least some Linux flavours) don't send a DHCPRELEASE before they power down, they just shut down the connection. The DHCP Server still thinks the lease is active. So when you reconnect, it already has you matched in the Pool.

Those are the steps, however there are other DHCP Messages available from the Options field. They are:

DHCPNAK. Say your computer misunderstands the Address in DHCPOFFER or your lease has expired. The DHCP Server will send you a DHCP Not Acknowledge packet.

DHCPDECLINE. A DHCP Server is supposed to test the address availability before issuing it to you. However if the packet is lost on transit, it's possible for the Server to issue an address that is already in use. When the Client receives an offer, it will also test the address. If it finds the address is in use. It will send back a DHCPDECLINE instead of a DHCPREQUEST.

DHCPINFORM. Occasionally you'll have a PC with a static IP address, however you may want it to receive other information (Gateway, DNS Servers) from the DHCP Server. The DHCPINFORM message asks the server for Local Configuration Information only, stating that the client already has an IP Address.

That, in a nutshell, is DHCP. I realize it is much more indepth and that I could go on for ages just describing the basics, however my purpose is to make this tutorial security oriented. I just wanted to cover the basics first.


DHCP and Security

First, let's look at a security benefit of DHCP (I'm not the greatest at thinking up scenerios so give me a break, but you'll at least get the idea). You're company wants static IP Addresses on all the machines that were previously Dynamic. There's been some fishy business and they want to know the where and when of it. You could go from machine to machine and set static IPs, however if you have multiple buildings, and the PCs are spread out through-out buildings... this would take a lot of time and effort. The easiest thing to do would be to limit your DHCP Scope. You, being the good little admin that you are, have documented all the PCs distributed throughout the firm, and have a nice list of MAC Addresses. Instead of running from PC to PC, you simply enter in specific DHCP Reservations. This MAC Address always get's this IP Address. You've got Addresses in your DHCP pool leftover? That's easy to deal with... Add those IPs to your DHCP Exclude list. Your entire firm is now essentially using static IP Addresses and you never had to leave your cozy little office. This is a great benefit, you see fishy activity from an IP. You pull out your diagram and you know exactly who that IP belongs to, and in this scenerio... it makes management happy.

However, DHCP also has several security flaws. The biggest and most easily exploited is a rogue DHCP Server. Walk into an office and plug in a PC running a DHCP Server. This has happened several times at our college. The IT people can never seem to figure out how to solve this problem. You'll end up with many users assigned IP Addresses that are completely useless and because of this, they lack network connectivity to the extent that they should have it. There are two quick fixes for this. Client-side firewalls that filter port 68/UDP, only allowing DHCP Messages from known DHCP servers. The other solution is a little more pricey, however better than having firewalls on all your client PCs inside a large corporation. This solution is layer-3 switches. These switches provide for access lists, which would allow you to setup ACLs on ports 67/udp and 68/udp so that clients/server communication on those ports would be only with legitimate servers.

You could also perform in a sense, a man in the middle attack using DHCP. A software application could be generated that listened for DHCP messages. A spoofed message could then be injected into the "conversation" sending a DHCPNAK to the client or a DHCPDECLINE to the server. You could effectively stop the client from ever receiving an IP Address. The software could also listen specifically for DHCPOFFERs. As soon as it hears one (you'd have to be using hubs or have the ability to sniff through the switch). However, the attackers PC could change it's IP address to match the IP that is offered. When the client tests the availablility of the address, it will find it in use and send back a DHCPDECLINE, again this process could be repeated forever preventing the client from receiving the information it requires.

A third way to exploit a network relying on DHCP is to claim all the addresses in the pool. If you are on a smaller network that only has a single Class C range as its pool (254 usable addresses), it would be very easy to claim all those addresses from the DHCP Server. The next person who sends out a DHCPDISCOVER is going to find out that there are no addresses available for them to use. This attack could be easily initiated using pre-existing software. Even honeyd will emulate real machines and claim real addresses from the network. A method of protection against an attack like this would be to create a list of allowed MAC Addresses, if that's a feasible design for your network.

I had hoped to present you with further security related DHCP tasks (from attacking or securing points of view)... however at 3AM... I'm starting to run out of wind and coffee. I wrote this because on Tuesday I have a test on DHCP and I find the best way to reinforce information is to explain it to someone else.

I'm curious to see solutions to some of the possible attacks I have listed... I'd be very interested in seeing how people deal with this, or if people even bother to deal with this. It's my theory that most people don't consider attacks using DHCP and tend to ignore it and leave it with a fairly basic default setup. Even setting up the ACLs to ensure only legit DHCP servers are used, could be a big step towards protecting yourself and your company. Anyways, that's about it for now... Take it easy and as always dump a bunch of feedback on me... Let me know what you think.

Peace,
HT

[Edit]
I thought of a little addition that I'd like to add. Very Handy software, that every admin should implement on their network is NetReg. This requires users to authenticate and provide you with their hardware information (MAC Address) before they'll recieve a valid DHCP Address. You only have to register your hardware the first time and the database will remember you. For the most part this will keep would-be attackers at bay.
[/Edit]