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:kurt.b...@gmail.com] > 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 <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_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/ >
