Preventing DHCP Spoofing Attacks

DHCP is an essential Windows networking protocol and a favorite among network admins. Let’s go over the basics of DHCP allocation and review common DHCP Spoofing techniques. Stay tuned for part 2 in this series for some more advanced DHCP pitfalls and less-commonly known caveats. 

What is DHCP?

DHCP (Dynamic Host Configuration Protocol) is an application layer network management protocol that provides a quick, automatic and central system for the distribution and assignment of IP addresses and TCP/IP configuration information for clients in a network. 

DHCP can be used to assign subnet mask information, default gateway IP addresses, domain name system (DNS) addresses, and more. Another feature of DHCP configurations is that they are time-bound by the DHCP Lease Time, which determines how often they will need to be renewed. 

The basics of DHCP allocation

Before we move on to describe DHCP spoofing and poisoning techniques, let’s review the basic workings of the DHCP networking protocol. 

In a normal scenario, when a client first connects to a new DHCP network, the process is as follows: 

• The client sends a DHCPDISCOVER request by broadcast.
  
  The request includes information about the client, such as the MAC Address, so that the server knows which client sent the request.
• The DHCP server responds with a DHCPOFFER.
  
  The DHCPOFFER offers the client an IP address from the DHCP server’s pool of available addresses and sets the destination IP to the offered address.
• The client replies with a DHCPREQUEST to confirm the address provided by the server and requests additional details from the server. 
• The DHCP server responds with a DHCPACK to acknowledge the Client’s request and confirm the requested IP address. Additional information is provided, including the DNS server address, domain name, and lease time.  
• When the time for the lease is over, the Client will send a DHCPRELEASE message to inform the server that the address can now be re-distributed to another client. 

The “classic” scenario we just described can take many variations. Here’s a short list of a few other possible vectors:

• If the DHCP server receives an invalid or unsupported request, it will send a DHCPNAK response to the client. This can happen even if the request is valid but the server’s address pool is depleted and no addresses are available.
• A client already familiar with the DHCP server address can skip some of the steps and send a DHCPREQUEST by unicast directly to the server. This is standard for DHCP lease renewal.
• If the client has a static IP address configured, it can send a DHCPINFORM message to notify the server and avoid a conflict with another client. 
• If a DHCP relay agent is involved, the process is a bit different. A relay agent can be any TCP/IP host used to forward requests and replies between the DHCP server and clients and is used when the DHCP server is on a different LAN than the clients. A relay agent will receive DHCP messages and then generate a new DHCP message to send out on another interface.  
• DHCP messages can be sent by either broadcast or unicast traffic, depending on the configuration. 

DHCP spoofing attack methods

Needless to say, the DHCP protocol is a powerful network configuration tool that can simplify life for network administrators. The problem arises when unsuspecting network administrators are not well aware of all that makes the DHCP protocol susceptible to attack. 

By default, the DHCP protocol uses no form of authentication and is sent on broadcast, so potentially any device on the network could receive and possibly tamper with the messages. Let’s consider what could happen if an attacker were to combine attacks – for example, DHCP starvation and Rogue DHCP – to launch a Man-In-The-Middle attack (MITM). 

DHCP Starvation Attack

In a DHCP starvation attack, an attacker sends the DHCP server multiple DHCPREQUEST messages with spoofed source MAC addresses within a short time span in order to deplete the server’s pool of available IP addresses and prevent a race condition. The “starved” DHCP server will not respond to new DHCP requests until a new address becomes available. 

A DHCP starvation attack sets the stage for the attacker to pass himself off as the DHCP server and send out spoofed messages to trick other clients on the network.

Rogue DHCP attack 

Now the attacker can set up his own rogue DHCP server, listen for incoming broadcast requests, and send out spoofed responses with malicious configurations. Usually, the attacker will aim to set himself as the DNS server and default gateway for the clients. 

The attacker will open port 53 on his machine for DNS activity, so that every DNS resolution request will reach his machine, allowing him to choose when to answer with his own hostname.

Testing your vulnerability to DHCP spoofing  

Running a penetration test is the only sure way to test your network’s vulnerability to DHCP spoofing attacks. A simple, quick, and automated way to run such a pen test in a safe and controlled environment is to use an automated penetration testing platform, such as Pentera.

Click here to read the full Pentera Labs research paper.

Example of how Pentera pentests for DHCP spoofing 

1. Pentera initiates the DHCP Starvation attack by overwhelming the real DHCP server with enough DHCP REQUEST messages to exhaust the server’s pool of available IP addresses. This sets the stage for closing in on a victim host.
   
2. An unsuspecting host broadcasts a DHCP DISCOVER request, expecting an answer from the real DHCP server  –

3. Since the real DHCP server has been starved and cannot reply, Pentera is able to send out its own malicious DHCP OFFER response – 

4. The victim host completes the negotiation flow against Pentera, receives fake configurations, and sets the DNS server as the Pentera host. Now that Pentera is masquerading as the victim’s DNS server, the host is effectively ensnared in a Man-In-The-Middle attack – 

5. At this point, if the victim sends a DNS request for a resource, Pentera can provide its own address and test many attack scenarios, one of them is the forced authentication scenario. 

DHCP spoofing can lead to forced authentication and credential harvesting

In a forced authentication scenario, Pentera – if you’re lucky, or a savvy attacker, if you’re less lucky – aims to obtain the victim’s NetNTLM hash. Here’s how it can happen – 

• Let’s say the victim tries to reach “www.SomethingThatDoesntExist.com”, which is to say a non-existing site, a wrong URL or an address with a typo or error. 
• The attacker’s host, which is acting as the victim’s DNS server will receive the DNS request for the missing address “SomethingThatDoesntExist.com”. 
• The attacker will reply that “SomethingThatDoesntExist.com” is the address of the attacker’s very own host.
• The victim will send an HTTP request to the attacker.
• The attacker will return an HTTP 401 – unauthenticated response, which will require the client to initiate an authentication process.
• Bingo! The attacker will obtain the client’s NetNTLM hash.

Once attackers have obtained NetNTLM hashes, their options for further exploiting the network and chances of success are staggeringly high. Still, even if you’ve already disabled NTLM authentication, that’s great, but it certainly doesn’t mean you’re in the clear. Stay tuned for the next part in this series to learn how DHCP misconfigurations can be exploited to expose port 139 and get some expert best practice recommendations.   

Recommendations 

Implementing DHCP snooping to mitigate DHCP spoofing 

Unfortunately, there isn’t a simple fix that can hermetically block DHCP spoofing. Protecting your network involves a methodology known as DHCP snooping, a set of techniques aimed at reducing and mitigating the impact of DHCP spoofing attacks. It can be configured on LAN switches to prevent malicious or malformed DHCP traffic and block rogue DHCP servers. 

DHCP snooping involves monitoring your DHCP traffic. This can be done by compiling information on hosts which have successfully completed a DHCP transaction in a database of “bindings” and use security or accounting features to monitor the traffic. 

We hope you’re now ready to review your DHCP policies, apply DHCP snooping policies in your network systems and devices, and validate your security posture for compliance.