MS09-007 resolves an issue in which an attacker may be able to log onto an SSL protected server which is configured to use certificate based client authentication with only the public key component of a certificate, not the associated private key. Only a subset of customers who log into SSL protected servers are at risk but it is a little tricky to explain who might be affected due to the unique nature of this vulnerability. This blog entry will help you assess the risk to which your application is exposed by explaining those details.
Affected deployments
This vulnerability does not apply to customers who have mapped certificate-authenticated users against an Active Directory domain. It only applies in those situations where certificates are mapped to local Windows accounts on the server. For domain deployments, we still recommend applying the update as a defense in depth measure.
Customers can find more information on the different ways of certificate mapping here: http://technet.microsoft.com/en-us/library/cc736706.aspx
The vulnerability
In a PKI deployment, digital X.509 certificates contain a public key component, which can be distributed to other parties that allows them to encrypt data that only the holder of the corresponding private key can read. When web sites use certificates for client authentication, they generally require the user to encrypt certain data with his private key to prove that he is really the owner of the certificate used to authenticate. This specific vulnerability occurs due to a flaw in the way the server validates that the user is using his private key to authenticate. As such, in some circumstances a user may successfully authenticate by only providing the public key, and not using the corresponding private key.
Determining if your configuration is at risk
On the Windows client platform, certificates are stored in the certificate store under the user’s individual account. Each certificate has an “Intended purpose” assigned. Common Intended purposes include Secure Email, Client Authentication, Encrypting File System, and All Intended Purposes. These describe for what purpose applications on the Windows client can use a specific certificate. A certificate can have multiple purposes. These intended purposes cannot be changed by the user, but are part of the EKU extension of the digital certificate. They are read-only and set by the certificate issuer.
You can review the intended purpose(s) of your certificates by clicking Start, and running “certmgr.msc”, the Microsoft Management Console certificate snap-in. The “Intended Purpose” shows under Personal, then Certificates, as seen in the screenshot below:
Your configuration would not be at significant risk unless an attacker gets access to your user’s public keys. While the public key component of a certificate is a “public key”, it’s important to understand that when a user authenticates against an SSL protected IIS web server, the public key component of the certificate is not transferred in clear text. During the authentication process, it cannot be sniffed off the wire by an attacker on the local subnet. As such, if the certificate is configured with an intended purpose of “Client Authentication” only, it would be more difficult for an attacker to gain access to the certificate and exploit the vulnerability. He would need to gain access to the certificate on the machine, or convince the user to authenticate against his own, malicious web site.
This deployment scenario is most common in those situations where the owner of a web site himself issues certificates to his users, and can limit the uses to a specific purpose. Another potentially impacted scenario is when the owner of a protected SSL web site allows users to use their own generic certificates to authenticate against a server. In this case, the user may also be using the certificate for other purposes (i.e. the certificate may have multiple intended purposes), such as authenticating against wireless networks or signing e-mail. Depending on the purpose, the public key may be distributed in clear text and to untrusted parties. This would make it easier for an attacker to gain access to the victim’s public key which he needs to exploit this vulnerability successfully, and thus increases the risk significantly.
We hope this blog entry helps address some of the questions you may have, and helps you assess the risk this vulnerability poses to your web application and its users.
- Maarten Van Horenbeeck (MSRC Operations), Robert Hensing and Jonathan Ness (MSRC Engineering)
*Postings are provided “AS IS” with no warranties, and confers no rights.*