[zz]Microsoft Security Bulletin MS01-017 Erroneous VeriSign-Issued Digital Certificates Pose Spoofing Hazard

http://www.microsoft.com/technet/security/bulletin/MS01-017.mspx

 

In mid-March 2001, VeriSign, Inc., advised Microsoft that on January 29 and 30, 2001, it issued two VeriSign Class 3 code-signing digital certificates to an individual who fraudulently claimed to be a Microsoft employee. The common name assigned to both certificates is "Microsoft Corporation". The ability to sign executable content using keys that purport to belong to Microsoft would clearly be advantageous to an attacker who wished to convince users to allow the content to run.

The certificates could be used to sign programs, ActiveX controls, Office macros, and other executable content. Of these, signed ActiveX controls and Office macros would pose the greatest risk, because the attack scenarios involving them would be the most straightforward. Both ActiveX controls and Word documents can be delivered via either web pages or HTML mails. ActiveX controls can be automatically invoked via script, and Word documents can be automatically opened via script unless the user has applied the Office Document Open Confirmation Tool.

Even though the certificates say they are owned by Microsoft, they are not bona fide Microsoft certificates, and content signed by them would not be trusted by default. Trust is defined on a certificate-by-certificate basis, rather than on the basis of the common name. As a result, a warning dialogue would be displayed before any of the signed content could be executed, even if the user had previously agreed to trust other certificates with the common name "Microsoft Corporation". The danger, of course, is that even a security-conscious user might agree to let the content execute, and might agree to always trust the bogus certificates.

VeriSign has revoked the certificates, and they are listed in VeriSign's current Certificate Revocation List (CRL). However, because VeriSign's code-signing certificates do not specify a CRL Distribution Point (CDP), it is not possible for any browser's CRL-checking mechanism to locate and use the VeriSign CRL. Microsoft has developed an update that rectifies this problem. The update package includes a CRL containing the two certificates, and an installable revocation handler that consults the CRL on the local machine, rather than attempting to use the CDP mechanism. 

 

What's the scope of the problem?
VeriSign, Inc., a major certificate authority, has informed Microsoft that in January 2001 it erroneously issued two digital certificates to an individual who fraudulently claimed to be a Microsoft employee. These certificates could be used to digitally sign programs (including ActiveX controls and Word macros) using the name "Microsoft Corporation".
Programs signed using these certificates would not be able to run automatically or bypass any normal security restrictions. However, the warning dialogue that appears before such programs could run would claim that they had been digitally signed by Microsoft. Clearly, this would be a significant aid in persuading a user to run the program.

What is a digital certificate?
To answer that question, we first need to discuss cryptography, particularly public key cryptography. Cryptography is the science of securing information by converting it between its normal, readable state (called plaintext) and one in which the data is obscured (known as ciphertext).
In all forms of cryptography, a value known as a key is used in conjunction with a procedure called a cryptoalgorithm to transform plaintext data into ciphertext. In the most familiar type of cryptography, secret-key cryptography, the ciphertext is transformed back into plaintext using the same key. However, in a second type of cryptography, public key cryptography, a different key is used to transform the ciphertext back into plaintext.
In public key cryptography, one of the keys, known as the private key, must be kept secret. The other key, known as the public key, is intended to be shared with the world. However, there must be a way for the owner of the key to tell the world who the key belongs to. Digital certificates provide a way to do this. A digital certificate is a tamperproof piece of data that packages a public key together with information about it - who owns it, what it can be used for, when it expires, and so forth.

What can a digital certificate be used for?
A digital certificate (or more properly, a key pair, of which the public key is packaged in a digital certificate) can be used in either of two ways. If people use the public key (the one encapsulated in a digital certificate) to encrypt data, only the person who holds the corresponding private key will be able to read it; this enables the data to be kept confidential.
On the other hand, if the owner of the private key uses it to encrypt data, anyone will be able to decrypt it using the corresponding public key. This process doesn't provide confidentiality (since anyone can access the public key and decrypt the message), but it does provide two other capabilities:

•	Proof of origin. If the data could be decrypted using the public key, it must have been encrypted using the corresponding private key - and the digital certificate says who owns the private key.
•	Authenticity. If someone modified the encrypted data while it was in transit, the recipient wouldn't be able to decrypt it, even using the public key. The fact that the data can be successfully decrypted shows that it wasn't tampered with.

Using public-key cryptography in this manner to prove the origin and authenticity of data is known as digital signing.

But what ensures that the private key really belongs to the person listed in the digital certificate?
Digital certificates are generated and digitally signed by organizations known as certificate authorities. It's the job of a certificate authority to verify the identity of the person requesting a digital certificate before issuing one to them.

What's wrong with the certificates in this case?
A certificate authority, VeriSign, erroneously issued two digital certificates to a person who claimed to be a Microsoft employee. The certificates say that the owner of the certificate is Microsoft, when in fact this is not the case.

What could these two certificates be used to do?
These certificates are of a type that can be used to digitally sign programs, including ActiveX controls and Office macros. Many software developers, including Microsoft, digitally sign the programs they create in order to assure customers that the programs are legitimate and have not been modified.

Could the certificates be used for any other purpose?
No. All digital certificates carry a marking that restricts what they can be used for. These particular certificates can only be used to digitally sign programs. They cannot be used to encrypt data, sign e-mails, log onto Windows 2000 systems, or do anything else besides signing programs.

How might an attacker use these certificates?
The attacker's overall goal would very probably be to convince other users to run an unsafe program, by using the digital signature to convince them that it is actually bona fide Microsoft software and therefore safe to run. There are a variety of scenarios the attacker might use to accomplish this, but if the attacker's goal was distribute malicious code widely, a few scenarios would likely be especially attractive.
The attacker probably would choose to use an attack scenario designed to deliver the program to a large number of users, such as hosting the signed program on a web site or sending an HTML e-mail that would retrieve it from a web site. It's also likely that he would choose to package the program as either an ActiveX control or an Office document containing a signed macro, because doing so would allow him to initiate running the program automatically, as soon as a user either visited the web page or opened the HTML mail.

Did you say that the attacker could make the signed program run automatically?
No. There's a fine distinction between initiating the running of a program and actually running it, and it's worth spending a few moments discussing the difference.
From the attacker's perspective, the problem with simply sending a signed program as an attachment to a mail, or hosting it as a file on a web site, is that he would need to persuade the user to select the program and deliberately choose to run it. This isn't impossible to accomplish - witness the success of the I Love You virus, for instance, which did exactly this - but the attacker would want a method that minimizes the number of steps the user must take to run the program.
Web pages and HTML e-mails can automatically initiate ActiveX controls, and can automatically open Word documents (unless the user has previously installed the Office Document Open Confirmation Tool). However, in either case a warning dialogue similar to the one below would be displayed before the program actually began running. The dialogue would ask the user whether it's OK for the program to run. The danger, of course, is that the dialogue would say that the program was digitally signed by Microsoft, and even a security-conscious user might agree to let it run.

What does the update do?
The update does the following:

•	Installs a CRL onto the local machine. The CRL lists the two bogus certificates as having been revoked.
•	Adds new functionality via a piece of software called an installable revocation handler that causes the system to check the CRL on the machine if the CDP data is missing or invalid.
•	Turns on CRL checking in IE for software publisher's certificates.