Web Proxy Autodiscovery Protocol Hijacking.

Publicated on : 1190142764
In this article I will focus on WPAD and it's security pitfall. And why it only takes one single file to be modified to route all traffic though an malicious proxy server to encompass your whole security model. In my quest to spread the word about why security is just plain useless, I wanted to show you a way of compromising all traffic that is routed through a proxy. No matter if your PC is regularly updated, or has a vigilant patch schedule, or is using state of the art virus scanners and firewall software, we can own you. The reason why we can own you is because it is possible to modify settings how the browser initially connects to the Internet, if you have the Web Proxy Autodiscovery Protocol (WPAD) enabled in your browser, all traffic can be intercepted and modified without your knowledge. All because administrators tend to trust their own configuration. Only when WPAD is enabled in all browsers and served up by a webserver, we could possibly try to hijack all traffic. This might sound rare, but it isn't.

Consider this university that serves up WPAD to it's students:

http://wpad.uoregon.edu/
http://wpad.uoregon.edu/wpad.dat

The surfer needs his browser to be enabled to auto detect it's LAN settings. Why? well, because people are lazy and it also gives somewhat more performance if you use a proxyserver. Now, the drawback of this technology is that if every browser is configured the same way, like in Universities, governmental institutions, or libraries, every browser will use the WPAD protocol to connect to the proxy server and route all traffic through it, depending on it's settings.

The browser looks up the wpad.domain.tld/wpad.dat which is a Javascript file that has instructions for the browser. This all happens before a single page is requested, that means that the local DHCP server tries to query the WPAD URL first, because DHCP has a higher priority than DNS. If the browser cannot locate the WPAD or PAC file it resides back to the plain DNS.

With google we can try to locate WPAD files like so:
http://www.google.com/search?q=inurl%3Awpad.dat
Or just try a domain by entering the wpad prefix:
http://wpad.somedomain.com
Let's asume we are on a university campus at uoregon.edu. All browsers are configured to automatically detect the LAN settings and have given a WPAD or PAC file that instructs the browser to use a local or remote proxyserver.

The browser tries all possible locations automatically:

http://wpad.uoregon.edu/wpad.dat
http://wpad.server1.uoregon.edu/wpad.dat
http://wpad.edu/wpad.dat

Once it finds it, it uses the file to obtain instructions. That WPAD.dat or PROXY.pac contains Javascript.
The following script could be used:

function FindProxyForURL(url,host)
{
// loopback
if ( host == "127.0.0.1" || host == "localhost" )
return "DIRECT";

if ( dnsDomainIs(host, "uoregon.edu") )
return "PROXY proxy.example.edu:8080; DIRECT";
if ( isInNet(host, "192.168.101.0","255.255.255.0") )
return "PROXY proxy.example.edu:8080";
return "DIRECT";
}

This Javascript file wpad.dat or proxy.pac sits on the server and instructs the browser what to use. No matter if you have Javascript disabled, the browser will fetch the Javascript file. Now, the reason why this is so dangerous is because if I can access the wpad.dat file, I could modify the proxy URL and route all traffic through my own malicious proxy that I have set up somewhere. While it's being routed you won't notice that all traffic goes through a malicious proxy, and that proxy is capable of intercepting and modifying all traffic with the right means. So I only have to change one file on that server in order to route all traffic through my own evil proxy server. You probably know how bad security is on university and governmental servers. it should not take much time to find a silly hole in some ASP or PHP script that allows to to upload a shell script that runs a small batch file that replaces the WPAD.dat file with our own.

So remember if that server is unsecured and allows the WPAD file to be altered, it only takes one shot to compromise all traffic. There are some more issues involving WPAD hijacking, and recently it has been discovered that MSIE7 suffers from a DNS traversal problem that was fixed in MSIE5.5. Overall it means that it could be very easy to hijack traffic. Sure, some conditions must be met, and you have to have some luck also. But when you are able or allowed to serve up a new WPAD configuration file, or serve up a bogus DHCP server on that domain, you will be in control.

I hope you enjoyed this article, while it is mostly focused on network security, I think it is relevant to webapplication security also. Because the webapplication layer could facilitate an entry point in order to launch such attack.

Netscape reference: http://wp.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html