Windows SMTP Service DNS query Id vulnerabilities

Advisory ID Internal
CORE-2010-0427

1. Advisory Information

Title: Windows SMTP Service DNS query Id vulnerabilities
Advisory Id: CORE-2010-0427
Advisory URL: http://www.coresecurity.com/content/CORE-2010-0424-windows-smtp-dns-query-id-bugs
Date published: 2010-05-04
Date of last update: 2010-05-04
Vendors contacted: Microsoft
Release mode: User release

2. Vulnerability Information

Class: Predictable from Observable State [CWE-341], Insufficient Verification of Data Authenticity [CWE-345]
Impact: Security bypass
Remotely Exploitable: Yes
Locally Exploitable: No
CVE Name: CVE-2010-1689, CVE-2010-1690
Bugtraq ID: 39908, 39910

3. Vulnerability Description

DNS spoofing and cache poisoning attacks have been known security threats that result from design weaknesses of the DNS protocol since the early 1990s as described by Christopher Schuba [1] and Paul Vixie [2]. In 1997 a practical implementation of a blind remote DNS cache poisoning attack that relies solely on exploiting the predictability of the ID field of DNS query packets was described by Arce and Kargieman [3]. This was followed up by further refinements and advancement of attack techniques by Vagner Sacramento [4] and Joe Stewart [5] in 2002. Amit Klein further investigated query Id predictability in BIND version 9[6] and Windows DNS[7] server implementions in 2007. In 2008 a much publicized advancement of the DNS cache poisoning technique was disclosed by Dan Kamisnky [8] in conjuntion with the release of security fixes by several vendors. Microsoft's MS08-037Security Bulletin addressed those DNS spoofing techniques in Windows DNS client and server software.

In light of the 16-year saga of discovery and refinenment of DNS poisoning attacks and protection techniques in January 2009 the Internet Engineering Task Force published RFC5452 with guidelines to make DNS more resilient against forged answer attacks.[9]

While researching the fixes issued by Microsoft in Microsoft's Security Bulletin MS10-024 published April 13, 2010 Nicolás Economou discovered two vulnerabilities in Windows SMTP Service and Microsoft Exchange . These vulnerabilities were fixed by the patches referenced in MS10-024 but were not disclosed in the vendor's security bulletin and did not have an unique vulnerability identifier assigned to them. As a result, the guidance and the assessment of risk derived from reading the vendor's security bulletin may overlook or missrepresent actual threat scenarios.
Nicolás found that the Windows SMTP Service does its own DNS resolution of MX records rather that use the DNS resolver from the operating system while investigating CVE-2010-0024. Furthermore, he found that the patch referenced in MS10-024 fixed two severe bugs that were not disclosed as such in the bulletin and had no CVE identifiers assigned to them. Basic analysis of the vulnerabilities disclosed in this advisory indicates that the threat of DNS spoofing attacks against Windows SMTP service and Microsoft Exchange or of exploitation of CVE-2010-0024 was underestimated in MS10-024.
An attacker may leverage the two previouly undisclosed vulnerabilities fixed by MS10-014 to spoof responses to any DNS query sent by the Windows SMTP service trivially. DNS response spoofing and cache poisoning attacks are well known to have a variety of security implications with impact beyond just Denial of Service and Information Disclosure as originally stated in MS10-024.
As a result the importance of deploying MS10-024 patches may be miss-represented in the vendor's security bulletin. Organizations using vulnerable packages should consider re-assessing patch deployment priorities in view of the additional information provided in this advisory.

3.1. Predictable DNS query ID

[CVE-2010-1689 | 39908] Prior to MS10-024 the Windows SMTP Service generated DNS queries with trivially guessable values in the transaction ID field. The issue was addressed in MS10-024 by adding a call to the CAsyncDns::GenerateRandWord method when building the DNS query.

3.2. Missing validation of DNS responses

[CVE-2010-1690 | 39910] Prior to MS10-024 the Windows SMTP Service did not check that the value of the ID field of a DNS response received from the network actually matched the value of the ID field of a corresponding DNS query packet previously sent. The issue was addressed in MS10-024 by adding validation logic to the CAsyncDns::ProcessReadIO method.

4. Vulnerable packages

  • Microsoft Windows 2000 (SP4 and previous)
  • Microsoft Windows XP (SP3, SP2 and previous)
  • Microsoft Windows 2003 (SP2 and previous)
  • Microsoft Windows 2008 (SP2 and previous)
  • Microsoft Windows 2008 R2
  • Microsoft Exchange Server 2003 (SP3, SP2 and previous)
  • Microsoft Exchange Server 2007 (SP2, SP1 and previous)
  • Microsoft Exchange Server 2010

 

5. Non-vulnerable packages

  • Microsoft Windows 2000 (SP4 and previous) with MS10-024
  • Microsoft Windows XP (SP3, SP2 and previous) with MS10-024
  • Microsoft Windows 2003 (SP2 and previous) with MS10-024
  • Microsoft Windows 2008 (SP2 and previous) with MS10-024
  • Microsoft Windows 2008 R2 with MS10-024
  • Microsoft Exchange Server 2003 (SP3, SP2 and previous) with MS10-024
  • Microsoft Exchange Server 2007 (SP2, SP1 and previous) with MS10-024
  • Microsoft Exchange Server 2010 with MS10-024

 

6. Vendor Information, Solutions and Workarounds

These vulnerabilities are fixed with the security updates included in Microsoft Security Bulletin MS10-024.

7. Credits

The bugs disclosed in this advisory were independently discovered and researched by Nicolás Economou. The identity of the original discoverer is unknown.

8. Technical Description / Proof of Concept Code

The vulnerabilities were found and researched on a Windows XP SP3 system by identifying binary differences in smtpsvc.dll after applying the corresponding patch from MS10-024. The dll versions 6.0.2600.5512 and 6.0.2600.5949 were compared.

The following code excerpt identifies the Predictable DNS query ID vulnerability[CVE-2010-1689 | 39908]. Without the MS10-024 patch smtpsvc.dll v6.0.2600.5512 looks like:

4FB5530C 4FB5530C loc_4FB5530C: 4FB5530C mov [esi+3Ch], eax 4FB5530F mov eax, [ebp+arg_8] 4FB55312 mov ecx, ushort gwTransactionId 4FB55318 inc word ptr ushort gwTransactionId 4FB5531F shr eax, 2 4FB55322 not eax 4FB55324 and eax, 1 4FB55327 push eax 4FB55328 push ecx 4FB55329 push [ebp+arg_4] 4FB5532C lea eax, [ebp+hostshort] 4FB5532F push [ebp+lpMultiByteStr] 4FB55332 push eax 4FB55333 push dword ptr [esi+3Ch] 4FB55336 call DnsWriteQuestionToBuffer_UTF8(x,x,x,x,x,x) 4FB5533B test eax, eax 4FB5533D jnz short loc_4FB5537E

As seen at address 4FB55318 the value used to populate the query ID field of outgoing DNS queries is simply incremented by one for each new query to be sent. After applying the patch CAsyncDns::Dns_QueryLib was modified as follows:

4FB5564F 4FB5564F loc_4FB5564F: 4FB5564F mov ecx, esi 4FB55651 mov [esi+3Ch], eax 4FB55654 call CAsyncDns::GenerateRandWord(void) 4FB55659 mov ecx, [ebp+arg_8] 4FB5565C shr ecx, 2 4FB5565F not ecx 4FB55661 and ecx, 1 4FB55664 push ecx 4FB55665 push eax 4FB55666 push [ebp+arg_4] 4FB55669 mov [esi+590h], ax 4FB55670 push [ebp+lpMultiByteStr] 4FB55673 lea eax, [ebp+hostshort] 4FB55676 push eax 4FB55677 push dword ptr [esi+3Ch] 4FB5567A call DnsWriteQuestionToBuffer_UTF8(x,x,x,x,x,x) 4FB5567F test eax, eax 4FB55681 jnz short loc_4FB556C2

The patch adds a call to method CAsyncDns::GenerateRandWord at address 4FB55654. The quality of the pseudo-random number generator used by CAsyncDns::GenerateRandWord was not investigated but simple observation of packets on the wire confirms that DNS query IDs are no longer generated using increments of one decimal unit.

In the case of the Missing validation of DNS responses vulnerability[CVE-2010-1690 | 39910] the following code excerpt shows the validation code added to CAsyncDns::ProcessReadIO by the patch from MS10-024.

4FB5517F 4FB5517F loc_4FB5517F: 4FB5517F mov ecx, [esi+34h] <-- Transaction ID received from the network 4FB55182 mov dx, [esi+590h] <-- Transaction ID set at "4FB55669: mov [esi+590h], ax" 4FB55189 cmp dx, [ecx] 4FB5518C jz loc_4FB5

Since CAsyncDns::ProcessReadIO is called prior to CAsyncDns::DnsParseMessage the patch effectively added a verification to the ID value in a DNS responses that was missing before. This implies that even if it was trivial to blindly guess the query IDs generated by the Windows SMTP service with no or just a few captured DNS queries an attacker did not even need to guess valid query ids to be able to spoof legitimate replies sucessfully.
Prior to MS10-024 the complexity of spoofing responses to Windows SMTP Service or Microsoft Exchange Server was reduced to just guessing the source port that originated the query. This lack of validation of inbound responses was confirmed in practice with a proof of concept exploit for the SMTP Server MX Record vulnerability disclosed in MS10-024.
MS10-024 also included "defense-in-depth changes" to Microsoft Exchange 2007 and Microsoft Exchange 2010 that added source portentropy to DNS transactions initiated by the SMTP service as stated in the FAQ in the general information section of the security bulletin. However, those "defense-in-depth changes" refer to randomization of the source port for outbound DNS queries and not to the value of the query ID used in DNS packets.
The FAQ section corresponding to the SMTP Server MX record vulnerability (CVE-2010-0024) in MS10-024 provides the following question and answer:

How could an attacker exploit the vulnerability? An attacker could try to exploit the vulnerability by creating a malicious DNS server that returns a specially crafted response to an MX resource record query.

Basic analysis of the vulnerabilities disclosed in this advisory that were fixed but not disclosed in MS10-024 indicates that the threat of DNS spoofing attacks against Windows SMTP service and Microsoft Exchange or scenario for exploitation of CVE-2010-0024 was underestimated. As a result the importance of deploying the MS10-024 patches may be miss-represented in the vendor's security bulletin. Organizations using vulnerable packages should consider re-assessing patch deployment priorities in view of the additional information provided in this advisory.

9. Report Timeline

  • 2010-04-20: Nicolás Economou notifies Core's Security Advisories Team of findings.
  • 2010-04-20: Core Advisories Team requests confirmation that transaction ids of DNS responses are not being validated.
  • 2010-04-21: Nicolás Economou confirms [CVE-2010-1689 | 39908]
  • 2010-04-28: Initial notification to the vendor. Publication date set to April 30 2010.
  • 2010-04-29: Vendor confirms that additional updates were included in MS10-024 and quotes a paragraph from MS10-024 that describes a defense-in-depth change for Microsoft Exchange 2007 and Microsoft Exchagne 2010 that adds additional source port entropy to DNS transactions initiated by the SMTP service. Indicates that since these were "defense-in-depth" changes no specific CVEs were assigned and that releasing separate updates for these issues is currently not being considered as they were already bundled in MS10-024. The undisclosed changes apply to all versions of Microsoft Exchange. Microsoft requests a copy of Core's advisory prior to its release to prepare for any follow up questions.
  • 2010-04-29: Core response: The FAQ from the general information section of MS10-024 quoted by Microsoft refers to source port entropy not to the value of the transaction id field used in outbound DNS queries. Core does not consider the two bugs reported to be "security-in-depth" fixes and points out that there is an amount of literature to support that opinion starting with Core's first published security advisory on DNS query Id prediction [3] and ending with Dan Kaminsky's over-publicized DNS poisoning technique which in 2008 Microsoft considered bonafide bugs that required public disclosure using their own CVEs as disclosed in MS08-037. Core found no reasonable way to justify the fix to [CVE-2010-1690 | 39910] as a "defense-in-depth change". Checking that the id of a reply actually matches the id sent in the corresponding query is basic fucntionality required of any DNS resolver. It is also a MUST requirement of section 9.1 of RFC5452. Core indicates that it will consult with Mitre to figure out if one, two or zero new CVE identifiers should be used in reporting these bugs since CVE-2008-1447 may or may not be applicable for the first bug described in the advisory. As soon as the final draft of the advisory is ready for publication Core will send it to Microsoft as requested and ask for comments or any official statement to be added to its Vendor Information section.
  • 2010-05-03: Final draft of CORE-2010-0427 sent to Microsoft.
  • 2010-05-04: CORE-2010-0427 is published.

 

10. References

[1] Schuba, Christoph, "Addressing Weaknesses in the Domain Name System Protocol", 1993.
http://ftp.cerias.purdue.edu/pub/papers/christoph-schuba/schuba-DNS-msthesis.pdf
[2] Vixie, Paul, "5th USENIX UNIX Security Symposium", 1995.
http://www.usenix.org/publications/library/proceedings/security95/full_papers/vixie.txt
[3] Arce, Ivan, Kargieman, Emiliano, "BIND vulnerbailities and solutions", 1997.
[4] Sacramento, Vagner, "Vulnerability in the sending requests control of Bind versions 4 and 8 allows DNS spoofing", 2002.
http://www.rnp.br/cais/alertas/2002/cais-ALR-19112002a.html
[5] Stewart, Joe, "DNS Cache Poisoning - The Next Generation", 2002.
http://www.secureworks.com/research/articles/dns-cache-poisoning
[6] Klein, Amit, "BIND 9 DNS cache poisoning", 2007.
http://www.trusteer.com/files/BIND_9_DNS_Cache_Poisoning.pdf
[7] Klein, Amit, "Windows DNS Server cache poisoning", 2007.
http://www.trusteer.com/files/Windows_DNS_Cache_Poisoning.pdf
[8] Kaminsky, Dan, "Black Ops 2008: It’s The End Of The Cache As We Know It ", 2008.
http://www.blackhat.com/presentations/bh-jp-08/bh-jp-08-Kaminsky/BlackHat-Japan-08-Kaminsky-DNS08-BlackOps.pdf
[9] Hubert, A., van Mook, R., "Measures for Making DNS More Resilient against Forged Answers", RFC-5452, 2009.
http://tools.ietf.org/html/rfc5452

11. About CoreLabs

CoreLabs, the research center of Core Security Technologies, is charged with anticipating the future needs and requirements for information security technologies. We conduct our research in several important areas of computer security including system vulnerabilities, cyber attack planning and simulation, source code auditing, and cryptography. Our results include problem formalization, identification of vulnerabilities, novel solutions and prototypes for new technologies. CoreLabs regularly publishes security advisories, technical papers, project information and shared software tools for public use.

12. About Core Security Technologies

Core Security Technologies develops strategic solutions that help security-conscious organizations worldwide develop and maintain a proactive process for securing their networks. The company's flagship product, CORE IMPACT, is the most comprehensive product for performing enterprise security assurance testing. CORE IMPACT evaluates network, endpoint and end-user vulnerabilities and identifies what resources are exposed. It enables organizations to determine if current security investments are detecting and preventing attacks. Core Security Technologies augments its leading technology solution with world-class security consulting services, including penetration testing and software security auditing. 

13. Disclaimer

The contents of this advisory are copyright (c) 2010 Core Security Technologies and (c) 2010 CoreLabs, and may be distributed freely provided that no fee is charged for this distribution and proper credit is given.

14. PGP/GPG Keys

This advisory has been signed with the GPG key of Core Security Technologies advisories team.