Conquer 2 New DNS Exploits

Executive Summary: You understand the importance of securing your DNS name servers, but what about your DNS clients? Two recent exploits—a Web Proxy Autodiscovery Protocol (WPAD)-related problem and a vulnerability involving malicious resolver reconfiguration—are targeting stub resolvers to work their mischief. This article describes the exploits and shows you how to defeat them.

When I talk about DNS security, I usually emphasize the importance of securing name servers. For example, I’m always encouraging administrators to disable or restrict access to recursion on external name servers. However, two recent exploits—a Web Proxy Autodiscovery Protocol (WPAD)-related problem and a vulnerability involving malicious resolver reconfiguration— are targeting stub resolvers (i.e., DNS clients) to work their mischief. What are these exploits and how can you defeat them?

WPAD
The first vulnerability involves WPAD, a protocol that lets Web browsers automatically determine the proxy settings they should use. Essentially, a Web browser that supports WPAD uses DNS to look up the name wpad and connects to the Web server at the returned address to retrieve a proxy auto-configuration file called wpad .dat. The browser then reads its proxy configuration from that file. The idea is to provide administrators a “hook” for specifying the proxy configuration for all the browsers in their organization from a single point. Currently, Microsoft Internet Explorer (IE), Mozilla Firefox, and Opera support this mechanism.

At first glance, WPAD appears innocuous. However, it can interact with the search list—in Windows parlance, the DNS suffix search list or DNS suffix search order—in unpredictable and undesirable ways. The search list is a series of domain names that are appended to names specified in the browser’s address field or on the command line. For example, if your search list contains the domain names subdomain.company.com and company.com, and you type

http://foo 

in your browser’s address field, the browser will look up foo.subdomain. company.com first and then (if that lookup doesn’t return an address) foo.company.com. The search list applies to the browser’s internal lookup for the name wpad, too.

You can explicitly set the search list, domain name by domain name, but the list is more commonly inherited (or devolved, in Microsoft terminology) from a Windows computer’s local domain name (which Microsoft dubs the primary DNS suffix). The search list, by default, includes the local domain name and all its ancestor domain names with at least two labels. So, the local domain name sub.net.ac.uk would devolve to a search list of sub.net.ac.uk, net .ac.uk and ac.uk.

The problem arises when the combination of wpad and the elements of the search list unexpectedly matches a domain name outside your organization’s control. For example, if your search list includes sub .org.co.nz, org.co.nz and co.nz, your browser will look up wpad.sub.org.co.nz, wpad.org .co.nz, then wpad.co.nz. If neither wpad .sub.org.co.nz nor wpad.org.co.nz exists, your browser could get its proxy configuration from wpad.co.nz, a domain name that your organization doesn’t run! (Actually, Beau Butler, a Kiwi security researcher who recently publicized this very problem, runs the wpad.co.nz domain.) That configuration could instruct your browser to shunt all its Web traffic through a proxy server in Berzerkistan.

A malicious user could subvert the WPAD mechanism in another way: If he or she connects a computer named wpad to your network, that computer might be able to register its name in DNS, or your DHCP server might add the name to DNS on the computer’s behalf. The malicious user could then set up a Web server on the computer to distribute a little hand-crafted wpad.dat file that, again, diverts all Webbrowser traffic to Berzerkistan.

Addressing the WPAD Problem
You can deal with this problem in several ways. First, you can set up a Web server (or use an existing Web server) to distribute a correct, official proxy auto-configuration file to Web browsers that support WPAD. Then, add wpad A records to your zones, pointing to the Web server’s address. (A records are DNS resource records that map domain names to IP addresses.) Second, you could use the site-local DHCP option 252 (aka auto-proxy-config) to specify the Web server and file from which browsers should load the proxy configuration. Either way, once a browser finds a proxy auto-configuration file, it will stop searching. Third, you can disable WPAD within the browser or through Group Policy. In IE, you can disable WPAD from Tools, Internet Options, Connections, LAN Settings. The dialog box that Figure 1 shows should appear. Clear the Automatically detect settings check box to disable WPAD.

A fourth option is to pare down the search list to the bare minimum. (Doing so is generally a good idea anyway; it prevents unexpected matches in contexts other than WPAD.) To disable the Windows devolution mechanism that populates the search list with the ancestors of the local domain name, clear the Append parent suffixes of the primary DNS suffix check box in the Control Panel Network applet’s Advanced TCP/IP Settings window, as you see in Figure 2. Clearing this check box will prevent ancestors of the primary DNS suffix (but not the primary DNS suffix itself) from being included in the search list. Again, you can also accomplish this configuration through Group Policy.

Before culling all the ancestor domain names from the search list, however, you should make sure your users and their applications aren’t counting on them. Users can become accustomed to typing shortened domain names into browsers or at the command line, and they might have used them in configuration files, too. For example, you might find that your users rely on several entries in the search list. If only the last of the domain names in the search list is problematic, you can set the search list explicitly to remove that single domain name but leave the rest. Figure 3 shows how to set the search list to include sub.org.co.nz and org.co.nz but not the troublesome co.nz.

Finally, even if you use the DHCP option to specify the Web server doling out your proxy auto-configuration file, you should add an A record for wpad to all your forward- mapping zones. Once a browser finds this A record, it will stop its search, even if no Web server is running at the IP address you specify. In many cases, adding a wpad A record to a zone will also keep a rogue computer named wpad from registering its name in DNS, because that name is already taken. If it doesn’t prevent that—setting up a DHCP client with the computer name wpad to see if it can overwrite a wpad A record you added manually is simple— make sure your name server is configured to accept only secure dynamic updates (if it’s a Microsoft DNS server) or that your DHCP server uses the interim DDNS update style (if you’re running the Internet Systems Consortium—ISC—DHCP server).

On a final note, don’t use the loopback address 127.0.0.1 in the A record. For some reason, an A record pointing to this loopback address doesn’t stop the application of the search list.

Continued on page 2

   Previous  [1]  2  Next