by Rik Farrow
Dynamic Host Configuration Protocol (DHCP) makes administration of networks easier by providing network information as systems start up. DHCP has proven a boon for Internet services providers as well.
But DHCP has a darker side that can be exploited. Like most Internet applications, DHCP has no provisions for security. An attacker who can launch a DHCP server on your network also has control over critical network parameters.
On the plus side, DHCP servers are internal (except for ISPs), and cannot be remotely attacked when properly protected by a firewall. But the lack of security in DHCP offers opportunities for the internal attacker, or for someone who can execute code on internal systems, even desktops systems.
DHCP started out as the Boot Protocol (BOOTP), a mechanism for providing some limited network information to diskless workstations and other network devices. In the days before flash memory became common, manufacturers, like Sun Microsystems and NCD (who manufactured X terminals), needed a way to supply boot information. Even the amount of memory available for the boot process was minimal, so things had to be as simple as possible.
The answer was BOOTP and TFTP (Trivial File Transfer Protocol). The client needed to have a device driver for the network interface, a minimal IP layer, UDP, the BOOTP and TFTP clients, and using these they could get an IP address, subnet mask, TFTP server address, and the name of a file to download and execute. The BOOTP client would begin the process by broadcasting a BOOTP request on the local subnet. The protocol does support the use of a relay, which was often a router that would forward to the request to a known BOOTP server, and pass the information back to the local client.
As time went on, vendors loaded the BOOTP responses with more and more information. A BOOTP client could learn network configuration parameters (for example, whether to act as a router), the address of a Network Information Service (NIS), addresses of routers, time servers, print servers, and so on. All this occurred before Microsoft had considered adding the TCP/IP protocol to Windows.
Once Microsoft started including a TCP/IP stack, the requirements for what BOOTP could do increased, and BOOTP started to be known as DHCP. A DHCP packet today is a BOOTP packet with a special option that defines it as one of seven DHCP message types. Today there are over 60 possible options, including many added to support NetBIOS and DHCP servers.
The most important use of DHCP is the assignment of network information. In Windows networks, you use DHCP to assign not only an IP address, but also information such as the default gateway and name server addresses. In the past, this information had to be configured for each desktop, and misconfigurations were common. For example, two desktop systems would wind up with the same IP address, and neither would function reliably on the network as long as both were up.
DHCP actually has three ways of assigning addresses. Addresses can be assigned as permanent, automatic, or dynamic. Permanent addresses rely on the administrator building a database (or flat file under UNIX) of MAC addresses and the IP addresses to be bound to them. Automatic address assignment, not available under Windows NT/2K DHCP servers, does this permanent mapping as new MAC addresses appear on the network. Dynamic address assignment is what most people with Windows servers actually use. Each time a DHCP client boots, or the network interface is brought up, an IP address is assigned from a pool of available addresses. This last approach has both good and bad sides.
The good thing about dynamic address assignment is that the administrator doesn't have to do anything other than configure the DHCP service with a pool of addresses, any addresses to exclude (such as fixed addresses for servers), and any other desired configuration information. As systems come and go, they get IP address leases which are good for hours to days. If a network adapter gets changed, or a system is replaced, the DHCP server can reuse the IP address once the lease expires. The default lease period for the Windows 2000 DHCP server is eight hours. Systems that stay up longer than the lease period can request extensions of the lease.
The bad thing is that anyone who connects to your network can get an IP address, the location of the name server, and the address of the default gateway. For an outsider, this is a real boon. In the "old" days, when I would request permission to connect to an organization's network, someone would make a phone call or visit the network support people and request an IP address. They wouldn't think of including the subnet mask, the addresses of the router or name server, all important to getting IP working. To avoid wasting time, I would also set up a sniffer in the background, so I could collect the information necessary to choose an IP address, subnet mask, default gateway, and possibly name server in minutes, as it often took hours to get the network information through the official channels. Even switched networks are vulnerable to this form of sniffing, as broadcasts are sent to all ports of switch.
Figuring out network information from packet dumps is beyond most people who use networks. But, with DHCP in use, anyone who connects gets all this information dynamically.
DHCP also means that the IP addresses assigned to each desktop will change from day-to-day. If you are relying on IP addresses to catch people who violate company policy (by visiting offlimit Web sites, scanning internal networks, etc.), tracking the client means looking at the DHCP logs, finding the offending MAC address, and trying to match that with a network adapter. Not that IP addresses should ever be used to identify users, but DHCP with dynamic addresses just makes it more difficult to pick out the system where some trouble originates.
Let's just imagine that it wasn't the security guy that you have hired, and are watching, that just connected to your network. Can the wiley attacker use DCHP to further leverage his or her attack?
Consider that DHCP, like most IP applications, has no provisions for security. That makes it quite simple for an internal attacker to set up his or her own DHCP server and begin competing with your official server. The Internet standard for the DHCP protocol, RFC 2131, actually supports the use of redundant servers, and the client gets to choose which server to listen to. You might even be lucky, and have most of your clients listen to the last server they received a lease from. But, the attacker can easily stack the odds by launching a denial of service attack against the DHCP server. This can be a garden variety attack, simply abusing the targeted server, or a specific attack that depletes the pool of addresses available for lease. Windows NT RRAS servers actually had a bug that would do this, and it can also be done using the hacking tools.
And what does the attacker gain? Simply denying access to IP addresses will keep clients from using the network, but is painfully obvious. A less obvious attack involves providing false information about key addresses to one or more clients. For example, the attacking system could provide its own address as the address of the name server. Then, the attacker can mislead users by providing its own address instead of the address of, say, the corporate Web server.
In a different attack, the attacking system provides its address as the default gateway. All non-local traffic gets directed to the attacking system, which duly forwards the traffic as if it were a router. At the same time, the attacking system can sniff the data, looking for passwords, proprietary information, or whatever else the attacker is looking for. In the case of challenge-response authentication, the attacker can use a "man-in-the-middle" attack to authenticate with a Domain Controller or Active Directory (unless you have enabled server signatures).
The Windows 2000 DHCP server will not run unless it gets "authorized" from Active Directory. While this is nice, it doesn't stop someone from running an unauthorized version of the free DHCP server that comes from the Internet Software Consortium (ISC). And clients can't talk to the Active Directory until after they have gotten their network information from a possibly evil DHCP server.
DHCP is just too useful to simply turn it off. And, there are things that you can do, although these solutions are far from perfect. For a start, if you are really concerned about strangers connecting to your networks, you can assign permanent (reserved in the language of Microsoft) addresses within DHCP. You do this by collecting the MAC addresses for the network adapters that are permitted to attach to your network, and manually enter each MAC address and the IP address it will be bound to. Then, every time someone changes an adapter, edit the database to change the MAC info. Don't permit dynamic or automatic address assignment.
Okay, that solution's pretty harsh. You can also closely monitor your DHCP server's logs. In the UNIX world, this appears in the standard log directory, /var/log, by default. For Windows NT and beyond, look in the System32\dhcp directory, the default location for the logfile. Once you have found the logfile, you need a tool or script that processes it routinely, looking for never before seen MAC addresses. The UNIX security tool arpwatch can also be used to monitor this, but only on a directly connected network where it can sniff all broadcasts.
Network-based ID systems might notice that a new DHCP server has appeared, and notify you of the event.
But that could fail too. DHCP clients send UDP packets from port 68 to port 67/UDP on the server. UDP packets are trivial to spoof, so a crafty attacker can spoof the source address of the authorized DHCP servers, so that everything that the ID sensor sees on the wire appears correct.
Like many other things in the world of IP, DHCP provides little in the way of security. As Ralph Droms, author of RFC2131, wrote: "Therefore, DHCP in its current form is quite insecure." Your best defense is constant vigilance.
Open source version of DHCP server and client software from the Internet Software Consortium: http://www.isc.org
ORA chapter on Windows DHCP server:
http://www.oreilly.com/catalog/wintcp/chapter/ch06.html
Article named "How to Hack UNIX" with examples attacks using DHCP: http://www.samag.com/documents/sam0012k/
DHCP Options and BOOTP Vendor Extensions: http://www.faqs.org/rfcs/rfc1533.html
RFC that defines the DHCP protocol, and replaces RFC1541: http://www.faqs.org/rfcs/rfc2131.html
Figure 1 caption: DHCP server spoofing. The DHCP spoofer uses its own DHCP server to supply network information to the Client, but sends its own address as the default route. When the Client wishes to reach a server beyond a router, the packet gets sent to the attacker, which sniffs the packet and then passes it on.