Blog

Poorly configured networks are vulnerable to many attacks. Easy attacks. In this blog we will demonstrate how easy it is to perform a DoS attack on a DHCP scope. Afterwards, we will remediate our poorly configured network devices with a security feature that you should include on every deployment to protect against this type of attack.

Attack Topology

Using my own network equipment¹ and my own computers¹, here is the topology used to demonstrate the attacks. It is assumed that “The Attacker” PC is connected to the same LAN segment as “The Victim” PC. The fact that the attacker was able to connect to the same LAN segment as the victim demonstrates a poorly configured or absent NAC policy, but that is a topic for another time.

¹ Do not attempt to perform these attacks on any networks/systems without express written consent from the network/systems administrators.

DHCP DoS Attack - Baseline

Before we launch our attack, we will gather some baseline data.

‘show ip dhcp pool’ shows us that we have plenty of addresses available to hand out.

‘show ip dhcp binding’ confirms our current bindings.

Consistent ICMP to default gateway sees response time of 1ms.

DHCP DoS Attack – The Attack!!!

Here we launch our attack from our “Attacker” PC. It is scary easy to do.

Using a tool on Kali Linux by the name of Yersinia, we will initiate a DHCP DoS attack and observe the results.

Let’s see how successful the attack was by checking the same outputs from our baseline.

‘show ip dhcp pool’ shows us that we have completely exhausted the DHCP scope that was attacked.

This is further confirmed by examining the DHCP binding table (the State = Selecting entries came from our attacker).

Finally, we can see that in this instance since the router itself was the DHCP server, we have rendered this network unusable.

In this case since the DHCP server was the router itself, we overwhelmed the CPU on the router, so not much else could be done attack-wise to this network. In other cases, the DHCP server may be external to the network, allowing this attack to progress into a Man in the Middle attack. In those cases, the network itself would continue to function, making it easy for the attacker to exhaust the real DHCP server pool and setup one of its own to make itself the default gateway for the segment in question.

DHCP DoS Attack – Prevention

By now, it is easy for you to see that something needs to be done about this. That something is called ‘DHCP Snooping’. Using DHCP Snooping we will prevent the attacker from exhausting the DHCP pool and from setting up a rogue DHCP server to be used for MitM.

Here is what the DHCP Snooping configuration looks like prior to making any configuration updates. By default this is disabled.

Next, we entered the below configuration to enable DHCP Snooping.

The rate limiter applied to the endpoint/untrusted interfaces is extremely important to fully mitigate this attack. A rate limit of ‘10’ means that only 10 DHCP packets per second are allowed from the endpoint connected to the interface. If this limit is breached, the interface will be put in an ‘err-disabled’ state. Without this rate limiter, the attack would persist/succeed in exhausting the DHCP scope, however, the default control plane policy for DHCP snooping will kick in to aid in keeping the network somewhat useable during the attack.

Now the output of the show ip dhcp snooping command looks a lot better.

DHCP DoS Attack – The Second Attack!!!

Let’s see how our little network fares against this attack now that we have configured DHCP Snooping. We will launch the attack the same as last time and observe the effects.

Using a tool on Kali Linux by the name of Yersinia, we will initiate a DHCP DoS attack and observe the results.

Let’s see how UNsuccessful the attack was by checking the same outputs from our baseline.

‘show ip dhcp pool’ shows us that we have still have plenty of addresses to hand out.

This is further confirmed by examining the DHCP binding table (the State = Selecting entries came from our attacker). Notice the attacker was not able to exhaust the pool prior to us mitigating the attack!

by this attack was limited to a single ICMP packet dropping during the initial burst of DHCP Discover packets from our attackers DoS attempt, prior to the attackers interface becoming ‘err-disabled’.  

What’s Next?

It’s obvious, go configure DHCP Snooping!!! Next time we will look at a dead simple MitM ARP attack (hint: don’t wait for it, configure dynamic ARP inspection now!).

As always if you have any questions on improving your IT environment set up for you and your business and would like to schedule a free consultation with us, please reach out to us at sales@lookingpoint.com and we’ll be happy to help!