Understanding and Preventing L2 Attacks Series Index
Part 3 - More Attacks and Mitigation This is the second article in the Layer 2 Security series. Here we will take a look at two different DHCP Attacks. Each attack will be explained, demonstrated, mitigated, and re-tested.
The article will be split out into five sections:
DHCP Refresher: The DHCP Refresher will go over the basics of DHCP. If you already understand the basics, you can likely skip this section.
DHCP Exhaustion Attack: The second section will explain and demonstrate how a DHCP Exhaustion attack works.
DHCP Spoofing Attack: In concert with the DHCP Exhaustion attack, we will also run a DHCP Spoofing attack.
Attack Mitigation: How to defend against both types of DHCP Attacks.
Additional Attacks: If you think the worst-case scenario is a DHCP outage, this section is for you.
The DHCP process is straightforward and something most of us don’t really think about too often. However, completely understanding how it’s supposed to work can help you understand why the attacks are going to be successful. Often the acronym “Dora” is used to describe the process:
The client starts the process by sending a discovery message to the L2 & L3 broadcast addresses. The Discovery Message basically says, “Who has an IP for me?”:
Source IP: 0.0.0.0
Destination IP: 255.255.255.255
Source MAC: The MAC Address of the sender
Destination MAC: FF:FF:FF:FF:FF:FF
The switch receives the broadcast and forwards it to every port in the same VLAN. For example, if the client is plugged into VLAN 10, every endpoint in VLAN 10 will receive a copy of the broadcast. Here is the first problem, if an attacker is plugged into the network, the attacker PC will receive the broadcast.
The DHCP Server will receive the Discovery message and reply to it with an Offer, if the server has an IP available. The Offer basically says “I got your message, and I can give you IP Address 10.0.0.1, with Mask 255.255.255.0, for a lease time of 8 days, and oh by the way my IP is 10.0.0.254.
Source IP: 10.0.0.254
Destination IP: 255.255.255.255
Source MAC Address: The MAC Address of the server.
Destination MAC Address: The MAC Address of the client
This is the second problem – What happens when the DHCP Server sends the Offer, but the client never responds? The answer is, it holds the IP listed in the Offer and will not issue it to any other host. The timer is not exactly clear, but in my testing, it seems to be around 10 minutes.
This also brings up the third problem – How is this secured? How do we know the DHCP Server is legitimate?
Once the client receives the offer (there can be more than one), it will begin the request process. The first step is DAD (Duplicate Address Detection), but assuming the IP is unique on the network, it sends the request. The request basically says, “I received your Offer, and I accept”. There are some tools for this on the infosec side which requires credentials to get an IP, but by default, there is no security.
Source IP: 0.0.0.0
Destination IP: 255.255.255.255
Source MAC Address: The MAC Address of the client.
Destination MAC Address: FF:FF:FF:FF:FF:FF*
*If you are wondering why the request goes to the L2 Broadcast when the server MAC is now known – It goes to the broadcast so if multiple DHCP Servers exist on the segment, they will all know which server’s offer was accepted. The other “losing” DHCP Servers will return their offered IPs to their pools.
In the final step of the process, the server sends the client an acknowledgement. The acknowledgement says, “The IP is now yours for the next x amount of time, and here is some other stuff (DNS, Default Gateway, etc…).
DHCP Exhaustion Attack
DHCP Exhaustion Attacks are disturbingly simple attacks that requires no special knowledge. In other words, if you have Google and 20 minutes to spare, you can crush any unprotected DHCP Server of any size. Plus, as we’ll see a bit later in this article, the results can be devastating.
Simply, the attacker PC will send DHCP Discovery messages to the broadcast address in rapid succession. With each Discovery, the source MAC Address is spoofed to a random MAC. All DHCP Servers in a segment will send Offers, and all available IPs will be reserved while the servers wait for the Request messages. The Request messages will never be sent.
DHCP Spoofing Attack
Now that we have the legitimate DHCP Servers down, we can launch our “fake” DHCP Server. There are essentially two ways to steal data with this type of attack:
Within the DHCP Scope, issue a DNS Server pointing to the attacker PC. The attacker can proxy all DNS queries to a legitimate server and selectively respond to DNS queries directly. For example, all DNS queries are forwarded to Google, except banking websites. The attacker can reply to the Banking queries with its own IP.
Within the DHCP Scope, issue a default gateway pointing to the attacker PC. The attacker PC can copy the traffic and then forward it to the original destination.
In the demonstration, we will use the DNS method.
DHCP Attack Mitigation
DHCP Snooping is a service that runs on your switches. The process does a few things:
Defines where the real DHCP Server(s) live. Only servers on pre-approved switch ports will be allowed to respond to the initial client Discover packet. All other DHCP Offers will be dropped.
Maintains a database of all DHCP assignments. This feature is frequently used with other security features (covered in the next post).
Rate limits DHCP Discover packets on non-trusted ports. For example, we are going to tell the switch to shut down any port that sends more than 100 (Best Practice) DHCP packets in one second.
The lab configuration is going to be very simple and there is not much to think about. In a production environment, it does get a bit more complicated when you have to account for various trunks, IP Helpers, switch platforms, and code versions.
So far, the legitimate DHCP Server has been removed from the equation and the attacker DHCP Server is the only one handing out IP Addresses. The victim PC will send all DNS queries to the attacker’s PC, but the queries will currently fail. Simply, the attacker PC does not have DNS running to answers these queries…yet.
The second bit is how does the attacker take advantage of these DNS queries. There are two methods:
Selectively reply to specific DNS queries with the attacker PC’s IP Address. From there, actually serve a spoofed website to the client.
Selectively reply to specific DNS queries with the attacker PC’s IP Address. This time instead of serving a spoofed website, the attacker can take a copy of the data and proxy the request to the real website.
Note: In both cases there would be diminished value if another attack wasn’t run to get to the client to trust an attacker provided certificate. There are attacks for that purpose that will not be covered in this article.
A Few Closing Notes
It’s astonishing to me how quickly and easily all of these attacks were carried out. In an unsecured production environment, an attacker can do all the above, plus more, in under 60 seconds. In addition, the attack would be very difficult to detect. Let’s walk through it…
Once the real DHCP Server is down, the users will switch to the rogue DHCP Server and everything will work just fine. In other words, you have no reason to think there was a problem, nor do the users. In addition, the attack against the real DHCP Server can be run only periodically to pick up new users with every run. The attacker can launch the exhaustion attack for a few seconds, launch the Spoofing attack for a few minutes to pick up some clients, and then shut down the rogue DHCP Server. From there repeat the process every x days. This would be almost impossible to detect without the right tools.
Finally, the maximum DHCP Lease time on a Microsoft Server, for example, is 999 days, the client can remain on the hook years!
Keep an eye out for our next post. We’ll go through a few more attacks on the Layer 2 network including ARP Attacks, Cam Table Attacks, and VLAN Hopping.