MS09-008: DNS and WINS Server Security Update in More Detail

Security Research & Defense

/ By swiat / March 13, 2009 / 7 min read

After releasing security update MS09-008, we received a number of questions on the WPAD issue (CVE-2009-0093) addressed in the update. There are claims that this update is ineffective. Let me be clear that this update will protect you and it should be deployed as soon as possible. Below is an overview on how the complete security update helps protect a system.

This security update resolves a number of different vulnerabilities with different attack vectors:

DNS Server Query Validation Vulnerability (CVE-2009-0233)
DNS Server Response Validation Vulnerability (CVE-2009-0234)
DNS Server Vulnerability in WPAD Registration (CVE-2009-0093)
WPAD WINS Server Registration Vulnerability (CVE-2009-0094)

We’ll review these in a bit more depth starting with the validation vulnerabilities and afterwards looking in more depth at the WPAD registration issue that has attracted most questions.

DNS Server Query and Response Validation Vulnerabilities

CVE-2009-0233 and CVE-2009-0234 are two vulnerabilities that allow an attacker to successfully spoof DNS responses by issuing specifically crafted DNS queries.

A DNS transaction ID is a number that uniquely identifies a single DNS transaction. The DNS server uses it to identify if a response to a query is in fact legitimate. When transaction IDs are predictable, an attacker could spoof valid responses to DNS queries made by the server, and as such introduce arbitrary addresses into the DNS cache.

In both vulnerabilities, the server does not cache specific types of DNS responses, allowing an attacker to cause the DNS server to continuously request a specific Resource Record (RR). This makes it easier for an attacker to match the correct transaction ID and source port combination and successfully spoof a response. The security update resolves these two issues by improving the way the DNS server will cache and re-use answers to these specific types of queries.

DNS Server Vulnerability in WPAD Registration

CVE-2009-0093 describes an issue with how the Web Proxy Auto-Discovery, or WPAD, and the Intra-Site Automatic Tunnel Addressing Protocol, or ISATAP, can be abused by an attacker.

This is typically a local domain attack where there is a degree of trust between the domain members. The Windows DNS server can allow clients to register their own hostname in the DNS server using dynamic updates. In the most common scenario, this takes place using secure dynamic updates, where a client authenticated against the domain can update its own name on the DNS server. If the WPAD or ISATAP names have not yet been registered, a domain-authenticated user could register his own machine as either of these two names.

The reason why ISATAP and WPAD are so interesting for an attacker to register, is because they are default names a client will resolve to obtain specific functionality. In the case of WPAD, the name tells the host where to connect for proxy configuration information. In the case of ISATAP, it points to a tunneling server that connects IPv6 hosts over IPv4 networks.

WPAD in particular is common enterprise functionality, and as such Microsoft needs to be very careful when releasing a security update to ensure that we both protect our customers, and do not break the functionality they have come to rely upon.

The security update we released helps protect customers by implementing a block list on the DNS server, containing a list of names which the DNS server will no longer resolve. This list is implemented as the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters\

GlobalQueryBlockList

(3/18/09: Updated registry key)

If the WPAD and ISATAP names are not registered on the DNS server when the security update is installed this block list is populated with both names. When a client issues a query for one of those names the DNS server will return a negative response, even if an attacker registers it.

However, when a DNS server already has an entry for either WPAD or ISATAP before the update is applied, it will not add that name to the block list, and will continue to answer requests for them. As an example, if a DNS server has a resource record configured named WPAD, the security update will add only the name ISATAP to the block list. If a DNS server does not have WPAD nor ISATAP configured, the block list will contain both names.

This is necessary as many of our customers legitimately use this functionality. Implementing a block list that blocks these names in all cases, requiring the administrator to remove them manually would break these configurations.

One concern that was raised by a security researcher is that an attacker may have introduced a malicious WPAD entry through a dynamic DNS update. When you install the security update after such an attack has taken place, the WPAD name will not be added to the block list, and the attack will continue to be effective.

This is indeed not a scenario the security update, or any security update released by Microsoft aims to address. Security updates are intended to help protect the system against future exploitation, and don’t aim to undo any attack that has taken place in the past. The update does not actively change the current configuration. When installing the update, it has no way of knowing whether the WPAD entry was configured by an administrator or an attacker.

Customers who have this specific concern can validate the IP address assigned to the current WPAD/ISATAP entries in their DNS zones using the DNS MMC snap-in:

Open the DNS MMC snap-in from the Administrative tools group
Expand “Forward Lookup Zones”
For each zone, look for Host (A), IPv6 address (AAAA) or Alias (CNAME) records with a name of ‘WPAD’ or ‘ISATAP’:

In addition, KB article 968732 describes in detail how a DNS administrator can manually edit the DNS block list to suit his environment.

WPAD WINS Server Registration Vulnerability

CVE-2009-0094 covers the same attack as the DNS Server Vulnerability in WPAD Registration, but using WINS. A WPAD-configured client can look up a host by resolving the name WPAD in WINS as opposed to DNS. This security update will install a WINS block list which is, as with DNS, pre-populated with the WPAD, “WPAD.” and ISATAP names, unless that name is present in the current WINS database. The WINS block list is implemented as the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WINS\
Parameters\QueryBlockList

Customers can validate whether a WPAD name is currently registered in their WINS database using the WINS MMC snap-in:

Open the WINS MMC snap-in from the Administrative tools group
Right click on “Active Registrations” and choose “Display records”
On the “Record Mapping” tab check the “Filter records matching this name pattern” and type “wpad”

Any active WPAD name registrations should show in the “Active Registrations” window as shown below:

KB article 968731 describes in detail how a WINS administrator can edit the WINS block list. Note that the WINS block list is independent from the DNS block list, and in both cases block lists do not replicate across multiple servers.

Beyond the two issues we’ve address regarding the WPAD protocol with this update, there may be other ways clients could get redirected to WPAD servers unintentionally. We’re continuing to investigate these. In fact, guidance around this can be found here http://www.microsoft.com/technet/security/advisory/945713.mspx.

We hope this blog entry clarifies the content of the security update and answers any questions you may have. This security update addresses a number of vulnerabilities and we recommend installing it at your earliest convenience.

-Maarten Van Horenbeeck, MSRC Program Manager

We’d like to thank the following contributors to this blog: