Patch Tuesday can be a long night for a VERT Engineer. With nCircle's 24-hour Patch Tuesday SLA, we work long hours to ensure our customers get the best detection available. These nights are usually filled with coffee, bad jokes and really bad music. Tonight was a little different... as it included a cool yet disturbing discovery. The discovery was that the patch for MS09-008 is highly flawed in it's patching of CVE-2009-0093.
This vulnerability allows users to set a WPAD entry in DNS when dynamic updates are enabled. Internet Explorer, configured to "Automatically Detect Settings", will query for this WPAD value and attempt to download proxy settings from the associated server. This could allow an attacker to Man-in-the-Middle the connection.
The flaw that I discovered is with servers that have already been exploited – in that compromised servers will already contain a WPAD entry. I initially thought, "No Problem! The block list will keep me from getting a response," but I’m a researcher, so I had to be sure.
It turns out that this isn't the case. Instead, the patch checks to see which entries have been created in the DNS server and *only adds block list entries for values not already being served*. In other words, if your DNS server contains an entry for WPAD and you apply MS09-008, the block list will not have WPAD added to it. Subsequent queries for WPAD will continue to be answered and if the WPAD entry is from a previous attack, your users will continue to be Man-in-the-Middled - even after you are patched.
This has serious consequences, as enterprises may mistakenly believe that this vulnerability has been remediated on compromised servers. After all, the patch appears in the 'Remove Programs' dialog and the patch registry keys are created. As a result patch management solutions and Microsoft’s Automatic Update service will likely report incorrectly that the patch has been successfully applied.
To verify that you are indeed effectively patched:
Check that HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters\GlobalQueryBlockList contains both 'wpad' and 'isatap'
Note: Although WINS also makes use of a query block list (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WINS\Parameters\QueryBlockList) WINS is not affected by this issue.
We have contacted Microsoft to notify them of this issue and are awaiting a response. VERT’s checks confirm that the vulnerability has been effectively remediated. If you’re not an nCircle customer, follow up with your vendor to ensure that they are checking for more than just the presence of the patch.
Comments (7)
To patch correctly, in your scenario, wouldn't the patch have to be able to distinguish between malicious and benign WPAD entries? How's it supposed to do that?
Posted by Larry Seltzer | March 11, 2009 3:57 AM
Posted on March 11, 2009 03:57
You're correct, the patch would need a way to tell the difference. Microsoft chose to go the route of 'if not wpad: add to block list'.
The problem is that you may have a malicious wpad entry. It would have made more sense to either.
1) add it to the block list, and notify administrators that they had an existing entry that is now blocked... if that entry is intended, they should remove the block list entry (This increases work, but at least ensures that someone isn't assuming they are patched when they aren't. It also has the added benefit of informing people who may have already been targeted that they have a malicious wpad entry.
2) Not allow dynamic updates for wpad. Instead of blocking query resolution, they could have blocked dynamic updates. Then administrators could manually create their wpad entries and all would be well.
I'm sure there are other approaches that would provide a satisfactory solution as well. I just can't help but think that the chosen solution (skip it if it exists) is the wrong way to go.
Posted by Tyler Reguly | March 11, 2009 4:04 AM
Posted on March 11, 2009 04:04
Tyler - I'm getting the sense from Microsoft docs (http://download.microsoft.com/download/5/3/c/53cdc0bf-6609-4841-a7b9-cae98cc2e4a3/DNS_Server_Global_%20Query_Block%20List.doc) that the GlobalQueryBlockList is new to Windows Server 2008. ("The DNS server role in the Windows Server® 2008 operating system introduces a global query block list that can help reduce this vulnerability.") Are your comments applicable to Windows Server 2003?
Posted by Larry Seltzer | March 11, 2009 2:16 PM
Posted on March 11, 2009 14:16
Larry,
The document definitely applies to Server 2008, it appears as though they backported the functionality to both Server 2000 and Server 2003, as the functionality was seen on all of the operating systems.
Posted by Tyler Reguly | March 11, 2009 2:25 PM
Posted on March 11, 2009 14:25
Surely there are many Windows vulnerabilities through which one could be exploited and then, with the patch applied, "protected" but still exploited?
Maybe I still don't understand what the patch is doing here. Is it doing anything more than GlobalQueryBlockList entries?
Posted by Larry Seltzer | March 11, 2009 5:53 PM
Posted on March 11, 2009 17:53
You just hit on it. There are many vulnerabilities where you can be "protected but still exploited (from a previous attack)".
In this case, however, if you've been exploited, you will not be protected. If you've been exploited already, the protection never happens as the GlobalQueryBlockList entries aren't created.
Posted by Tyler Reguly | March 11, 2009 6:08 PM
Posted on March 11, 2009 18:08
Microsoft has responded to this in their Security Vulnerability Research and Defense blog: http://blogs.technet.com/srd/archive/2009/03/13/ms09-008-dns-and-wins-server-security-update-in-more-detail.aspx
Posted by Larry Seltzer | March 13, 2009 6:36 PM
Posted on March 13, 2009 18:36