Why does this not surprise me? Kurt
---------- Forwarded message ---------- From: Core Security Technologies Advisories <advisor...@coresecurity.com> Date: Tue, May 4, 2010 at 15:26 Subject: [Full-disclosure] [CORE-2010-0427] Windows SMTP Service DNS query Id vulnerabilities To: full-disclos...@lists.grok.org.uk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Core Security Technologies - CoreLabs Advisory http://corelabs.coresecurity.com/ Windows SMTP Service DNS query Id vulnerabilities 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 implementations in 2007. In 2008 a much publicized advancement of the DNS cache poisoning technique was disclosed by Dan Kaminsky [8] in conjunction with the release of security fixes by several vendors. Microsoft's MS08-037 [http://www.microsoft.com/technet/security/bulletin/ms08-037.mspx]Security Bulletin addressed those DNS spoofing techniques in Windows DNS client and server software. In light of the 16-year saga of discovery and refinement 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 [http://www.microsoft.com/technet/security/bulletin/ms10-024.mspx] published April 13, 2010 Nicolas 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 misrepresent actual threat scenarios. Nicolas 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 [http://web.nvd.nist.gov/view/vuln/detail?vulnId=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 previously 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 [http://www.microsoft.com/technet/security/bulletin/ms10-024.mspx]. 7. *Credits* The bugs disclosed in this advisory were independently discovered and researched by Nicolás Economou [http://corelabs.coresecurity.com/index.php?module=Wiki&action=view&type=researcher&name=Nicolas_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 successfully. 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 port*entropy 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 [http://web.nvd.nist.gov/view/vuln/detail?vulnId=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 Exchange 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 functionality 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. [http://www.openbsd.org/advisories/res_random.txt] [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 at: [http://corelabs.coresecurity.com/]. 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. Based in Boston, MA and Buenos Aires, Argentina, Core Security Technologies can be reached at 617-399-6980 or on the Web at [http://www.coresecurity.com]. 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, which is available for download at [http://www.coresecurity.com/files/attachments/core_security_advisories.asc]. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkvgnyEACgkQyNibggitWa2SyQCfdWpNuMmlU8Ye1eE0uSII5f+G mmwAnj4hejHo/gnLh8qF/EhHBJHvvijS =VxJA -----END PGP SIGNATURE----- _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/