Skip to main content

Microsoft reopens WPAD Vulnerability from 1999.

Apparently MSFT hasn't had enough vulns lately.  They decided to reintroduce one (or never fix it in the first place).

From 1999.

Reported last week at a "ethical hacker conference" in New Zealand by Beau Butler, the WPAD vulnerability allows you to perform a man-in-the-middle attack for hostnames that do not have a FQDN.    Essentially, what happened is Microsoft fixed it back in 1999, and it's taken this long to figure out that they only fixed it for ".com".  Other extensions weren't fixed at all ".au", ".nz" for example.

Some blogs have picked this up and said "Zero Day!!!"  But it's not.  It's the same one from 1999.

Here is a link to the Microsoft Security Advisory posted yesterday.

It lists several mitigating factors.
• Customers who do not have a primary DNS suffix configured on their system are not affected by this vulnerability. In most cases, home users that are not members of a domain have no primary DNS suffix configured. Connection-specific DNS suffixes may be provided by some Internet Service Providers (ISPs), and these configurations are not affected by this vulnerability.
• Customers whose DNS domain name is registered as a second-level domain (SLD) below a top-level domain (TLD) are not affected by this vulnerability. Customers whose DNS suffixes reflect this registration would not be affected by this vulnerability. An example of a customer who is not affected is or, where “contoso” and “fabrikam” are customer registered SLDs under their respective “.com” and “.gov” TLDs.
• Customers who have specified a proxy server via DHCP server settings or DNS are not affected by this vulnerability.
• Customers who have a trusted WPAD server in their organization are not affected by this vulnerability. (See the Workaround section for specific steps in creating a WPAD.DAT file on a WPAD server.)
• Customers who have manually specified a proxy server in Internet Explorer are not at risk from this vulnerability when using Internet Explorer.
• Customers who have disabled 'Automatically Detect Settings' in Internet Explorer are not at risk from this vulnerability when using Internet Explorer.

In my opinion, this is weak.  That's apparently Secunia's opinion as well.  As they rated it "less critical".

My question is, did MSFT re-introduce this vulnerability?  Or did they just half ass fix it in `99?

The following OS'es are affected:
Microsoft Windows 2000 Advanced Server
Microsoft Windows 2000 Datacenter Server
Microsoft Windows 2000 Professional
Microsoft Windows 2000 Server
Microsoft Windows Server 2003 Datacenter Edition
Microsoft Windows Server 2003 Enterprise Edition
Microsoft Windows Server 2003 Standard Edition
Microsoft Windows Server 2003 Web Edition
Microsoft Windows Vista
Microsoft Windows XP Home Edition
Microsoft Windows XP Professional


Popular posts from this blog

Offset, Depth, Distance, and Within

Without going off the deep-end here and discussing every single Snort rule keyword, I just wanted to touch on a few modifiers that people sometimes misunderstand.  They aren't difficult, and hopefully after this explanation and a few examples, I can clear some of the air around these five modifiers.

The five modifiers that I am talking about are
OffsetDepthDistanceWithinnocaseThese five modifiers are not keywords of themselves, but rather they apply as modifiers to another keyword.  That keyword is "content". The content keyword is one of the easiest pieces of the Snort rules language as all it does is look for a particular string.  So for instance if I wanted to look for the word "joel" within a packet.  A simple:
content:"joel";Would allow me to do that.  The interesting part comes into play when you want to specify where inside of a particular packet you want the string "joel" to be looked for.  If you are running just a plain content ma…

Writing Snort Rules Correctly

Let me start off by saying I'm not bashing the writer of this article, and I'm trying not to be super critical.  I don't want to discourage this person from writing articles about Snort rules.  It's great when people in the Snort community step up and explain some simple things out there.  There are mistakes, it comes with the territory.  If you choose to be one of the people that tries to write Snort rules, you also choose to be someone who wants to learn how to do it better.  That's why I write this blog post, not to bash the writer, but to teach.

I noticed this post today over at the "Tao of Signature Writing" blog, and to be honest I glanced over most of it figuring it was a rehash of things I've already read or things that have already been written from countless people about "Here's how you write Snort rules!".  I scrolled down quickly skimming, not reading at all really, and noticed this part:
Now, let us look at the second questio…

Safari 5.1.4 now available

Safari 5.1.4 now available, fixes issues and improves performance | TUAW - The Unofficial Apple Weblog:

Improve JavaScript performanceImprove responsiveness when typing into the search field after changing network configurations or with an intermittent network connectionAddress an issue that could cause webpages to flash white when switching between Safari windowsAddress issues that prevented printing U.S. Postal Service shipping labels and embedded PDFsPreserve links in PDFs saved from webpagesFix an issue that could make Flash content appear incomplete after using gesture zoomingFix an issue that could cause the screen to dim while watching HTML5 videoImprove stability, compatibility and startup time when using extensionsAllow cookies set during regular browsing to be available after using Private BrowsingFix an issue that could cause some data to be left behind after pressing the "Remove All Website Data" button