search menu icon-carat-right cmu-wordmark

CERT Coordination Center


Microsoft Windows NT and 2000 Domain Name Servers allow non-authoritative RRs to be cached by default

Vulnerability Note VU#109475

Original Release Date: 2001-08-09 | Last Revised: 2002-08-06

Overview

Microsoft Domain Name Servers hosted on Windows NT or Windows 2000 Server systems run with permissive DNS cache defaults. This may allow unauthorized remote intruders to redirect sites that rely on the vulnerable DNS servers for legitimate information.

Description

The Domain Name System, (partially specified in RFC 1034, Domain Names - Concepts and Facilities,) is the network infrastructure which maps Internet addresses to human-readable labels (names), and vice-versa. Several implementations of the servers responsible for managing this mapping information have had a specific security vulnerability called "cache poisoning" which may lead to corruption of the DNS information (resource records, or RRs) being managed (see CA-1999-22 for more details).

Cache poisoning occurs when malicious or misleading data received from a remote name server is saved (cached) by a gullible name server. This bad data is then made available to programs running on workstations that request the cached data through the client interface (resolver). (Sample programs needing such DNS information include web browsers and email servers). This can adversely affect the mapping between host names and IP addresses, among other things. Once this mapping has been changed, hosts looking for legitimate DNS responses from a corrupted server can be redirected to arbitrary sites.

The default configuration vulnerability discussed here occurs when cache pollution protection is disabled as a default option in Windows NT and Windows 2000 servers. Windows Server systems installed with DNS ship with the "Secure cache against pollution" option disabled, allowing DNS cache poisoning to occur either by accident or design. This option represents the value of a specific registry key. If the value SecureResponses is not set to "1" in this key, then cache poisoning can occur. When in this state, the vulnerable DNS server will cache any records in a response received from a remote DNS server, even if those records are outside the namespace delegated to the remote DNS server.

It is important to note that this cache poisoning can occur without an attacker needing to predict DNS query ids (as assumed in CVE-1999-0024). Maliciously-registered glue records distributed by global top-level domain servers (gTLDs) may be utilized when attacking specific sites vulnerable to this weak configuration option.

Impact

Once the cache poisoning occurs, hosts looking for legitimate DNS responses from a corrupted server can be redirected to arbitrary sites. Alternatively, the information returned can be garbage, leading to possible denial of DNS service.

Solution


On affected Windows NT or 2000 systems, locate the following key in the registry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters

On the Edit menu, click Add Value, and then add the following registry value:

     Value Name: SecureResponses
     Data Type: REG_DWORD
     Value: 1

On Windows 2000 Server systems, there is a GUI option "Secure cache against pollution" in the DNS Management Console which can set the registry key value automatically. Please see the Knowledge Base article Q241352 for step-by-step instructions.

(Note that even given the stronger configuration, other forms of attack involving DNS cache poisoning are possible. This class of problem likely cannot be completely resolved until there is widely-deployed cryptographicly-secure authentication available for DNS. See the IETF dnsext Working Group for more information on this topic.)

See Q241352 for the complete set of instructions for enabling cache protection for both Windows NT and Windows 2000 Server systems.

Vendor Information

109475
Expand all

Microsoft Corporation

Notified:  July 23, 2001 Updated:  September 14, 2001

Status

  Vulnerable

Vendor Statement

Like [CERT] noted, this issue is addressed by a configuration change in
the registry, as noted at:

http://support.microsoft.com/support/kb/articles/Q241/3/52.ASP

That configuration change addresses the issue that this [note] is
reporting.


Currently, this is configuration setting is set to disabled by
default, based on the performance penalties this introduces.
However, we are making performance improvements and we are planning
to change this default so that this is enabled by default starting
with Service Pack 3 and with Windows .Net Server.

We believe that this is a configuration issue rather than a
vulnerability.  The means to change this behavior is publicly
documented and has been available via the KB article. Because there
is a performance penalty with this change currently, customers have
to make an informed risk assessment of the benefits of enabling this
feature and the drawbacks.  We're working to improve the performance
to a point where we feel comfortable making this enabled by default.
However, this change is a change in configuration settings and not a
change in the product itself.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

Please see additional information at:
http://www.microsoft.com/WINDOWS2000/en/server/help/sag_DNS_pro_SecureCachePollutedNames.htm
http://msdn.microsoft.com/library/en-us/regentry/46753.asp

If you have feedback, comments, or additional information about this vulnerability, please send us email.


CVSS Metrics

Group Score Vector
Base N/A N/A
Temporal N/A N/A
Environmental N/A

References

Credit

The details of this issue have been discussed in several public forums: NANOG INCIDENTS@securityfocus.com SANS intrusions@incidents.org Microsoft has several articles in its knowledgebase as well.

This document was written by Jeffrey S. Havrilla.

Other Information

CVE IDs: None
Severity Metric: 11.55
Date Public: 2001-06-22
Date First Published: 2001-08-09
Date Last Updated: 2002-08-06 21:43 UTC
Document Revision: 62

Sponsored by the Department of Homeland Security Office of Cybersecurity and Communications.