Securebits Blog

Recently, I was thinking about the current status of DHCP security and whether a new DHCP attack can be created. In fact, I am almost confident that a new extended version of the available exhausting attack is feasible. The current DHCP exhausting attack can only be performed against the DHCP pool assigned to the particular subnet/VLAN where the attacker resides. However, what I call Extended Exhausting Attack can be performed against ALL the address pools configured on a DHCP server. I have not tested this practically; so, the following explanation is merely theoretical – I will do a practical experiment later in the near future.

To understand the traditional exhausting attack and the extended exhausting, we need to understand how DHCP functions in case the DHCP server is located locally within the subnet of the client and in case the DHCP server is located outside the subnet. From the client view, the operation is the same, however, from the server view, it differs.

The DHCP process by which a client gets auto IP-configuration is called the D.O.R.A. process [Discover, Offer, Request, and Acknowledgment.] In short, if the DHCP server is located in the same subnet as the client, the four steps of this process are as follows:

1- DISCOVER: the client sends a DISCOVER message. The source IP is 0.0.0.0 and the destination IP is 255.255.255.255; the source MAC is the MAC address of the client and the destination MAC is FF:FF:FF:FF:FF:FF. The purpose of this message is to declare that the client wants to know the available DHCP server.

2- OFFER: If there is a DHCP server within the same subnet, the server responds with an OFFER message. This is a unicast packet: the source IP is the IP address of the server and the destination IP is the IP address which the server would like to assign to the client. The source MAC is the MAC address of the server and the destination MAC is the MAC address of the client. Also, the OFFER message contains all other IP settings, like subnet mask, default gateway, DNS server, WINS servers, etc.

3- REQUEST: The client then issues a REQUEST message confirming its acceptance of the offered settings. This message contains the same IP and MAC addresses of the DISCOVER message. It is a broadcast message at both Layer 2 and Layer 3.

4- ACKNOWLEDGMENT: Finally, the server sends an ACK message to the client and the client now is eligible to use the offered settings. This message contains the same IP and MAC addresses of the OFFER message.

However, if the DHCP server is located in a different subnet/VLAN, there is the introduction of “DHCP Relay Agent”; usually, the router/gateway assumes the functionality of the DHCP Relay Agent in modern LANs. From the client perspective, the D.O.R.A process is exactly the same; however, in the OFFER and ACK messages, the field “Relay Agent IP Address” is filled with the IP address of the router/gateway. Also, the field “Next Server IP Address” in the OFFER message is filled with the IP address of the DHCP server. The role of the Relay Agent is to be a link between the client and the server as follows:

1- When the client sends a broadcast DISCOVER message, the Relay Agent catches it and sends another DISCOVER message to the DHCP server; however, this second DISCOVER message is unicast. The source IP is the IP address of the Relay Agent and the destination IP is the destination IP of the server.

2- The server sends a unicast OFFER message to the Relay agent. Upon receiving it, the Relay Agent forwards the OFFER to the client.

3- The Relay Agent again picks the broadcast REQUEST message sent by the client. Then, it sends another unicast REQUEST message to the server.

4- The server sends a unicast ACK to the Relay Agent which forwards this ACK to the client.

Traditional exhausting attack involves exploiting the D.O.R.A process to get all the IP addresses in the pool. By repeating the D.O.R.A process with different MAC addresses, the server will release all IP addresses configured in the pool. For example, if an attacker is located inside 10.10.10.0/24 subnet, he can exhaust all the IP addresses in the pool designated for that particular subnet. New systems introduced to the 10.10.10.0/24 subnet cannot get their auto IP configuration since the server has run out of IP addresses.

This well-known attack can only target the pool allocated to the subnet in which the attacker resides. Let’s assume this example: a corporate LAN with a DHCP server 10.1.0.74, and multiple subnets/VLANS 10.1.11.0/24, 10.1.12.0/24, 10.1.13.0/24, …, 10.1.20.0/24. Each VLAN has a designated pool in the DHCP server. If the attacker resides in 10.1.13/24 subnet, he can only exhaust the pool associated with that subnet. Other subnets/VLANs are not affected.

In the Extended Exhausting attack I am thinking of, it is possible to exhaust ALL the pools regardless where the attacker resides. This involves spoofing the Relay Agent of every subnet/VLAN. The following steps outline the process:

1- The attacker resides in 10.1.13.0/24 subnet. He wants to exhaust the pool associated with 10.1.15.0/24 subnet. The attacker needs to know in advance the gateway router for that subnet; usually it is going to be 10.1.15.1. The attacker may check his gateway IP address and apply the implemented scheme on other subnets.

2- The attacker sends a DISCOVER message. It is a unicast packet with spoofed source IP; such spoofed IP is the Relay Agent (i.e. gateway) of the other subnet, e.g. 10.1.15.1. Also, this DISCOVER has in its “Relay Agent IP Address” field the IP of that gateway, too.

3- When the server receives this DISCOVER message, it appears as though a client in the subnet 10.1.15.0/24 is requesting a new IP address. The server would also know that the DISCOVER message is being forwarded by a Relay Agent whose IP address is indicated in the source IP as well as in the “Relay Agent IP Address” field. The server checks the pool associated with 10.1.15.0/24 subnet to see if there are available addresses.

4- If there is an available IP in the pool, the server sends an OFFER to the Relay Agent, that is, to the spoofed IP address that was in the DISCOVER message. The OFFER carries an IP address within the 10.1.15.0/24. This packet will not be delivered to the attacker; it will be sent to the router/gateway of the 10.1.15.0/24 subnet. However, since the router/gateway did not issue a DISCOVER message (with the same Transaction ID), the router/gateway will just ignore the OFFER.

5- The server now expects a REQUEST message from the Relay Agent, which is the router/gateway of 10.1.15.0/24.

6- The attacker now has the chance to send the REQUEST message; however, the attacker does not know the IP address offered by the server since the OFFER message never reached the attacker. In this case, the attacker would send around 254, at maximum, REQUEST messages where every message contains an IP address from the subnet 10.1.15.0/24. All of these messages contain the same Transaction ID used initially by the attacker in the DISCOVER message. These messages will be sent with the spoofed IP address of the Relay Agent (i.e. router/gateway)

7- One of these REQUEST messages will match the OFFERED IP address and it will be accepted as a legitimate REQUEST. The server sends an ACKNOWLEDGMENT message to the Relay Agent/Gateway. This message will be ignored by gateway/router just like with the OFFER message.

8- The attacker now repeats the cycle again for around 254 times, at maximum, to exhaust the pool for 10.1.15.0/24.