Recently there have been reports of "rogue DHCP server" malware -- trojans that automatically install their own DHCP servers on your network and compete with your legitimate server. Using rogue DHCP servers, attackers can intercept and redirect traffic from any device that uses the Dynamic Host Configuration Protocol (
Continue Reading This Article
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
The Dynamic Host Configuration Protocol was developed in the early 1990s to ease network maintenance and setup, and it has always had fundamental security vulnerabilities. Fortunately, there are time-tested solutions you can use to detect and defend against rogue DHCP server malware.
When a DHCP-enabled client (for example, a laptop) connects to the network, it sends out a broadcast message searching for the DHCP server. The local DHCP server responds with a proposed IP address assignment for your laptop, and eventually other local configuration information, such as the DNS server IP address and gateway IP address. Once the negotiation is complete, the laptop can configure itself and talk to others on the IP network.
Thanks to DHCP, a mobile device can go from a wireless hotspot to a home network to a corporate network, all without ever having to manually change its IP address settings. Large enterprises can deploy and redeploy hundreds or thousands of servers without ever manually changing individual network configuration settings.
DHCP, however, had known security issues since it was invented. The original DHCP specification, dating back to 1993, has a section called "Security Considerations," which reads:
"...DHCP in its current form is quite insecure. Unauthorized DHCP servers may be easily set up. Such servers can then send false and potentially disruptive information to clients such as incorrect or duplicate IP addresses, incorrect routing information (including spoof routers, etc.), incorrect domain nameserver addresses (such as spoof nameservers), and so on."
In some ways, it's amazing that we've gone 16 years without widespread DHCP problems. Since 2001, if not earlier, there have been well-known automated tools for conducting DHCP man-in-the-middle attacks. One major issue exploited by network sniffer tools like Ettercap, as well as today's malware, is that according to the standard DHCP implementation, there is no way for a client to identify legitimate DHCP servers. (In 2001, the IETF released a specification for authenticated DHCP, but vendors and administrators have still not widely implemented it.)
As a result, your laptop trusts all DHCP server responses and assumes they are equally valid. "Rogue" DHCP servers, running on infected workstations, can respond to your broadcast DHCP request with bogus configuration data. If the rogue server's messages arrive first, your laptop may accept the poisoned configuration information.
Emergence of rogue DHCP server malware
In December 2008, the "Trojan.Flush.M" malware was discovered. This Trojan automatically sets up a rogue DHCP server with the goal of distributing a malicious DNS server address to unsuspecting clients. For example, when your laptop attempts to renew its DHCP lease, a Trojan.Flush.M rogue DHCP server might quickly respond with a poisoned DHCP response that includes the attacker's DNS server IP address. If your laptop accepts this information, then any time you type a new URL into your Web browser, your laptop will query the attacker's DNS server for the IP address, which corresponds to that domain name. You could type in "http://bankofamerica.com," and the attacker might respond with the address of an evil Bank of America-branded phishing site, which would then cause your browser to load a malicious webpage.
This might sound complicated, but with 16 years of development, DHCP attack tools are fairly mature. Using Ettercap, anyone can point-and-click their way to conducting a DHCP man-in-the-middle attack. Furthermore, a single infected workstation can compromise an entire subnet's traffic, without any user realizing.
How to thwart rogue DHCP server malware attacks
Fortunately, over the years effective defense tools have emerged. Multiple network switch vendors offer built-in "DHCP snooping" capabilities, which block untrusted DHCP server traffic at the switch. "DHCP snooping" equipment also tracks MAC addresses, IP address assignments and corresponding ports, ensuring only legitimate combinations are allowed to communicate.
You can scan your network for rogue DHCP servers using tools such as DHCP Sentry, Roadkil.net's DHCP Find, Dhcploc.exe or dhcp_probe. Some DHCP server-scanning tools have built-in email and IM alerting capabilities, so they can alert system administrators as soon as a potential rogue DHCP server is detected. Network intrusion detection systems can also be configured to alert on potential rogue DHCP server traffic.
Appropriate network segmentation will help keep rogue DHCP servers contained. That way, even if the malware infects a single segment and spoofs DHCP, the damage will be limited. Finally, it's a good idea to monitor your internal network for evidence of client misconfiguration, such as unexpected DNS traffic to suspicious addresses. As we've seen with Trojan.Flush.M, incorrect DNS settings can be symptomatic of a rogue DHCP server.
Rogue DHCP server malware is a new twist on an old concept. The good news is that effective threat mitigation strategies exist; the bad news is that many organizations haven't bothered to deploy them yet. Segment your network carefully, configure DHCP snooping if your infrastructure supports it, monitor your internal network traffic, and respond promptly to suspicious activity. As always, the best strategy is defense in depth.
About the author:
Sherri Davidoff is the co-author of the new SANS class "Sec558: Network Forensics" and author of Philosecurity. She is a GIAC-certified forensic examiner and penetration tester. She provides security consulting for many types of organizations, including legal, financial, healthcare, manufacturing, academic and government institutions.
This was first published in July 2009