North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: [dns-operations] Web Proxy Auto-Discovery (WPAD) Information Disclosure (fwd)

  • From: Gadi Evron
  • Date: Tue Dec 04 09:56:53 2007

I was told I should care about smaller entities that ccTLDs on this, so here is a forward to NANOG of a discussion on DNS-operations.

---------- Forwarded message ---------- Date: Tue, 4 Dec 2007 00:56:51 -0600 (CST) From: Gadi Evron <[email protected]> To: Rickard Dahlstrand <[email protected]> Cc: [email protected] Subject: Re: [dns-operations] Web Proxy Auto-Discovery (WPAD) Information Disclosure

On Tue, 4 Dec 2007, Rickard Dahlstrand wrote:
Gadi Evron wrote:

A malicious user could host a WPAD server, potentially establishing it as
a proxy server to conduct man-in-the-middle attacks against customers
whose domains are registered as a subdomain to a second-level domain
(SLD). For customers with a primary DNS suffix configured, the DNS
resolver in Windows will attempt to resolve an unqualified .wpad. hostname
using each sub-domain in the DNS suffix until a second-level domain is
reached. For example, if the DNS suffix is and an
attempt is made to resolve an unqualified hostname of wpad, the DNS
resolver will try If that is not found, it will
try, via DNS devolution, to resolve If that is not
found, it will try to resolve, which is outside of the domain.

Most of the wpad.tld domains are already reserved like this one It's amazing that when they fixed it for .com etc. a
while back they missed that there where two-level tld-domains.

What's the problem with the search algorithm?
When IE 5 starts, it will begin searching for a WPAD server, if it is configured to use WPAD. It starts the search by adding the hostname "WPAD" to current fully-qualified domain name. For instance, a client in would search for a WPAD server at If it could not locate one, it would remove the bottom-most domain and try again; for instance, it would try next. IE 5 would stop searching when it found a WPAD server or reached the third-level domain,
The algorithm stops at the third level in order to not search outside of the current network. However, for international sites, this is not sufficient, because third-level domains can be outside the current network. For example, if the network at did not have a WPAD server, the search algorithm eventually would reach, which is an external network name. If the owner of set up a WPAD server, he or she could provide chosen proxy server configuration settings to the clients at For that matter, any network in that didn't have its own WPAD server but did have WPAD enabled in its web clients also would also resolve to
From the FAQ for the 1999 fix...

It is quite possible, and we can assume (until someone tells us they know), that they fixed it for ccTLDs as well, and then re-introduced the flaw somehow.

(BeauButler?: I have registered, and do not intend to be 'really nasty'. I am collecting the 404 logs with the intention to produce some nice charts, hoever. Also, the wpad organisational-boundaries bug appears to have resurfaced in Internet Explorer 7!!)
Beau Bulter is the guy who got all the press by talking about this at kiwicon last week:

This is the story that got Microsoft's attention:
Which is where Beau says there are ~160,000 exploitable machines in NZ alone. He would *supposedly* know since he has the domain.

Whether it is a major issue or not, misconfigurations happens, heck, shit happens. I'd think we should watch for this and get that domain registered/monitored at different ccTLDs.