Yeah, that's a headscratcher, isn't it? Kurt
On Tue, May 4, 2010 at 17:11, Richard Stovall <[email protected]> wrote: > Thanks Kurt. I'll make sure we're all patched up. I have to question, > however... > Microsoft Exchange Server 2003 (SP3, SP2 and previous) > SP3? > > On Tue, May 4, 2010 at 7:56 PM, Kurt Buff <[email protected]> wrote: >> >> Why does this not surprise me? >> >> Kurt >> >> >> ---------- Forwarded message ---------- >> From: Core Security Technologies Advisories <[email protected]> >> Date: Tue, May 4, 2010 at 15:26 >> Subject: [Full-disclosure] [CORE-2010-0427] Windows SMTP Service DNS >> query Id vulnerabilities >> To: [email protected] >> >> >> -----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/ >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ >> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
