Alert: Microsoft Security Bulletin - MS02-050
From: Russ (Russ.Cooper@RC.ON.CA)Date: 09/05/02
- Previous message: NGSSoftware Insight Security Research: "New Paper: Threat profiling Microsoft SQL Server"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 4 Sep 2002 23:30:58 -0400 From: Russ <Russ.Cooper@RC.ON.CA> To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
http://www.microsoft.com/technet/security/bulletin/MS02-050.asp
Certificate Validation Flaw Could Enable Identity Spoofing (Q328145)
Originally posted: September 04, 2002
Summary
Who should read this bulletin: Customers using Microsoft® Windows®, Office for Mac, Internet Explorer for Mac, or Outlook Express for Mac.
Impact of vulnerability: Identity spoofing.
Maximum Severity Rating: Critical
Recommendation: Administrators should install the patch immediately.
Affected Software:
- Microsoft Windows 98
- Microsoft Windows 98 Second Edition
- Microsoft Windows Me
- Microsoft Windows NT® 4.0
- Microsoft Windows NT 4.0, Terminal Server Edition
- Microsoft Windows 2000
- Microsoft Windows XP
- Microsoft Office for Mac
- Microsoft Internet Explorer for Mac
- Microsoft Outlook Express for Mac
Technical description:
The IETF Profile of the X.509 certificate standard defines several optional fields that can be included in a digital certificate. One of these is the Basic Constraints field, which indicates the maximum allowable length of the certificate's chain and whether the certificate is a Certificate Authority or an end-entity certificate. However, the APIs within CryptoAPI that construct and validate certificate chains (CertGetCertificateChain(), CertVerifyCertificateChainPolicy()) and WinVerityTrust) do not check the Basic Constraints field. The same flaw, unrelated to CryptoAPI, is also present in several Microsoft products for Macintosh.
The vulnerability could enable an attacker who had a valid end-entity certificate to issue a subordinate certificate that, although bogus, would nevertheless pass validation. Because CryptoAPI is used by a wide range of applications, this could enable a variety of identity spoofing attacks. These are discussed in detail in the FAQ, but could include:
- Setting up a web site that poses as a different web site, and "proving" its identity by establishing an SSL session as the legitimate web site.
- Sending emails signed using a digital certificate that purportedly belongs to a different user.
- Spoofing certificate-based authentication systems to gain entry as a highly privileged user.
- Digitally signing malware using an Authenticode certificate that claims to have been issued to a company users might trust.
Mitigating factors:
Overall:
- The user could always manually check a certificate chain, and might notice in the case of a spoofed chain that there was an unfamiliar intermediate CA.
- Unless the attacker's digital certificate were issued by a CA in the user's trust list, the certificate would generate a warning when validated.
- The attacker could only spoof certificates of the same type as the one he or she possessed. In the case where the attacker attempted an attack using a high-value certificate such as Authenticode certificates, this would necessitate obtaining a legitimate certificate of the same type - which could require the attacker to prove his or her identity or entitlement to the issuing CA.
Web Site Spoofing:
- The vulnerability provides no way for the attacker to cause the user to visit the attacker's web site. The attacker would need to redirect the user to a site under the attacker's control using a method such as DNS poisoning. As discussed in the FAQ, this is extremely difficult to carry out in practice.
- The vulnerability could not be used to extract information from the user's computer. The vulnerability could only be used by an attacker as a means of convincing a user that he or she has reached a trusted site, in the hope of persuading the user to voluntarily provide sensitive data.
Email Signing:
- The "from" address on the spoofed mail would need to match the one specified in the certificate, giving rise to either of two scenarios if a recipient replied to the mail. In the case where the "from" and "reply-to" fields matched, replies would be sent to victim of the attack rather than the attacker. In the case where the fields didn't match, replies would obviously be addressed to someone other than ostensible sender. Either case could be a tip-off that an attack was underway.
Certificate-based Authentication:
- In most cases where certificates are used for user authentication, additional information contained within the certificate is necessary to complete the authentication. The type and format of such data typically varies with every installation, and as a result significant insider information would likely be required for a successful attack.Authenticode Spoofing:
- To the best of Microsoft's knowledge, such an attack could not be carried out using any commercial CA's Authenticode certificates. These certificates contain policy information that causes the Basic Constraints field to be correctly evaluated, and none allow end-entity certificates to act as CAs.
- Even if an attack were successfully carried out using an Authenticode certificate that had been issued by a corporate PKI, it wouldn't be possible to avoid warning messages, as trust in Authenticode is brokered on a per-certificate, not per-name, basis.
Vulnerability identifier: CAN-2002-0862
This email is sent to NTBugtraq automatically as a service to my subscribers. Since its programmatically created, and since its been a long time since anyone paid actual money for my programming skills, it may or may not look that good...;-]
I can only hope that the information it does contain can be read well enough to serve its purpose.
Cheers,
Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor
- Previous message: NGSSoftware Insight Security Research: "New Paper: Threat profiling Microsoft SQL Server"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
