Post by Rickard DahlstrandPost by Gadi Evronhttp://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.
-----
Post by Rickard DahlstrandFrom 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-a-turkey/2007/11/23/1195975914416.html
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.
