Attacks on the DHCP protocol: DHCP starvation, DHCP spoofing, and protection against these techniques

Theory

To protect a network from DHCP attacks, you have to understand how a DHCP server interacts with clients. For instance, what is the relationship between the MAC address value specified in the Ethernet header and the CHADDR value in the DHCP header? Or what messages are sent only by the DHCP server to the address, and not vice versa?.. Therefore, let’s take a quick look at the basic DHCP messages and the DHCP header structure.

DHCP messages

Only four messages are required for a client and a DHCP server to get an IP address and other network parameters. To discover DHCP servers, a client configured to get an IP address automatically sends a DHCPDISCOVER message to the network (255.255.255.255) and data link (FF:FF:FF:FF:FF:FF) broadcast addresses. The IP header specifies 0.0.0.0 in the source address field of the IP packet since the client hasn’t received this parameter yet. The MAC address of the client is specified in the message source field at the data link layer.

Upon receiving a DHCPDISCOVER message from a potential client, the DHCP server offers an available IP address to it. This message sent by the server to the client is called DHCPOFFER. During the offer period, this address is reserved by the DHCP server and cannot be offered to other clients.

Suppose the client received a DHCPOFFER message from a DHCP server. It then sends a DHCPREQUEST broadcast message containing the IP address of the server that has issued the offer. This broadcast message informs other DHCP servers that the client has already accepted an offer from one of the servers. In this case, the remaining DHCP servers release the reserved IP addresses, and these addresses can be subsequently offered to other clients.

When the server receives a DHCPREQUEST message, it specifies the IP address chosen by the client in a DHCPACK message and sends it back to the client.

At this point, the client has received all the required network parameters, and the interaction process is considered completed. But in addition to these four basic messages, there are several other important ones:

• DHCPNACK is a message sent by the server to the client to notify it about a refusal to provide an IP address; and 
• DHCPRELEASE is a message sent by the client to the server to notify it that the client no longer wants to use the current IP address and the server can ‘return’ this address back to the pool of available IP addresses.

Done with basic messages. To sum up: such messages as DHCPOFFER, DHCPACK, and DHCPNAK are sent only by the server to the client. Remember this. You’ll need this information a little bit later.

DHCP header structure

Now let’s take a brief look at the DHCP header encapsulated in UDP datagrams. By the way, I forgot to mention the transport layer: in DHCP, the server and the client use UDP ports 67 and 68, respectively.

Let’s go through the most important header fields:

• op Code – specifies the message type. If the client makes a request to the server, then this field is set to 0x01; otherwise, to 0x02;
• htype – address type operating at the data link layer. For Ethernet, this field is set to 0x01;
• hlen – specifies the length of the link layer address in bytes (0x06 for Ethernet);
• xid – transaction identifier used to match requests and responses to them;
• sec – displays time that has elapsed since the moment when the client began to receive or update its IP address (in seconds);
• CIADDR – IP address of the client. This field is used if an IP address has already been assigned to the client, and its lease must be renewed;
• YIADDR – the server fills this field with the IP address offered to the client;
• SIADDR – IP address of the DHCP server when it sends response messages (i.e. DHCPOFFER and DHCPACK) to the client;
• GIADDR – IP address of the gateway agent (router) that separates the networks where the client and the DHCP server are located;
• CHADDR – specifies the MAC address of the client. This field is of special importance, remember it; and 
• Options – a variable-length field that specifies additional parameters (e.g. subnet mask, addresses of DNS servers, default gateway address, address lease time, etc.).

Hopefully, everything is clear so far. Now let’s get back to the above-mentioned CHADDR field. It’s logical to assume that the source MAC address in the CHADDR field of the DHCP header and the source MAC address in the Ethernet header (in messages sent by the client to the server) should be identical.

For normal client-server interactions, this is true. Keeping this in mind, let’s have some practice.

Testing DHCP defenses

Test system

I assembled a test system from what I had at hand:

• Cisco 2821 router;
• Cisco Catalyst 2960 switch; and 
• client PC (Kali Linux).

I run DHCP on the router to issue addresses from the following pool: 192.168.1.2-254. The switch configuration is empty (like out-of-the-box).

DHCP Starvation

Prior to delivering an DHCP Starvation attack, I must explain its principle. As you are aware, the DHCP server maintains a correspondence table that contains IP addresses assigned to clients and their MAC addresses; as a result, an IP address that has already been assigned to one client cannot be offered to another client. The idea of the DHCP Starvation attack is to ‘exhaust’ the DHCP server by sending fake DHCPDISCOVER packets with random source MAC addresses. The server will respond to these packets and reserve available IP addresses from the pool; as a result, it won’t be able to assign IP addresses to legitimate users for some time (as long as the attack is in the active phase).

I am going to use the Yersinia tool named after a deadly bacterium causing plague. In addition to DHCP, it can attack several other link layer protocols.

I select the DHCP protocol, specify the option “sending DISCOVER packet”, and start sending fake DHCPDISCOVER packets.

While the server is being flooded with fake packets, let’s examine the DHCP address pool.

As you can see, absolutely all addresses in the range 192.168.1.2-254 have been reserved by the DHCP server. As long as the flooding continues, the server won’t be able to assign addresses from its pool to new clients: the DHCP server is exhausted.

By the way, such flooding can cause a denial of service on a DHCP server. Let’s check the load on the router’s CPU:

As you can see, the load on the processor is 50%. And that’s just from DHCPDISCOVER packets (plus STP and CDP every couple of seconds)!

Rogue DHCP or DHCP Spoofing

The second attack vector targeting DHCP requires a rogue DHCP server. It’s needed to issue fake network parameters to clients (including the default gateway address) and deliver MITM attacks. From the attacker’s perspective, the best way to do this is to disable the legitimate DHCP server first, which has already been done.

Yersinia has a function called “creating DHCP rogue server.” I have to specify its parameters: address of the fake server (to provide network parameters on its behalf), range of addresses, their lease period (the longer the better), subnet mask, and – most importantly! – address of the default gateway (i.e. the PC that will sniff user traffic).

I switch the network interface of the sniffing PC to the forwarding mode, and that’s it! Client devices configured to get IP addresses automatically will send DHCPDISCOVER broadcast messages and receive network parameters from my fake DHCP server.

Below are the ICMP traffic dump (as it looks on the attacker’s machine) and the MITM attack scheme implemented against my test network.

How to neutralize DHCP attacks

Now let’s examine security technologies preventing DHCP attacks. Conditionally, they can be divided into two vectors: protection against DHCP Starvation and against DHCP Spoofing.

In most cases, attacks on the DHCP protocol are neutralized by the DHCP Snooping technology that should be used in combination with Port Security. Both technologies are implemented on switches.

Trusted and Untrusted ports

The concept of trusted and untrusted ports solves the problem associated with the sudden appearance of fake DHCP servers on the network. Trusted ports allow forwarding DHCP messages from the server. Remember the DHCPOFFER, DHCPACK, and DHCPNAK messages discussed above? A fake DHCP server won’t be able to offer its false options to clients by sending such messages if it’s located behind an untrusted port.

Trusted ports are directly connected to the DHCP server or ‘look’ at it. Accordingly, all other ports are untrusted. In my test network, only one port is trusted: G0/1.

When you enable DHCP Snooping, all ports become untrusted by default. Therefore, you have to specify a trusted port for the switch. But before doing this, make sure to enable DHCP Snooping globally and specify the VLAN it will operate in. My system uses the default switch configuration, and all ports belong to VLAN 1.

Time to run a test. I turn off the legitimate DHCP server, discard the address provided by it, and try to get an IP address from a fake DHCP server. Here’s what happens on the attacker’s PC: the fake DHCP server sees the client’s discovery messages and diligently tries to offer fake network options to it, but the client doesn’t respond to such offers.

This happens because the switch drops DHCPOFFER messages from an untrusted port; as a result, the client doesn’t see the fake offer.

Limit Rate

This is another useful feature of DHCP Snooping making it possible to limit the number of DHCP packets transmitted through the switch port per second.

To enable this function, select the entire range of untrusted ports and set the limit to ten packets per second. Cisco recommends no more than 100 packets per second, but ten is more than enough for my test system. It’s important not to restrict legitimate traffic from clients.

Another experiment: I launch a DoS attack by sending DHCPDISCOVER messages and look what happens. It doesn’t take long: the console log instantly pops-up and notifies me that ten DHCP packets were received on port F0/2, and the port has been put to the err-disable state. Port F0/2 is now disabled, and its functionality can be restored only by an admin.

As you can see, the Limit Rate function prevents an attacker from delivering a denial of service attack or quickly exhausting the pool of addresses by sending a large number of DHCP requests.

Verify MAC address

The verify MAC address feature in DHCP Snooping is enabled by default. But if, for some reason, it’s disabled, below is the syntax required to enable it.

Earlier, I mentioned the CHADDR field in the DHCP header and the source MAC address in the Ethernet header: if the client and server interact normally, then values in these fields should be identical. When the verify MAC address feature is enabled, the switch checks these two fields: if they contain different MAC addresses, the switch drops them.

By the way, the MAC addresses are verified using the router’s CPU, which is times slower compared to packet processing by ASIC chips. If the networks operates normally, this doesn’t noticeably affect its performance. But imagine a situation when a DHCP starvation attack is delivered: it generates a huge number of DHCPDISCOVER packets, and each of them must be checked by the switch processor for matching MAC addresses.

Within a minute after the beginning of such an attack, the load on the switch’s CPU reaches 95% due to the huge number of DHCP packets it has to process. The Limit Rate function prevents such situations: the port simply goes down when the permitted number of packets per second is exceeded.

Port Security

This is the last (but not the least!) switch security feature to be addressed in this article. It has nothing to do with the DHCP Snooping technology, but plays an important role in protecting the network against DHCP attacks. Port Security makes it possible to specify MAC addresses of hosts that are permitted to transmit data through a given port. The source MAC address in the Ethernet header is used for verification; based on its result, a decision to allow data transmission through the port is made.

I configure all untrusted ports so that they can dynamically remember only one MAC address and save them to the current switch configuration. Then I specify the response to a violation of security rules: shutdown. But prior to doing this, the ports have to be switched to the Access mode.

Now if I start flooding the system with DHCPDISCOVER messages with unique source MAC address values in each Ethernet frame, the port will instantly switch to the err-disable mode (similar to Limit Rate) since the created rule (only one MAC address is allowed per switch port) is violated.

You can examine the table maintained by the switch that displays MAC addresses remembered for each interface.

It’s not really difficult for an attacker to exhaust a DHCP server by changing the MAC address of the network card. Even though this tactics takes time, it’s effective. But if Port Security is enabled on the switch, it has no chance.

Conclusions

One might think that DHCP attacks aren’t relevant nowadays. In my opinion, any attack can be relevant if an admin doesn’t pay due attention to network security, especially if network equipment operates with default settings.

If used separately, the above-described security technologies can be overcome by an attacker. Only their combined use can ensure proper protection of the DHCP protocol on your network.