2) I have no doubt that you speak from real experieence, but in fact, it’s not “the default” as the original article seems to indicate.

3) user-agents don’t necessarily mean “direct to service” ot “IE-handled” HTTP traffic; it’s a simple matter to specify the user-agent to be used by both WinInet and WinHTTP. My http_test script does exactly that.

Also, you seem to be hung up on the “user creds”. Yes; you can get the domain\username, and from that, a dictionary attack is far more plausible, but by default, you can’t “use” NTLM credentials anywhere except where they are provided. As far as what you can do with those credentials, that’s dependent on the trust level applied to your malicious web/proxy server by the domain. If you’re able to get this machine trusted for delegation, you are either an internal admin or the domain was already compromised.

Yes; the question of grabbing credentials off the wire is a bad one (part of the MITM scenario I listed as part of the threat groups), but ignoring the potential for a malicious wpad seems a bit short-sighted, IMHO. Anyone with the skills to register a fake wpad and deploy a credentials-grabbing web server should be expected to also have the skills to write the basic JScript that comprises every WPAD.dat (the default request for any wpad-consuming client) script ever created. From here, our enterprising jerk can do much more than simply snatch NTLM credentials; they can monitor the traffic sent between the client and the real proxy or upstream server. In this way, they can operate much longer without attracting attention. A credentials-grabbing web site that simpy disconnects after authenticating the user is going to attract attention as the Internet access stops dead.

I’m not arguing that the mitigation steps are invalid - in fact, they’ll work exactly as described. My issue is with the minimalist nature of the article (ok; maybe “gimme a break” was a bit much, but Jertemy really torqued my screws). There are few things I hate more than “just enough information to cause too much concern”. The article spent more time on “looky mommy!” than it did with “this is a good, easy answer”.

Sorry, Dan - ISA does not (never did) “register” anything in DNS, WINS, or DHCP. If you observed this in your environment, it is because a human made it so. If you mean ISA responds to requests for “http://isaserver/wpad.dat” or “http://isaserver/wspad.dat”, that’s a different matter and even then, this doesn’t happen by default; enabling a response to this specific request also requires human intervention (enabling auto-discovery).

Looking forward to the article just the same (or maybe more)…

2) I’ve been to quite a few places where a machine can get into the namespace simply by turning on. Usually, this is because of WINS, but DHCP->DNS is seen as well (better compatibility with non-Windows systems). Here’s the requirements:

a) Must be easy to register names anonymously
b) Must not have WPAD name already registered
c) Must have Windows machines on network

3) They’re WPAD aware, but not WPAD by default. In the field, when you turn on the WPAD spoofer, you get lots of Windows services (remember, they have Agent strings), a number of IE browsers, and no Firefox.

Now, lets get to your next paragraph. You most certainly are splitting hairs: Yes, all I can register is an address, but at that address, all I need to put is a web server hosting a single text file. That address can be anywhere on the Internet — if for some strange reason I didn’t want to put a web server on the actual network, I could put it off in Malaysia and clients would go grab their proxy script from there. “An attacker would have to know how to put up a web server and a proxy server” is not exactly a high bar to jump.

WU will probably use machine creds, but CryptoAPI runs as the user (in some cases, anyway).

I’m not sure why you keep harping on MITM. This isn’t like the old school MITM’s where I need to break into routers or get into the physical path. This is like FX’s attacks back in 2003, where I could attack spanning trees on switches and get myself onto any VLAN I wanted, company-wide. Any port, even in the lobby, and I win. That’s not so good.

The only “fact” you’re really attacking is that the wpad.dat file is stored directly in DNS. OK, fine. There’s a layer of indirection that the reporter missed. But “Oh gimme a break, willya?” is a bit much. At the end of the day:

1) I do this.
2) I take over Google, and get NTLM user creds from lots of people.
3) You read the news article.
4) You follow the steps in the KB article.
5) I can’t do this anymore.

This seems like a good outcome. This entire blog post seems to say, “The threat is overblown, you shouldn’t register these names”, and I believe that’s a disservice to good security administration.

BTW, I know ISA Server registers WSPAD; are you sure it doesn’t register WPAD too?

The article that spawned this blog lists nothing of any work performed by anyone at all. The focus of this missive is the manner in which the issue is raised and discussed; the discussion around the issues and threat model are merely “first-run”. I have no doubt that more time spent digging can certainly result in more interesting scenarios.

1) Since any collaboration between IOA and MS on this issue is covered under NDA, it’s clearly not subject for discussion in a public forum; much less a ComputerWorld article and is therefore inarguable for either side here. If the details of this work become public, then perhaps we can argue specific points.

2) Windows DHCP servers will behave according to the way they’re configured. Yes, by default, DHCP will attempt to register DNS records, but 99.444% of the time, this fails because most admins don’t understand the required steps to take to make this work. By defualt, it does not work, making this question moot. There are specific steps that have to be taken to make this process function correctly, and therefore, the DHCP registration of DNS-based WPAD records is much less of a threat. There is no argument that WINS provides absolutely no protection against malicious name registrations.

3) IE is not the only wpad-consuming browser. I’ve personally tested Firefox and Netscape (8x or greater) and found them both to be wpad-aware. Whether this exists by default or not is orthogonal. If your applications seek a wpad name record, they’re potentially vulnerable. FF will also provide NTLM credentials to the requesting site or proxy in the local network. This is the way this stuff was designed to operate.

No one is splitting any hairs; the core of this threat is that the client uses the WPAD DNS / WINS name query to locate the host where it can acquire a script that causes it to act in accordance with EvilWPADDood’s wishes. Take the IE example, since it’s the favored here. IE will attempt to acquire a script from the host referenced by a successful wpad name query. If this script cannot be obtained, or the script execution results in an error, IE will choose “direct” and move forward on that basis; as will FF and NS. Unless the client acquires a functional script that redirects them to a malicious host (MITM proxy, etc.), the “attack” is little more than a DoS. Yes; the earlier you can prevfent this attack, the better, but the point is that the name registrations alone constitute a small threat.

Windows Update and CryptoAPI use the credentials available to them; if no one is logged on, they use machine or service account credentials (the main part of WU pain for those who force authentication at their ISA). FWIW, the credentials theft question falls sqaurely into the MITM category outlined in the blog.

No one is trying to discount Chris’ work. What’s being discounted is a poorly-researched and -written news article that combines a vagure reference to a KB with inaccurate “facts”. I’ll be very interested in seeing how deep you and Chris have taken the attack methodology.

BTW, ISA creates no WPAD registrations whatsoever; this is performed by the network admin or not at all.

No, it’s a little worse. My apologies though, I don’t think Chris Paget has posted the slides from Shmoocon on the IOActive website yet.

A couple things you’ve missed:

1) IOA worked rather closely with Microsoft on this issue, in finding it, in measuring the impact, and in developing the fix.
2) DHCP servers will commonly register entries in DNS for anonymous parties. WINS of course will also do such registrations. They’re both pretty good at blocking registrations of existing records. It’s when there is no record, that a problem happens. Unfortunately, very few places have WPAD registrations, so it’s easy to take the name.
3) IE will happily provide NTLM credentials to any proxy, and any site that requests it. Furthermore, WPAD attackers get access to the Local Intranet zone, exacerbating the impact of a vulnerability in the browser.

You’re splitting hairs with wpad.dat. DNS and WINS provide the address from which to download wpad.dat. Also, IE is in fact the only browser to enable WPAD by default, though in normal usage it should disable itself. This disabling doesn’t appear to be completely perfect, though, and won’t cover new users that show up post-infection. It also does not cover various Window services, such as Windows Update or CryptoAPI, which will continue to acquire WPAD resources and will provide NTLM credentials to an attacker.

Again, let me repeat that: IE and Window Services are fundamentally more vulnerable to the WPAD issue, because only they have scenarios that enable WPAD by default. Please let us know if you find anything else!

Your faith in discoverability is also misplaced. As an attacker, I can add and remove registrations at will, in both DHCP and WINS. I showed three years ago how easy it is to tunnel massive amounts of data with DNS; three years later, it’s still a trivial way to tunnel through wireless access points. People monitor what they know to worry about; the reality is that this wasn’t on anyone’s radar to even be aware of. Even when people know the risk, they might not even look. We can only do our best to let people be aware of the risks they’re in.

As was said in the article, this wasn’t a disaster of epic proportions, but it is something people should be aware of, and can fix very easily with the fix that we worked with Microsoft to design. Please keep in mind that I have no way to attack your DNS server normally to register www.google.com; it’s not the server that hosts the zone. But, if I use WPAD, then suddenly I’m able to get Google to come to me. That’s a security problem, and we recommend that people deploy the fix.

You’re welcome to contact me if you have any further questions about this. Chris put a lot of time into figuring out exactly how this is and isn’t vulnerable, and I don’t think you’re capturing all that he’s done.

–Dan

P.S. Given that this is isaserver.org, most people here should have ISA server, and thus will hopefully already have WPAD registrations as created by ISA. So hopefully nobody here is affected!

G