Yesterday the US-CERT released a Technical Alert (TA16-144A) about the recently found WPAD Name Collision Vulnerability. We will give you a summary about the vulnerability as well as the basic mechanisms here.
The Web Proxy Auto-Discovery Protocol is used to auto-configure the proxy for web browsers. So when joining the according network the browser can use DHCP and DNS methods to find a specific configuration file (typically named wpad.dat), which is loaded and applied to the browser’s settings. Therefore, there is no need to configure each browser in your environment individually/manually.
Since the beginning of 2012, the ICANN is open for applications for new gTLDs (generic Top Level Domains). This can also be used by companies to register their name as TLD. For example, we could apply for the TLD .ernw, to present you this blog on insinuator.ernw.
Still, it was and is possible to configure an internal DNS server to resolve such arbitrary TLDs. Continuing the above example we could configure our internal DNS to resolve printer.ernw to our printer-server, which still would not be publicly resolvable.
So what would happen if the “printer.ernw” DNS request would reach a public DNS-Server? Well, the DNS could not resolve the address – at least not unless someone registers .ernw as a TLD. Getting back to WPAD, a browser might try to load the proxy configuration file by trying to access http://proxy.ernw/wpad.dat (again just an example), as the DHCP Server told that the file can be found there. Now there are certain situations, where the DNS request for proxy.ernw can reach public DNS Servers, e.g. when one uses his business laptop at home.
An attacker could now register the according TLD and provide a proxy configuration file on the example URL mentioned above. Of course, this configuration file would point to his own proxy server, which in that case would be used by the browser. And -boom- you have a Man-in-the-Middle scenario, where the attacker can see the whole browser traffic. Depending on the browser and OS this proxy might even be set as system proxy and then traffic from other programs might be routed through the attacker’s proxy.
The Technical Alert already contains a solution for vulnerability, so we will not repeat them here, but instead give you a quick checklist to see if your corporate network is save:
- If you only use the fully qualified domain name of your company also for internal systems, you are safe. (E.g. the proxy configuration file is found at proxy.yourcompany.com/wpad.dat)
- If you don’t have proxy auto-configuration enabled on your workstations (or even don’t have a proxy), you are save.
- If you already have your companies gTLD registered publicly (so that proxy.yourcompany resolves to your own systems anyway) and use that URL for your proxy auto-configuration, you are save.
We hope this helps you to sort out open questions and give you an general understanding of the issue.