COMMAND
Verisign
SYSTEMS AFFECTED
Verisign
PROBLEM
Following is based on a Microsoft Security Bulletin MS01-017.
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.
- 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.
Sadly, Thawte (which was purchased by Versign and is supposed to
be the second largest CA) does not include a CPD field in their
server certificates either. Actually checking most of the CA
certificates shipped with IE less than half have a CPD field. Of
the big CA only Entrust seems to use the field.
On the plus side if you use IE and go into Internet Options ->
Advanced -> Security and check the boxes next to "Check for
publisher's certificate revocation" and "Check for server
certificate revocation" then you will get a warning. IE won't pop
up the warning when you visit a site with a certificate without a
CPD field but if you click on the lock and bring up the
certificate window you will see the following text:
"Windows cannot determine the validity of this certificate
because it cannot locate a valid certificate revocation list
from the certificate authority that issued this certificate."
First of all, CRLDP is an optional extension, which means you can
include it or not include it (most CAs leave it out). Claiming
that Verisign are somehow at fault because they don't include
this extension is incorrect.
Secondly, even if they had included it, it wouldn't have done any
good. The revocation checking in MSIE is handled by an add-on
DLL called VSREVOKE.DLL. This has some random URL at Verisign
hardcoded into it. If you go into MSIE and dive down into some
obscure menu and enable revocation checking (it's disabled by
default), what'll happen is that it'll go to the hardcoded
address, find there's nothing there, eventually time out, and
process the cert anyway. The only effect of enabling revocation
checking is that every time MSIE sees a cert, it stalls for about
a minute before it continues as if nothing was wrong (this was
for IE4, maybe they've finally fixed it in 5, but that won't help
the huge number of uses who get IE4 pre-installed and never
change their machine configuration).
Therefore even if Verisign had included CRLDP's, MSIE will ignore
them by default, and if you can figure out how to enable
processing would get it wrong. Even if Verisign were to add them
to their CRL, it wouldn't help you if you were using Microsoft
software.
SOLUTION
A patch is available to fix this vulnerability. Please read
Security Bulletin
http://www.microsoft.com/technet/security/bulletin/ms01-017.asp
for information on obtaining this patch.
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.
MS 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. 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.