SkipNavigation
US-CERT
American Flag
  Vulnerability
Notes
Database

Search Vulnerability Notes

Vulnerability Notes Help Information


 
 View Notes By
  Name

ID Number

CVE Name

Date Public

Date Published

Date Updated

Severity Metric



 Other Documents
  Technical Alerts

Technical Bulletins

Alerts

Security Tips

 

Vulnerability Note VU#458659

Microsoft Windows domain name resolver service accepts responses from non-queried DNS servers by default

Overview

Systems running Microsoft Windows 98, NT, Windows 2000, or Windows XP DNS resolvers accept DNS replies from any IP address, not just the ones being sent DNS requests. This may lead to domain information spoofing or DNS cache poisoning.

I. Description

Microsoft Windows systems use a caching domain name resolver service running on the computer to handle domain name service (DNS) requests and responses for applications. For example, when a user browses to www.microsoft.com in Internet Explorer, a DNS request is sent to some predetermined nameserver for an answer to the question, "What IP address should I connect to when looking for the machine that goes by the name 'www.microsoft.com'?" The answer returned (typically from the nameserver) is then stored in a cache which can then be reused when future requests for the same name information are made by other applications.


However, the Microsoft Windows domain name resolver service accepts responses from non-queried DNS servers by default. These resolvers will only match the source IP address of incoming response messages with their corresponding outgoing request destination IP addresses when the registry key named QueryIpMatching is set to "1". This essentially automatically fulfills one precondition necessary to trick victim DNS resolver clients into accepting attacker-determined domain name information.

When a remote attacker attempts to poison a victim resolver cache, QueryIpMatching may offer some benefit. Two pieces of information are then needed to perpetrate a domain name spoof attack (or directed service cache poisoning):

  1. The address of the name server the victim expects responses from;
  2. The query id expected in response to an outstanding name request made for an address the attacker is hoping to redirect.

Without QueryIpMatching being set, an attacker "only" needs the outstanding query id. As noted in CA-2001-09, this may not be a difficult precondition to fulfill, depending on the implementation of the resolvers in question.

In the presence of an attacker capable of sniffing local network traffic (garnering queryids, spoofing valid DNS servers), other risks become apparent. Obviously matching IP addresses in this scenario adds little to no security benefit since the target nameserver IP address can be easily known and spoofed in the absence of any cryptographic protection (e.g., IPSEC, DNSSEC).

II. Impact

Attackers able to successfully predict the query id of DNS requests initiated by client systems would be able to corrupt DNS responses and potentially misdirect network traffic and mislead victims. This could result in identity masquerading, loss of confidential information, denial of service, and other impacts typically associated with DNS cache corruption (cache pollution) or domain name information spoofing.

III. Solution

The previously-published solution utilizing the registry key IpQueryMatching does not work for all versions of Windows. Microsoft is currently investigating this issue and expects to provide more complete solution information in the near future.

Use cryptographic protection of either the site DNS or network traffic (i.e., use DNSSEC or IPSEC). Note use of DNSSEC may not be feasible by sites with older resolvers unable to validate DNSSEC-secured domain name information.

Systems Affected

VendorStatusDate Updated
Microsoft CorporationVulnerable22-Jul-2002

References

http://www.kb.cert.org/vuls/id/109475
http://www.cert.org/advisories/CA-1997-22.html
http://www.cert.org/advisories/CA-2001-09.html
ftp://ftp.isi.edu/in-notes/rfc2181.txt
http://www.iss.net/security_center/static/4280.php
http://www.microsoft.com/technet/security/bestprac/bpent/sec3/nameres.asp
http://www.microsoft.com/technet/itsolutions/network/deploy/depovg/tcpip2k.asp
http://www.microsoft.com/technet/prodtechnol/winxppro/reskit/prjj_ipa_vitx.asp
http://www.microsoft.com/technet/prodtechnol/windows2000pro/reskit/part4/proch22.asp
http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/tcpip/part2/tcpch06.asp
http://www.microsoft.com/windows2000/techinfo/reskit/en/ProRK/prcc_tcp_dacz.htm
http://www.microsoft.com/windows2000/techinfo/reskit/samplechapters/cncf/cncf_imp_miqe.asp#cncf_imp_sykl

Credit

The CERT/CC thanks Hank Nussbacher <hank@riverhead.com> of Riverhead Networks for raising awareness on this issue. This issue was previously documented in the ISS X-Force Database as win2k-dns-resolver (4280).

This document was written by Jeffrey S. Havrilla.

Other Information

Date Public04/14/2000
Date First Published07/22/2002 01:02:32 PM
Date Last Updated08/30/2002
CERT Advisory 
CVE Name 
US-CERT Technical Alerts 
Metric10.50
Document Revision48

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

 
Page Corner Image
Copyright 2002 Carnegie Mellon University
Disclaimers and copyright information
Get Adobe Reader Get Adobe Reader