-----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-----