WPAD Name Collision Vulnerability – Naked Security


A combination of poorly configured networks and new Internet domain name rules offers cybercriminals a new, easy way to attack entire organizations, according to a University of Michigan study.

The vulnerability, described by US-CERT (the United States Computer Emergency Preparedness Team) in Alert TA16-144A released on May 23, 2016, affects computers that use WPAD.

WPAD is the abbreviation of Web Proxy Autodiscover Protocol, a system that allows organizations to easily configure the many web browsers within their network.

WPAD is supposed to find its browser configuration files on the internal network, but cunning attackers may be able to trick WPAD by downloading tricked versions of these configuration files from the public Internet.

Worse, if you are using a work computer at home and have WPAD turned on, you may very well end up searching for your browser setup every time on the open internet, simply because your work network is not visible.

And the WPAD is very often activated, as the 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 operating systems, as well as Safari, Chrome, and Firefox browsers.

WPAD explained

Organizations typically allow web access through intermediary servers called proxies to improve performance, monitoring, and security.

But that creates a ‘chicken and egg’ problem: How do you tell browsers inside the network which proxy server to use to gain web access in the first place?

The easiest way to answer this question is to use a configuration file called a PAC (proxy auto-config) file that automatically configures the browser.

So, before it can find the proxy server, a web browser needs to know: where is the PAC file?

And this is where WPAD comes in: a WPAD compatible browser will automatically look for a PAC file called wpad.dat on the local network.

The browser determines where to look using the network name of the computer it is on. A browser on a computer with the network name computer.team.division.company.example would search in the following locations, in order:


The .company.example domain is private for 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 that way.

If a web browser is on another network, the one where the DNS servers do not know how to respond to requests for .company.example, these queries can be forwarded to public DNS servers.

According to US-CERT:

The WPAD vulnerability is important to business assets such as laptops. In some cases, these assets are vulnerable even at work, but observations indicate that most assets become vulnerable when used outside of an internal network (e.g. home networks, public Wi-Fi networks) .

It’s a data breach that happens often, according to the University of Michigan:

in two of the 13 DNS root servers, approximately 20 million such requests leak to the public DNS namespace every day. This has been a known problem for years but… were not exploitable before.

This is dangerous because if the attackers could buy the domain name .company.example they could create 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 forum from which to spy on all web traffic passing to and from that browser, extracting personal data or confidential company information and injecting malware or advertisements.

WPAD data leaks have been happening for years, but some companies have avoided the issues despite their poor network setup because, in private, they use their own official top-level domain name, such as .example.com, or a top-level domain coined as .company.test it will not work on the public internet and is not for sale.

The problem is that a recent change in the way global top-level domains (gTLDs) work is changing that.

How the gTLD Project made matters worse

Global top-level domains include names that do not refer to any geographic region, such as .com, .org and .net.

In the beginning, the internet had only 7 gTLDs and the number grew very calmly until 2011 when there were 22.

But in 2012, ICANN (Internet Corporation for Assigned Names and Numbers) opened the doors and started accepting applications for the creation of new gTLDs and today there are over 700.

The expanded gTLD harvest includes everything from .ninja To .city and a number of things that companies could presumably use internally, such as .office, .network, .global and .group.

The domain names that once protected businesses from WPAD data leaks because they only worked inside the company are starting to work outside the company as well – and they’re for sale.

Organizations can no longer assume that the domain names they created for their private DNS will not work on the internet, so the issue of WPAD data leakage has become a real vulnerability.

Researchers at the University of Michigan have shown that WPAD attacks are possible and practical, but not widely exploited:

We find that while some attack surface areas have already been registered, the overall registration and exploitation status is still in its infancy, indicating that proactive protection strategies are still achievable.

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 configuring a device that will not be used on internal networks.
  • Consider using a Global DNS Fully Qualified Domain Name (FQDN) as the root for the enterprise and other internal namespaces.
  • Configure internal DNS servers to authoritatively respond to internal TLD queries.
  • Configure firewalls and proxies to record and block outgoing 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 suffers demonstrably serious damage from name collision while visiting.

Another suggestion from us: do not invent domain names, not even (maybe mostly) for testing or documentation.

If you need sample domain names that do not need to be registered, and no one else will ever be allowed to register for unfair purposes, please see Internet standards documents RFC 6761. (Special-Use Domain Names) and RFC 2606 (Reserved Top-Level DNS Names).


Previous Prime Infra gets the green light from IPs for a water supply project
Next Cloud Domain Name System (DNS) Market Size 2021-2028: Analysis by Key Leadnig Players