Finding Web Proxy Auto Discovery Protocol (WPAD)-related Security Exposures Using Farsight Security's NXDOMAINs Channel
Introduction
Virtually all popular web browsers automatically check Web Proxy Auto Discovery Protocol (WPAD) for hints about web cache appliances that they should automatically configure and begin to use. This can be convenient and advantageous, but it is ALSO a major potential man-in-the-middle (MITM) security risk.
Farsight Security’s new NXDOMAIN channel can help identify domains where WPAD-related security exposures potentially exist, after which those risks can be mitigated (or at least understood and accepted on an informed basis).
Web Proxy Cache Servers
Web proxy cache servers (such as the free/open-source Squid Cache or analogous commercial products) are one potentially effective way to reduce bandwidth requirements and optimize customers’ web experience.
By locally caching frequently requested web content, wide-area bandwidth requirements can be reduced. Depending on the characteristics of a cache’s user base (and the content they tend to access, and how the cache is configured), bandwidth savings may be 50% or more. To understand why this is possible, remember that most people visit a relatively small number of sites, and most of the content on those sites is “static” (relatively unchanging).
For example, assume a much-anticipated new product or service finally gets announced. When that happens, many customers will quickly visit the announcement site to learn more. While those announcement-related web pages could be repeatedly retrieved from their original source, once for each customer who’s interested, it is more efficient to retrieve the pages once, and then temporarily save (or “cache”) a copy of the pages locally to share with others who may also be interested. (Obviously there are many subtle details involved in practically doing this, including things like deciding what pages or page components to cache and which ones not to, and how long stuff should be cached, but that has been extensively studied and worked out, and out of scope for this article)
Offering a local web cache can also accelerate web page delivery by reducing latency and thus minimizing bandwidth-delay products.
Finally, web proxy cache servers, when deployed in an enterprise or institutional setting, can also provide a “choke point” where potentially malicious web sites (or policy-non-compliant web sites) can be characterized and potentially blocked, if appropriate.
Even with these advantages, the ever-decreasing cost of transit bandwidth has driven down interest in web proxy caching services, simply because it can be cheaper to add transit bandwidth than it would be to deploy and maintain web caches. Increasingly pervasive use of https (web encryption) also puts negative pressure on caching technologies since encrypted content normally can’t be cached.
An excellent discussion of additional drivers decreasing the value of web proxy caching can be seen in Barry Greene’s terrific article.
That said, web caching does remain an option, particularly in underserved areas where bandwidth costs still remain high and connectivity tends to be thin, or locations where web content inspection and filtering is required.
And more importantly, virtually all the world’s web browsers still try to use web proxy caches automatically.
How Do Users Get Configured to Use a Web Proxy Cache Server?
Large ISPs that deploy web proxy cache servers normally specify the required settings:
Via DHCP Option 252
Via “transparent web cache redirection” at the network layer or
Via the use of Web Proxy Auto Discovery (WPAD), discussed further below.
When one of those approaches gets used, the customer typically doesn’t even know that their traffic may be getting cached, although there are sites that can help users detect the presence of automatic caching.
Users can also check and manually configure/disable caching in their browser web browser’s proxy cache settings if they want to do so.
Focusing on WPAD
WPAD is an ancient protocol, dating to 1996 and Netscape Navigator 2.0. While widely used, it was never formally standardized and documented by the IETF. See the expired draft here and more information here.
In a nutshell, WPAD attempts to connect users with a proxy autoconfiguration “PAC” file provided by their service provider.
Wikipedia describes the approach that WPAD employs when checking for a PAC file: If, for
example, the network name of the user’s computer is
pc.department.branch.example.com, the browser will try the following URLs in
turn until it finds a proxy configuration file within the domain of the client:
http://wpad.department.branch.example.com/wpad.dathttp://wpad.branch.example.com/wpad.dathttp://wpad.example.com/wpad.dathttp://wpad.com/wpad.dat[…]
That search for wpad.dat configuration files for a user from the hypothetical
example.com domain potentially results in queries for:
wpad.department.branch.example.com, thenwpad.branch.expample.com, thenwpad.example.com, then evenwpad.com(if flawed)
If those hosts don’t exist, the failed NXDOMAIN queries will show up in
FSI’s new NXDOMAINs channel.
The MITM Exposure
Especially if your enterprise or ISP doesn’t use a web cache and doesn’t have a WPAD server, the WPAD protocol, embedded and enabled in virtually every web browser by default, represents a significant potential man-in-the-middle attack vector since your browser will automatically look for WPAD hosts that want to give it a PAC file.
For example, imagine if a malicious eavesdropper creates their own proxy server
and then registers the hostname wpad.somedomain.com, as they may be able to
do if that hostname isn’t already in use or reserved/forbidden from being
registered).
The eavesdropper can then create a privacy-invasive proxy autoconfiguration file, install it on their WPAD server, and use it to eavesdrop upon other customers’ traffic as that traffic gets redirected through the proxy server under the control of the malicious user.
This obviously has the potential to undermine user privacy, if successfully exploited.
The security implications of WPAD are NOT a new discovery; see for example
“Microsoft confirms man-in-the-middle WPAD vulnerability” from December 2007,
or
“WPAD: Internet Explorer’s Worst Feature” from January 2008.
While both of those articles refer to Microsoft Internet Explorer, WPAD is supported by virtually all popular modern browsers.
Are Users’ Browsers Really Querying for WPAD Hosts?
You betcha, all the time. You can see this if you have access to FSI’s new NXDOMAINs channel:
From a blade server with access to Channel 221 at Farsight’s Security Information Exchange (SIE):
$ nmsgtool -C ch221 | grep wpad | grep qname | awk '{print $2}'
[WPAD names will scroll by until you hit control-C]
Or, if you’ve purchased access to Channel 221 via SIE Remote Access (SRA), and wanted to look for domains with WPAD queries you could say:
$ sratunnel -s 'ssh username@server' -c 221 -w ch=221 -o nmsg:udp:127.0.0.1,8000 &
$ nmsgtool -l 127.0.0.1/8000 | grep wpad | grep qname | awk '{print $2}'
[WPAD names begin to scroll by after a few seconds]
$ kill %sratunnel
What Should You Do?
While all of the above may be of some general interest, at least some of you may wonder, “What specifically should I do given this information?” That will depend on the sort of person you are.
Security Researchers
If you’re a security researcher and you’re not currently subscribing to Farsight Security’s new NXDOMAINs channel, you might want to give Farsight Sales a call and arrange to check it out. WPAD exposures are just one example of a security vulnerability that can easily be spotted in the NXDOMAINs channel
Domain Owner or Authoritative DNS Admin
Ensure that the wpad.whateverdomain hostname (AND the corresponding wpad
hostnames for any or all subdomains you use) are “well-controlled.”
That means that they should either be registered to the domain owner or his designated person, OR blocked from registration by anyone.
End User or Site Admin
Review your system, your browser and other applications for their current proxy-related settings. If your site requires use of a proxy, obviously you don’t want to break that (or your access to the Internet will stop working).
However, if your site does NOT use a proxy, or you want to opt out from using an OPTIONAL proxy service that’s offered, ensure you do NOT have proxy autodiscovery enabled.
Proxy autodiscovery settings may be set at the operating system level, the application level, or both.
Proxies are often thought of as being used primarily by web browsers, but they may also be used in other applications, too (for example, if you’re fond of Mozilla products, check the Thunderbird email client as well as the Firefox web browser).
Some starting points for users and site admins interested in proxy-related settings:
Apple Mac
OS X 10.10.5 (Yosemite)
- Apple –> System Preferences… –> Network –> [click on network connection being used] –> Advanced –> Proxies
Note: Chrome and Opera typically use the system’s proxy-related settings by default
Firefox 40.0.3 (current version)
- Firefox –> Preferences –> Advanced –> Network –> Connection –> Settings –> Network –> Change Proxy Settings
Note: Firefox may be configured to use the system settings or its own application specific settings.
Microsoft Windows
You’ve now seen how WPAD, a little known feature, can potentially have a big impact on the security and privacy of your browser. You’ve also learned how Farsight Security’s NXDOMAINs channel can help you see where WPAD exposure may currently exist, and how to address that vulnerability.
Joe St Sauver, Ph.D. is a Scientist with Farsight Security, Inc.
