Today, Microsoft issued a Security Advisory warning that fraudulent digital certificates were issued by the Comodo Certificate Authority. This could allow malicious spoofing of high profile websites, including Google, Yahoo! and Windows Live.
The advisory states how 9 certificates were fraudulently issued by Comodo for the following names:
• login.live.com
• mail.google.com
• www.google.com
• login.yahoo.com (3 certificates)
• login.skype.com
• addons.mozilla.org
• 'Global Trustee'
The major issue is that Comodo is a trusted root authority on all default Windows and OS X installations. This means that an attacker could easily masquerade a malicious website as one of the above with the HTTPS authentication succeeding.
This kind of power would have any internet miscreant drooling over the opportunity to construct phishing sites, perform man-in-the-middle attacks, and any other content-spoofing attack that can be dreamed up.
That being said, Comodo claims in an incident report that only one yahoo.com certificate was seen live on the internet, and that site was promptly taken down.
All of the fraudulent certificates have been revoked and browsers with certificate revocation checking enabled (see below) will properly identify the certificates as invalid.
How did this happen?
According to a report by Comodo, an account used for the approval of certificate requests was compromised within one of their trusted partners.
An attacker obtained the username and password of a Comodo Trusted Partner in Southern Europe. We are not yet clear about the nature or the details of the breach suffered by that partner other than knowing that other online accounts (not with Comodo) held by that partner were also compromised at about the same time.The attacker used the username and password to login to the particular Comodo RA account and effect the fraudulent issue of the certificates.
This highlights one of the major problems with digital signatures and the public key infrastructure (PKI) -- that being transitive trust.
When Comodo provided their partner with the ability to issue certificates in their name, they were not only trusting said partner to properly vet the identities for certificate applicants, but also trusting the partner to protect this power to issue certificates.
This is similar to the Stuxnet outbreak from last year, in which the private key compromise of hardware vendor Realtek enabled fraudsters to spread malware having a valid digital signature.
In that case, by issuing the certificate to Realtek, the certificate authority was similarly not only trusting Realtek to sign legitimate software themselves, but also trusting them to protect this power from abuse.
Trust is transitively passed down the certificate chain, where a compromise at any level breaks the chain completely -- and every chain has its weakest link.
Countermeasures
As stated above, Comodo has already revoked the 9 fraudulent certificates. The revoked certificate serial numbers are published in Comodo's Certificate Revocation List (CRL), which can be manually imported and consumed on most platforms; on Windows via certmgr.msc, on OSX via KeyChain, or directly into some browsers, like Firefox.
Enabling certificate revocation checking in your browser is also advisable, not only for this particular issue, but to benefit from past and future revocation information as well.
Notably, from my VB2010 presentation on digital signature abuse, neither Internet Explorer 8 nor Firefox have certificate revocation options set to safe defaults. Internet Explorer 8 has server certificate revocation checking off by default and Firefox only has Online Certificate Status Protocol (OCSP) revocation enabled. Microsoft has changed the default in Internet Explorer 9 to have server certificate revocation checking enabled by default.
Fortunately in this case, Comodo certificates support OCSP revocation, so Firefox users (including Firefox 4) as well as IE9 users will be protected by default, where as IE8 users will have to enable this setting, if they have not already.
In parallel, Microsoft have also issued an update that installs the 9 fraudulent certificates as 'Untrusted Certificates'. These are also viewable via the certmgr.msc tool on Windows.
And for the uber paranoid, you can perform an extra sanity check by examining the issuer of the certificate when visiting one of these sites -- as none of the genuine certificates have been issued by Comodo.
Closing thoughts
The immediate action items are clear; users on all platforms should ensure they've got up-to-date certificate revocation data and browser settings to keep it that way for the future.
The longer term solutions for the security industry are less so. While the detection of these fraudulent certificates was quick and published remediation swift, this fast response may well have been a fluke as a result of the particular way the attack was conducted.
In their incident response, Comodo reports the attacker used the compromised account to create a new account from which the fraudulent certificates were approved.
Perhaps if the attacker had been more covert, avoiding the user creation and separating the high-profile certificate request approvals by a longer time frame, the compromise may have gone unnoticed with far more drastic consequences.
In no way is this an easy problem to solve. Software has vulnerabilities; systems get broken into; malicious insiders aid and abet.
Hopefully this causes the industry players to audit not only their own security systems and policies, but those of their trusted partners as well. As the problem of transitive trust remains inherent in the PKI, it's about every link in the chain, not just your own.
Happy browsing.
Creative commons picture of a padlock courtesy of Trevor Blake's Flickr photostream.
