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.
Example of how Pentera pentests for DHCP spoofing
- 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.
- An unsuspecting host broadcasts a DHCP DISCOVER request, expecting an answer from the real DHCP server –
- Since the real DHCP server has been starved and cannot reply, Pentera is able to send out its own malicious DHCP OFFER response –
- 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 –
- 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.
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.
CVE-2022-22948: Sensitive Information Disclosure in VMware vCenter
New zero-day vulnerability joins a chain of recently discovered vulnerabilities capable of operating an end-to-end attack on ESXi. Organizations should evaluate risk and apply vCenter client patches immediately. Executive Summary Pentera Labs’ Senior Security Researcher, Yuval Lazar, discovered an Information Disclosure vulnerability impacting more than 500,000 appliances running default vCenter Server deployments. This finding is...
4 steps to knowing your exploitable attack surface
Originally published on Dark Reading. According to a Cisco CISO Benchmark survey, 17% of organizations had 100,000 or more daily security alerts in 2020, and its trajectory has only increased. Source: Cisco 2020 CISO Benchmark Survey 2021 only followed this trend with a record year of newly-discovered CVEs – 20,137 to be exact, topping the...
The Security Miss in Misconfigurations: Taking a second look at firewall misconfigurations
Network misconfigurations take on many types and forms, and come about for many different reasons. Many of them stem from blind adherence to poorly-informed common practices or even just from simply not being aware that operating system configuration defaults inherently contain security misconfigurations. Let’s review 2 common misconfigurations to serve as our examples: Why closed...