DHCP Starvation attack is another type of attack that we may face in our network. It is a Layer 2 attack, meaning you do not even need any IP address set between your Kali Linux machine and the MikroTik router to launch this attack.

But what DHCP Starvation attack can do exactly?

As you may know, most of network engineers use a DHCP server in their network to allocate IP addresses to devices in the network. What an attacker will do, he will exhaust our DHCP pool in our MikroTik router in a way that all available IP addressed will be assigned to unreal devices based on Kali Linux requests, and the rest of the real devices in our network will not be able to have IP addresses from the DHCP server anymore. More than this, this attack would cause that the CPU on the router goes to 100% and again the router will not be able to do normal tasks that a normal router should do.

If you want to learn exactly how this would happen in the background, let me then show you this illustration:

Every DHCP client (PC, laptop, phone, Tablet, printer, etc..) requesting for an IP from the DHCP server will have to pass through 4 DHCP messages so it has an IP leased to it. This is what we call is as DORA where :

• “D” is Discover sent as a broadcast by the DHCP client seeking a DHCP server in the network.
• “O” is Offer where the DHCP server replies to the DHCP client and offers an IP.
• “R” is Request where the DHCP client requests the offered IP to stay for him from the DHCP server.
• “A” is acknowledgment where the DHCP server acknowledges the DHCP client that the IP is leased for him.

This is all good for now. However, the attacker will use this DORA communication to launch its DHCP starvation attack. What attackers normally do, they launch a continued DHCP Discover to the DHCP server from different “unreal” devices, and the DHCP server will answer by DHCP Offer to each of those requests. The result will be that the DHCP server has offered all his IPs in his pool to fake devices and he won’t be able to server other real devices. Please note that the attackers will not allow the DORA to complete, so they only do discover and wait for an offer to launch again another discover until the pool of IPs is finished.

Now you know the theory behind it, let’s run the attack and see how to mitigate it.

LAB: DHCP Starvation Attack & Prevention

 

I do have the following scenario. R1 is connected to a switch on its port Ether2, and on this switch we have an attacker who plugged in his Kali Linux machine on the interface Ether1 or the switch. On R1 we have DHCP server enabled providing an IP from the range of 172.80.80.0/24.

The attacker on Kali Linux wishes to run a DHCP Starvation attack so all IPs from the DHCP server pool will be exhausted and the router will not be functional anymore. Let’s try to run the attack and see what will happen to R1.

Again, from Yersinia we can launch the DHCP Starvation attack as you see in the picture above. Let’s see if R1 has all his IPs reserved.

 

You can clearly see, the IPs from the DHCP pool have been exhausted and all have offered as a status (so DHCP Offer as I have previously explained). Also, you can clearly see that the CPU of the router goes to 100%.

This is a very bad type of attack that we may have. So how can we solve it?