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
Register
