Attackers Managed to Obtain Microsoft Digital Signing Keys
22 Mar. 2001
Verisign has erroneously provided attackers with digital certificates that would enable them to sign ActiveX and distribute it as if Microsoft Corporation has signed the code.
Although these certificates are not trusted by default, it does enable those yet unknown attackers to distribute malicious code that will be properly signed as if it came from Microsoft.
Microsoft Windows 95
Microsoft Windows 98
Microsoft Windows Me
Microsoft Windows NT 4.0
Microsoft Windows 2000
VeriSign, Inc., recently advised Microsoft that on January 30 and 31, 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.
However, 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 download the VeriSign CRL and use it. Microsoft is developing 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.
Versions of the update are being prepared for all Microsoft platforms released since 1995. However, because of the large number of platforms that must be tested, the patches are not available at this writing. Until the update is available, Microsoft urges customers to take some or all of the following steps to protect themselves should they encounter hostile code signed by one of the certificates.
Visually inspect the certificates cited in all warning dialogues. The two certificates at issue here were issued on 29 and 30 January 2001, respectively. No bona fide Microsoft certificates were issued on these dates.
Install the Outlook Email Security Update to prevent mail-borne programs from being launched, even via signed components, and install the Office Document Open Confirmation Tool to force web pages to request permission before opening Office documents.
Consider temporarily removing the VeriSign Commercial Software Publishers CA certificate from the Trusted Root Store. Knowledge Base article Q293819 provides details on how to do this.
The certificates are not trusted by default. As a result, neither code nor ActiveX controls could be made to run without displaying a warning dialogue. By viewing the certificate in such dialogues, users can easily recognize the certificates.
The certificates are not the bona fide Microsoft code-signing certificates. Content signed by those keys can be distinguished from bona fide Microsoft content.
Even if you have previously said to always trust Microsoft-signed programs, you would still see a warning dialogue at least one time. This is because trust is assigned on a per-certificate basis, not on a per-name basis. That is, you can specify that you trust a particular certificate because the name on it is Microsoft, but there isn't any way to say that you want to trust all certificates that say Microsoft on them.
The upshot is this: even though the two bogus certificates say they are Microsoft certificates, they are not trusted by default. You are guaranteed to see the warning dialogue the first time you encounter a program signed using either of these certificates, and will continue to see it unless you select "Always trust content from Microsoft Corporation" in response to the warning dialogue.
Because this issue has the potential to affect a large number of customers, Microsoft has taken the step of producing a version of the update for all operating systems produced in the past six years. Specifically, Microsoft will release versions of the update for Windows 95, Windows 98, Windows 98 Second Edition, Windows Me, Windows NT 4.0, and Windows 2000, when used in conjunction with Internet Explorer 4.01, 5.01, and 5.5.
Is there anything I can do in the meantime?
Yes. You can do three things today to help protect your systems.
If you see a dialogue asking whether to trust content signed by Microsoft, visually inspect the certificate and verify that it isn't one of the bogus ones.
Ensure that you have installed the Outlook Email Security Update and the Office Document Open Confirmation Tool.
Consider taking steps to temporarily prevent any certificates issued by VeriSign from being trusted