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.

I wanted to share the response that I received from Microsoft and provide some of my own feedback. I must admit that I was initially floored by their response, which was:

"Thanks for bringing this to our attention. While I understand your concern, this is in fact expected functionality of the security update."

[removed discussion of issue]

There are important reasons why this path was chosen: it is not possible to tell legitimate WPAD entries from illegitimate ones that were loaded by attackers. Hence our need to accept an already "existent" entry as being valid.

They also pointed me to a KB that references this issue. What's interesting is that this KB wasn't referenced in the advisory release; it was added today as a 'Minor Update'

V1.1 (March 11, 2009): Clarified that CVE-2009-0093 does not apply to supported editions of Windows Server 2008. Added a link to Microsoft Knowledge Base Article 962238 under Known Issues in the Executive Summary. Clarified what systems are primarily at risk for CVE-2009-2033. Finally, updated a finder acknowledgment for CVE-2009-0233 and CVE-2009-0234.

1. This was not a newly discovered vulnerability. How to exploit the vulnerability was already public knowledge.
2. This public discussion did not benefit malicious individuals. It did, however, raise some awareness with Microsoft's customers who may believe they are adequately protected when they are not.

So why was I floored by Microsoft's response? They didn't actually patch this vulnerability; instead they introduced a means of mitigation and deployed that mitigation in the update. That alone would be fine. The issue I have is that they have punted security altogether in the interest of functionality. The responsible thing to do would be to find a balance between the two.

There are a number of approaches that Microsoft could have taken here, that they chose not to take:

1. Provide a simple message during installation of the patch, notifying the user of existing wpad or isatap entries in the DNS server zones and informing them that the intended mitigation would not be applied.
2. Modify the way that dynamic updates work to provide a dynamic update block list, restricting wpad or isatap from being updated dynamically. As it stands right now you can still submit updates for these, they just wont be resolved if they exist in the global query block list.
3. Add both entries to the global query block list and allow users to go back and remove them if the functionality was required.
4. Bring this case to the public as part of the original Advisory if they already knew about it.

These are quick examples from a long list of alternative approaches that could have been taken - each of which would have provided more responsible guidance to their customers than the "don't ask; don't tell" method that they chose.

I'm probably the the biggest Microsoft supporter within VERT. I'm a huge fan of the work they've done to improve security across the board. That being said, I can't help but see this as a step backwards. I understand the need to preserve functionality, but not at the cost of sweeping security issues under the rug. Simply providing a comment within the original advisory would have been a step forward. Instead, no notification was provided to their customers until after I had brought the issue to their attention. Even then, the response was a single line linking to a KB. That KB contains a list of other KBs and one of those contains a single line indicating that this may occur. This suggests that Microsoft was aware of this issue and released their update with minimal concern for security. I believe their customers deserve more.

Earlier today, Larry Seltzer commented that "Microsoft updates don't undo exploits". This is 100% true; however undoing the exploit in this case would be reverting a configured wpad/isatap entry. I'm not asking Microsoft to undo exploits; I'm simply asking that they provide the mitigation that their advisory claims it will provide or proactively advise customers that a particular risk has been accepted on their behalf.

In this case, they provided neither guidance nor remediation.

Winner: functionality by technical knock out.

Recently Microsoft released a blog post addressing MS09-008, after I raised an issue with it. I think it's clear where my colleagues and I stand on the issue, but here's a quick summary for those who haven't been following ...

The MS09-008 "patch" provides the functionality to apply a mitigation (Global Query Block List) and the application of the mitigation. One of my colleagues even coined the term "patchigation", since the issue is never actually patched. To patch the issue Microsoft would have had to block the ability to set wpad and isatap entries dynamically and they chose not to do this. Instead they have mitigated the risk of a malicious entry by providing a method of blocking the valid response from being sent.

So where does that leave us?

• Before Patchigation
1. Attacker sends Dynamic Update to set the wpad entry to a malicious target
2. DNS Stores wpad entry
3. Victim queries DNS and is provided the malicious wpad entry
• After Patchigation
1. Attacker sends Dynamic Update to set the wpad entry to a malicious target
2. DNS Stores wpad entry
3. Victim queries DNS and is told the address doesn't exist
• After a proper Patch (which isn't available)
1. Attacker sends Dynamic Update to set the wpad entry to a malicious target
2. DNS Rejects wpad entry

• After Patchigation - no wpad
1. Attacker sends Dynamic Update to set the wpad entry to a malicious target
2. DNS Stores wpad entry
3. Victim queries DNS and is told the address doesn't exist
• After Patchigation - wpad (valid or malicious)
1. Attacker sends Dynamic Update to set the wpad entry to a malicious target
2. DNS Stores wpad entry
3. Victim queries DNS and is provided the malicious wpad entry

But I thought I was patched? Why didn't Microsoft inform me about this?

To be fair, Microsoft did provide information about this (strictly speaking) - the advisory contains a Known Issues link that points to a knowledge base and that knowledge base contains a single line, halfway down the page to inform you that wpad and isatap entries won't be created if they existed prior to the host being patchigated. It's not directly referenced in the advisory, and the Known Issues" link wasn't added until after I contacted Microsoft and wrote my initial blog post, but I digress ...

Microsoft has since commented that it is not the goal of an update to undo an attack that has already taken place and that customers are encouraged to apply the update. I do not believe they should aim to undo previous attacks and I firmly believe that customers should apply the update. The update addresses more than the WPAD issue and we have encouraged our customers to apply the update from the time it was released.

I do, however, believe that this practice of patchigation is a dangerous practice. By burying a packaged mitigation within the monthly patches, Microsoft leaves customers who have already been compromised with a false sense of security that there is no problem. As I've said many times in the past, I'm a big fan of Microsoft's Security Program in general. As a Security Researcher however, my appreciation has to take a back seat to exposing risks as I find them. This one is risky, I found it, and I exposed it.

Microsoft has also stated that no previous patch has ever undone an attack. This is not the first time I've heard the argument that patches are not aimed at undoing an attack, and I feel the need to be clear - I do not expect a Microsoft patch to undo an attack, I expect a Microsoft patch to effectively prevent future attacks. This patchigation does not do that.

If a wpad entry exists, the mitigation is not applied. Since the patch and mitigation are one and the same, that means that the issue is not actually remediated. It's not a matter of undoing the single attack that's taken place already, it's an issue of not preventing future attacks. This same issue holds true for organizations with valid wpad entries, the mitigation isn't applied (as Microsoft has indicated, there's no way of knowing if an entry is valid or not) and therefore future attacks can occur. So this isn't about undoing a single attack, this is about preventing future attacks. I suspect customers' expectations are the same as mine: once I'm patched, I'm immune to future attacks.

So I put the question to you: Is patchigation good enough? Whether you think it is or think it isn't, how much do you want to know?

Just wanted to let everyone know that I'm off to CanSecWest for the remainder of the week. If you're going to be there and want to talk security, nCircle, VERT or anything really... Feel free to track me down. You can also ping me on twitter (@treguly).