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 <ge@linuxbox.org> To: Rickard Dahlstrand <rickard.dahlstrand@iis.se> Cc: dns-operations@mail.oarc.isc.org Subject: Re: [dns-operations] Web Proxy Auto-Discovery (WPAD) Information Disclosure On Tue, 4 Dec 2007, Rickard Dahlstrand wrote:
Gadi Evron wrote:
http://www.microsoft.com/technet/security/advisory/945713.mspx
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 corp.contoso.co.us and an attempt is made to resolve an unqualified hostname of wpad, the DNS resolver will try wpad.corp.contoso.co.us. If that is not found, it will try, via DNS devolution, to resolve wpad.contoso.co.us. If that is not found, it will try to resolve wpad.co.us, which is outside of the contoso.co.us domain.
Most of the wpad.tld domains are already reserved like this one http://wpad.com/ It's amazing that when they fixed it for .com etc. a while back they missed that there where two-level tld-domains.
Rickard.
http://www.microsoft.com/technet/security/bulletin/fq99-054.mspx ----- 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 a.b.Microsoft.com would search for a WPAD server at wpad.a.b.microsoft.com. If it could not locate one, it would remove the bottom-most domain and try again; for instance, it would try wpad.b.microsoft.com next. IE 5 would stop searching when it found a WPAD server or reached the third-level domain, wpad.microsoft.com. 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 xyz.com.au did not have a WPAD server, the search algorithm eventually would reach wpad.com.au, which is an external network name. If the owner of wpad.com.au set up a WPAD server, he or she could provide chosen proxy server configuration settings to the clients at xyz.com.au. For that matter, any network in com.au that didn't have its own WPAD server but did have WPAD enabled in its web clients also would also resolve to wpad.com.au. -----
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. Also: http://www.wlug.org.nz/WPAD ----- (BeauButler?: I have registered wpad.co.nz, 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: https://kiwicon.org/presentations#oddy This is the story that got Microsoft's attention: http://www.theage.com.au/news/technology/flaw-leaves-microsoft-looking-like-... Which is where Beau says there are ~160,000 exploitable machines in NZ alone. He would *supposedly* know since he has the wpad.co.nz 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. Gadi.