VeriSign, Inc., recently 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 by using keys that purport to belong to Microsoft would clearly be advantageous to a malicious user who wanted to convince users to allow the content to run.

The certificates could be used to sign programs, ActiveX controls, Microsoft 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 Microsoft Word documents can be delivered by either Web pages or HTML e-mail messages. ActiveX controls can be automatically invoked by a script, and Word documents can be automatically opened by a script unless you have applied the Microsoft Office Document Open Confirmation tool.

Although the certificates state that they are owned by Microsoft, they are not real Microsoft certificates, and content that is 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. Therefore, a warning message would be displayed before any of the signed content could be run, even if you had previously agreed to trust other certificates with the common name "Microsoft Corporation." The danger is that even a security-conscious user might agree to let the content run, and might agree to always trust the fraudulent certificates.

VeriSign has revoked the certificates, and they are listed in the VeriSign current Certificate Revocation list (CRL). However, because the VeriSign code-signing certificates do not specify a CRL Distribution Point (CDP), it is not possible for any browser's CRL-checking mechanism to download the VeriSign CRL and use it. 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 computer, rather than attempting to use the CDP mechanism.

For additional information on this update, click the article number below to view the article in the Microsoft Knowledge Base:

Back to the top

Mitigating Factors

•	The certificates are not trusted by default. Therefore, neither code nor ActiveX controls could be made to run without displaying a warning message. By viewing the certificate in such messages, you can easily recognize the certificates.
•	The certificates are not the real Microsoft code-signing certificates. Content that is signed by those keys can be distinguished from real Microsoft content.

For additional information about how to revoke the the trusted status for these certificates, click the article number below to view the article in the Microsoft Knowledge Base: For additional information, see the following Microsoft Web site: Windows NT Server 4.0, Terminal Server Edition users can obtain the Windows NT Server 4.0 Terminal Server Edition, Security Rollup Package (SRP). For additional information about the SRP, click the article number below to view the article in the Microsoft Knowledge Base:

Back to the top