-----BEGIN PGP SIGNED MESSAGE----- __________________________________________________________ The U.S. Department of Energy Computer Incident Advisory Center ___ __ __ _ ___ / | /_\ / \___ __|__ / \ \___ __________________________________________________________ INFORMATION BULLETIN Erroneous Verisign-Issued Digital Certificates for Microsoft March 22, 2001 20:00 GMT Number L-062 ______________________________________________________________________ ________ PROBLEM: Verisign erroneously issued two VeriSign Class 3 code-signing digital certificates to an individual fraudulently claiming to be a Microsoft employee. Both certificates use the name "Microsoft Corporation". PLATFORM: Microsoft Windows® 95 Microsoft Windows 98 Microsoft Windows Me Microsoft Windows NT® 4.0 Microsoft Windows 2000 DAMAGE: Damage varys. Indirectly, if a sys admin or user believes executable code to be from Microsoft, he/she will probably trust it. Meanwhile, the attacker could provide "Microsoft Corporation" signed executables that are really trojans or other malicious code. SOLUTION: Apply the workarounds provided below. ______________________________________________________________________ ________ VULNERABILITY MEDIUM. Much of this threat/vulnerability can be mitigated by ASSESSMENT: verifying the Microsoft certificates, and checking the Verisign revoked list before trusting Microsoft code, as described in this bulletin. ______________________________________________________________________ ________ [****** Start Microsoft Advisory Here ******] - - - ---------------------------------------------------------------------- Title: Erroneous VeriSign-Issued Digital Certificates Pose Spoofing Hazard Date: 22 March 2001 Software: All Microsoft customers should read the bulletin. Impact: Attacker could digitally sign code using the name "Microsoft Corporation". Bulletin: MS01-017 Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-017.asp. - - - ---------------------------------------------------------------------- Issue: ====== 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, we urge 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. The FAQ and Knowledge Base article Q293817 provide complete details regarding both certificates. - Install the Outlook Email Security Update (http://www.officeupdate.com/2000/downloadDetails/Out2ksec.htm) to prevent mail-borne programs from being launched, even via signed components, and install the Office Document Open Confirmation Tool (http://officeupdate.microsoft.com/downloadDetails/confirm.htm) 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. Mitigating Factors: ==================== - 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. Patch Availability: =================== - A software update is under development and will be released shortly. When it is available, we will update this bulletin to provide information on how to obtain and use it. - - - --------------------------------------------------------------------- THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY. [****** End Microsoft Advisory Here ******] ______________________________________________________________________ _________ CIAC wishes to acknowledge the contributions of Microsoft for the information contained in this bulletin. ______________________________________________________________________ _________ CIAC, the Computer Incident Advisory Capability, is the computer security incident response team for the U.S. Department of Energy (DOE) and the emergency backup response team for the National Institutes of Health (NIH). CIAC is located at the Lawrence Livermore National Laboratory in Livermore, California. CIAC is also a founding member of FIRST, the Forum of Incident Response and Security Teams, a global organization established to foster cooperation and coordination among computer security teams worldwide. CIAC services are available to DOE, DOE contractors, and the NIH. CIAC can be contacted at: Voice: +1 925-422-8193 (7x24) FAX: +1 925-423-8002 STU-III: +1 925-423-2604 E-mail: ciac@ciac.org Previous CIAC notices, anti-virus software, and other information are available from the CIAC Computer Security Archive. World Wide Web: http://www.ciac.org/ (or http://ciac.llnl.gov -- they're the same machine) Anonymous FTP: ftp.ciac.org (or ciac.llnl.gov -- they're the same machine) PLEASE NOTE: Many users outside of the DOE, ESnet, and NIH computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Your agency's team will coordinate with CIAC. The Forum of Incident Response and Security Teams (FIRST) is a world-wide organization. A list of FIRST member organizations and their constituencies can be obtained via WWW at http://www.first.org/. This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or the University of California, and shall not be used for advertising or product endorsement purposes. LAST 10 CIAC BULLETINS ISSUED (Previous bulletins available from CIAC) L-052: Cisco IOS Software SNMP Read-Write ILMI Community String L-053: Cisco IOS Software TCP Initial Sequence Number Improvements L-054: Microsoft IIS and Exchange Malformed URL Denial of Service L-055: pcAnywhere Denial of Service, abnormal server connection L-056: The Naked Wife (W32.Naked@mm) Trojan L-057: Kerberos /tmp Root Vulnerability L-058: HPUX Sec. Vulnerability asecure L-059: Microsoft IIS WebDAV Denial of service Vulnerability L-060: Mutt Format String Vulnerability and Incompatibility L-061: Microsoft IE can Divulge Location of Cached Content -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use iQCVAwUBOrp+QLnzJzdsy3QZAQGpiwP8DtRo7x4/Z+qkeFaDAFuByZUISRrws+55 r0OD2PAxpXd9CvsCxB7nxGnL9cIUBnGwNNX/iR8hiAkYsX7bUyZYiFFMcp8vvD8O NdUsIpVE4r53EsbXgGZ6vIkoGQItdanz42yc0QCWuD432SbcSPEOeXouYgvLgGvk UnGsluM9BCo= =CQak -----END PGP SIGNATURE-----