Oh, Gimme a Break, Willya?!? Some Details Would be Useful - WPAD
By A. Nony Mous
http://www.computerworld.com/action/article.do?com...014242
There are three kinds of falsehoods; lies, damned lies and statistics. Since there are no quoted numerical data in this article, this is a clear case of damned lies. It makes for an interesting read; if for no other reason, than to demonstrate a fine example of:
- Sensationalistic reporting style
- Fact avoidance
- Credibility self-destruction
Blow-by-blow:
1. Microsoft Corp. is warning”, “the company said” and “Microsoft said” are used throughout the text, but the article ends with the disclaimer “Microsoft staffers were not immediately available to comment.”
Esqueeze you? Unless my English language skills have deteriorated horribly (or I’m having microdot flashbacks again), the author has just discounted his own article in fine style. Either “Microsoft made statements” or it did not. Perhaps a well-meaning editor performed this ill-fated favor for Jeremy, but if so, I would expect that he would at least read those edits. Maybe these statements are in reference to the KB article he links within the article, but none of this is clear.
2. Applications such as Internet Explorer use the Web Proxy Automatic Discovery (WPAD) protocol to find a file that enables a browser to configure its proxy settings. However, it’s possible to plant a configuration file that would route traffic through a malicious proxy”.
Take note; these are the only accurate (although incomplete) statements in the entire article. IE is not the only application to make use of WPAD; Netscape, Opera, Firefox (the list goes on) all have this capability – nor is Windows the only platform where this behavior is observed. If you want to know more about how ISA Server supports this mechanism you can read about it here. If you’re a fan of RFC-style text, you can also read about the WPAD protocol as written by the original authors here. To the point of a malicious WPAD file being placed in the network, causing hosts that request it to use the malicious proxy, this is potentially true, but requires a significant amount of effort by EvilWPADDood. We’ll examine this in more detail in a moment.
3. A malicious WPAD.dat file could be placed in the Domain Name System (DNS) or the Windows Internet Naming Service (WINS),”
Sorry Jeremy, it just ain’t so. Even in the KB article you reference, this statement is nowhere to be found, nor will you locate it in any authoritative text on DNS or WINS. Neither DNS nor WINS deliver any form of a file to the WPAD-seeking host. DNS and WINS serve the same purpose to a WPAD client; namely, that of translating names to IP addresses; but that’s all they do. While DNS does possess the ability to provide text content via TXT records *if requested*, that’s not part of the WPAD process.
4. The fix is for Windows Server 2003 and Windows 2000 Service Pack 4”
Exactly what “fix” is being quoted here? There is no code change in that KB article. To be fair, perhaps Jeremy just doesn’t understand how KB articles are organized. Either way, the statement is completely inaccurate.
Malicious WPAD Threats
Lest you conclude from my tone that I’m minimizing the potential threats posed by a malicious WPAD, think again. The threat is real; just one of incredibly low probability. Should you protect yourself from malicious WPAD registrations in DNS and WINS? Of course you should, if for no other reason, than to reduce the probability of accidental changes that can cause service outages for your users. If you already maintain proper WPAD records, and these records and data are changeable only by your network administrators, then the threat is limited only to their (in)actions.
In order to assess the threat posed by EvilWPADDood, let’s first examine the goals of a malicious WPAD effort:
- Denial of Service. A faulty WPAD file can create a scenario where no one can reach the Internet via their WPAD-dependent applications. The impact of this action is directly proportional to the immediacy of your organization’s dependence on Internet access, although it probably represents an ill-conceived practical joke more than anything else.
- Information Disclosure. A malicious WPAD could redirect all your users’ traffic through a MITM proxy that does nothing more complicated than copying your traffic to the local drive for later perusal at EvilWPADDood’s leisure. The impact of this action is much more subtle and potentially more dangerous, depending of course on the information EvilWPADDood is able to acquire (and understand).
- Plant Malware. If EvilWPADDood can convince your application to acquire and run his script, he can perform any action allowed by that application in the context of the interactive user. Current browser sandboxing mechanisms greatly limit this threat, but the effectiveness of this protection depends on what security options you select and enforce for your WPAD-aware applications.
Note that in all cases, this effort leaves an incredibly well-lit trail that even a noob network admin could follow in his sleep. Basic network forensics will out EvilWPADDood once the problem is discovered and corrected, resulting in his immediate (and hopefully painful) removal from the environment. This assumes, of course, that you don’t subscribe to the theory that “criminals make the best cops”.
In order to accomplish his nefarious goals, EvilWPADDood must be able to:
- Exercise control over your DHCP, DNS and / or WINS servers and their records.
- Deploy a MITM or edge proxy
- Create a WPAD script that redirects all or only the interesting destinations through his MITM proxy or nowhere (useful for the DoS goal).
- Patiently wait for the script to be acquired by the applications (ISA-served IE caches this file for an hour; YMMV)
- Run really fast and hide really well (discovery is simple if you actually monitor your network)
In other words, this threat can only be executed if:
- Its performed by someone with administrative access to your network and support servers, or
- Your DNS records can be updated by anyone (WINS provides no record controls)
If you’ve been paying attention (and I haven’t punched your “sleep button”), it should be immediately obvious that this threat is inversely proportional to your organization’s:
- Network management policies. If you allow any network host to update DNS records, or if anyone on the network can change DHCP, DNS or WINS records, then you’re asking for it and no amount of fake record placement will save you.
- Hiring and people-management skills If you don’t trust your network administrators, you (or your management chain) shouldn’t have hiring or management authority for that organization. Happy, well-adjusted people don’t poop where they feed.
Preventing Malicious WPAD
Can we actually prevent this from occurring? Yes.
Know Your Administrators
This is management 101, folks. Happy people do right by the organization; unhappy people don’t. If you don’t keep touch with the people in whom you place your trust, you can’t possibly see when the happiness quotient starts its decline. Know what motivates them and do your best to fill that intellectual and emotional belly (it really IS both). If you can’t satisfy them because of your or your organization’s limits, maybe it’s best that you seek other opportunities. If the limit is the admin himself, start searching for a replacement. No one person is so critical that you should tolerate a potential threat from them. There is no gain in trying to protect yourself from your network administrators. If you disagree with this statement, please don’t approach me with your resume.
Create valid WPAD records
If you’ve read through the KB referenced in the Computer World article, you’ll find this phrase: “Network administrators who have not already registered legitimate WPAD entries in DNS or in WINS, and network administrators who have not correctly implemented WPAD through DHCP and Option 252…”. Use the force between your ears, Luke. If you create and maintain proper WPAD records, the threat is essentially eliminated (don’t start with the “bad admin” bit again) and you don’t have to create fake DNS and WINS records as directed in KB 934864.
Limit DNS updates to authenticated queries
If you operate a Windows 2000 or later domain and you allow anonymous DNS updates, you’re asking for it. You can still minimize this effect by creating proper records. Additionally, if you employ DHCP 252, you can specify a name other than “wpad” and use WINS or DNS round-robin entries to make sure they point only to your ISA servers. This way, you reduce the question of malicious WPAD considerably.
Summing up
- Is there any form of threat via the WPAD mechanism? – yes, but in a properly-managed organization it’s so small as to be nearly irrelevant.
- Is this a Windows or IE “vulnerability”? – not only no, but Hell No. WPAD is a public protocol, used by a plethora of applications and operating systems, each of them equally “vulnerable”.
- If this threat is so small, why does KB 934864 exist? This article was written to provide a basic answer to the question of “how can I prevent this?” asked by customers.
Greg Mulholland Says:
March 31st, 2007 at 4:33 pm
Wow Tom! i’m guessing whoever A.Nony Mous(e) is that they have looked at the issue in some depth. I agree with the post as it seems to de-bunk the sensationalist, misguided reporting that is far to common.
G
Dan Kaminsky Says:
March 31st, 2007 at 8:14 pm
Tom–
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!
Jim Harrison Says:
March 31st, 2007 at 9:18 pm
Dan,
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.
Dan Kaminsky Says:
April 1st, 2007 at 2:52 pm
1) The details of the work were publicly presented; I’ll try to get the slides up shortly. Send me an email and I’ll send you a copy.
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?
Jim Harrison Says:
April 1st, 2007 at 5:03 pm
1) looking forward to them - the blog might have seemed less nasty if this were available and referenced in the linked article
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)…