Further on this to my earlier comment - not a good assumption that Exchange/SMTP service "re-invented" anything. You find code re-use throughout Microsoft. Very possible they simply forked code from the OS to use in Exchange/SMTP service, and this is being included as the first patch in this area to Exchange/SMTP service since the DNS changes were released.
Regards, Michael B. Smith Consultant and Exchange MVP http://TheEssentialExchange.com -----Original Message----- From: Carol Fee [mailto:[email protected]] Sent: Thursday, May 06, 2010 10:13 AM To: MS-Exchange Admin Issues Subject: RE: FYI - MSFT doesn't tell all it knows If the SMTP doesn't use the operating system resolver, where does it find the DNS servers that it uses ? 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 CFee -----Original Message----- From: Jason Gurtz [mailto:[email protected]] Sent: Wednesday, May 05, 2010 4:36 PM To: MS-Exchange Admin Issues Subject: RE: FYI - MSFT doesn't tell all it knows Very Interesting... (and not surprised here either) I guess they need to read Joels article I linked yesterday too ;) Well, I guess if there are ever host resolution issues on Exchange I'll know that I'd be wasting my time by doing ipconfig /flushdns Re-inventing the wheel: always a fun time down the road! ~JasonG > -----Original Message----- > From: Kurt Buff [mailto:[email protected]] > Sent: Tuesday, May 04, 2010 19:57 > To: MS-Exchange Admin Issues > Subject: FYI - MSFT doesn't tell all it knows > > 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_p > apers/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.a > sc]. > > -----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/ >
