The WPAD Vulnerability I Discovered After Installing Pi-Hole!
So, if you have your own internal LAN network, and if you setup your domain extension to meld with your web-site (which I do), and you install Pi-Hole… you get a surprise! The number one blocked site that first day I set up Pi-Hole was a site that was getting a lot of referrals, and that was “wpad.drbillbailey.net”! Wha….?!?!? There is no “wpad.drbillbailey.net”! So, I found this article:
When domain names attack: the WPAD name collision vulnerability
Naked Security by Sophos – By: Mark Stockley – “A combination of poorly configured networks and new rules on internet domain names are giving cybercriminals a new and easy way to attack entire organizations, according to research out of the University of Michigan.
The vulnerability, described by US-CERT (the United States Computer Emergency Readiness Team) in alert TA16-144A issued 23 May 2016, affects computers that are using WPAD.
WPAD is short for Web Proxy Autodiscovery Protocol, a system that makes it easy for organizations to configure the many web browsers inside their network.
WPAD is supposed to find its browser configuration files on the internal network, but wily attackers may be able to trick WPAD into downloading booby-trapped versions of those configuration files from the public internet instead.
Worse still, if you use a work computer at home, and WPAD is enabled, you may very well end up searching for your browser configuration on the open internet every time, simply because your work network isn’t visible.
And WPAD very often is enabled, as US-CERT points out:
WPAD is enabled by default on all Microsoft Windows operating systems and Internet Explorer browsers. WPAD is supported but not enabled by default on Mac and Linux-based operating systems, as well as, Safari, Chrome, and Firefox browsers.
WPAD explained
Organizations typically allow access to the web through intermediary servers called proxies to improve performance, monitoring and security.
But that creates a “chicken-and-egg” problem: how to tell the browsers inside the network which proxy server to user in order to get web access in the first place?
The easiest way to answer that question is with a configuration file called a PAC (proxy auto-config) file that sets the browser up automatically.
So, before it can find the proxy server, a web browser needs to know: where’s the PAC file?
And that’s where WPAD comes in – a WPAD-enabled browser will automatically look for a PAC file called wpad.dat on the local network.
The browser works out where to look by using the network name of the computer it’s on. A browser on a computer with the network name computer.team.division.company.example would look in the following locations, in order:
wpad.team.division.company.example/wpad.dat
wpad.division.company.example/wpad.dat
wpad.company.example/wpad.dat
The .company.example domain is private to the organization’s network and DNS lookups for *.company.example domains are supposed to be answered by the organization’s own DNS servers.
Unfortunately it doesn’t always work out that way.
If a web browser finds itself on another network, one where the DNS servers don’t know how to respond to queries for .company.example, those queries may be escalated to public DNS servers.
According to US-CERT:
The WPAD vulnerability is significant to corporate assets such as laptops. In some cases these assets are vulnerable even while at work but observations indicate that most assets become vulnerable when used outside an internal network (e.g. home networks, public Wi-Fi networks).
It’s a data leak that happens a lot, according to the University of Michigan:
in two of 13 DNS root servers, roughly 20 million such queries are observed to be leaking to the public DNS namespace every day. This has been a known problem for years but … were not exploitable previously.
This is dangerous because if attackers were able to purchase the domain name .company.example they could put up a website at wpad.company.example and publish their own PAC file that tells browsers to use the attacker’s proxy server.
The attacker would then have a grandstand seat from which to spy on all the web traffic passing to and from that browser, extracting personal data or confidential company information and injecting malware or ads.
WPAD data leakage has been going on for years but some companies have avoided trouble in spite of their poor network configuration because in private they use their own, official top-level domain name, like .example.com, or a made-up top-level domain like .company.test that won’t work on the public internet and isn’t for sale.
The problem is that a recent change in the way that global top-level domains (gTLDs) work is changing that.
How the gTLD project made it worse
Global top-level domains include names that don’t denote any geographical region, such as .com, .org and .net.
In the beginning, the internet had just 7 gTLDs and the number grew very sedately until 2011, by which time there were 22.
But in 2012 ICANN (the Internet Corporation for Assigned Names and Numbers) threw the doors open and started taking applications for the creation of brand new gTLDs and today there are more than 700 of them.
The expanded crop of gTLDs includes everything from .ninja to .city and a number of things that companies might plausibly use internally such as .office, .network, .global and .group.
Domain names that once kept companies immune from WPAD data leakage, because they only worked inside the company, are starting to work outside the company too – and they’re up for sale.
Organizations can no longer assume that the domain names they made up for their private DNS won’t work on the internet, so the problem of WPAD data leakage has become a genuine vulnerability.
The researchers at the University of Michigan have shown that WPAD attacks are possible and practical but not widely exploited:
We find that even though some attack surface domains have already been registered, the overall registration and exploitation status are still in the early stage, indicating that proactive protection strategies are still feasible.
US-CERT recommends that administrators take the following steps to mitigate this vulnerability:
- Consider disabling automatic proxy discovery/configuration in browsers and operating systems when you set up and device that will not be used on internal networks.
- Consider using a fully qualified domain name (FQDN) from global DNS as the root for enterprise and other internal namespace.
- Configure internal DNS servers to respond authoritatively to internal TLD queries.
- Configure firewalls and proxies to log and block outbound requests for wpad.dat files.
- Identify expected WPAD network traffic and monitor the public namespace or consider registering domains defensively to avoid future name collisions.
- File a report with ICANN if your system is suffering demonstrably severe harm as a consequence of name collision by visiting.
- One more suggestion from us: don’t make up domain names, not even (perhaps especially) for testing or documentation.”