Conquer 2 New DNS Exploits

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

Malicious Resolver Reconfiguration
Recently, the Measurement Factory conducted a survey of the Internet’s DNS infrastructure (dns.measurement-factory.com/surveys/200710.html) and found roughly 16 million open recursors. Open recursors are Internet IP addresses that will accept recursive queries from any querier. These findings are bad enough in and of themselves: Hackers can use open recursors as accomplices in distributed Denial of Service (DoS) attacks against targets on the Internet. Open recursive name servers are also more susceptible to cachepoisoning attacks. However, further investigation into the nature of these open recursors revealed a more insidious threat.

A team of researchers (including Georgia Tech’s David Dagon) sent queries to a subset of these open recursors and examined the responses. Most of the responses were correct, but some were wrong—most apparently due to bugs or misconfiguration. But some of the open recursors (about 68,000) returned responses that were both wrong and potentially malicious. These open recursors always returned the same addresses as the response to any query. Many of these addresses appear to belong to open proxy servers in unsavory locations (from an Internet standpoint), such as Russia and China, or on networks flagged to be frequent sources of spam.

Of course, no one in his or her right mind would deliberately reconfigure a computer’s resolver to point to one of these open recursors. Yet, in captures of Georgia Tech’s DNS traffic, Dagon and his team found many computers using these open recursors as primary sources of name resolution. Their resolvers had likely been reconfigured to use these open recursors by malware downloaded from the Internet—many species of malware do just this. Once the computers were thus reconfigured, the responses from the open recursors would shunt all Web traffic through these remote proxy servers, where the data (e.g., passwords, credit card information) could be captured and used maliciously.

Defending Against Resolver Reconfiguration
Besides the standard-issue precautions against downloading malware—such as educating users to employ proper discretion when downloading files from the Internet— there are measures you can take to prevent even compromised computers from falling victim to this scheme. Firewall rules should prevent arbitrary internal computers from querying name servers on the Internet. If malware is successful in changing a computer’s resolver configuration, the resolver will simply stop working. The computer’s user will likely report this problem to IT staff, who can then diagnose the problem, remove the malware, and restore the resolver’s original configuration.

Table 1 shows a set of firewall rules that permits a designated set of internal name servers to query Internet name servers (and receive responses) but deny queries sent directly from internal resolvers to Internet name servers. If possible, the firewall should also use stateful filtering of UDP to acceptUDP datagrams only from the IP addresses of Internet name servers that were recentlyqueried by an internal name server.

Don’t Forget the Client
Like most IT administrators, you might be focusing your efforts on securing name servers, but attacks can also target clients. Due attention is therefore necessary. Successful attacks against resolvers can result in just as much damage—and can be considerably more subtle—than attacks against name servers.

For more helpful DNS best practices and tools, please visit my online library of resources at www.infoblox.com/library/dns_resources.cfm.