Oh, Gimme a Break, Willya?!? Some Details Would be Useful – WPAD

By A. Nony Mous

http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9014242

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:

1. Sensationalistic reporting style
2. Fact avoidance
3. 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:

1. 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.
2. 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).
3. 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:

1. Exercise control over your DHCP, DNS and / or WINS servers and their records.
2. Deploy a MITM or edge proxy
3. Create a WPAD script that redirects all or only the interesting destinations through his MITM proxy or nowhere (useful for the DoS goal).
4. Patiently wait for the script to be acquired by the applications (ISA-served IE caches this file for an hour; YMMV)
5. 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:

1. Its performed by someone with administrative access to your network and support servers, or
2. 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:

1. 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.
2. 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

1. 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.
2. 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”.
3. 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.