Re: [dns-operations] Web Proxy Auto-Discovery (WPAD) Information Disclosure (fwd)
---------- Forwarded message ----------
Date: Tue, 4 Dec 2007 00:56:51 -0600 (CST)
From: Gadi Evron <ge@xxxxxxxxxxxx>
To: Rickard Dahlstrand <rickard.dahlstrand@xxxxxx>
Cc: dns-operations@xxxxxxxxxxxxxxxxx
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-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.