You are here

More Bogus Certificates

I few months back I retold the story of a bogus Microsoft certificate issued by Verisign in 2001. It's a difficult story to track down ten years later because many articles published by then have either disappeared or been 'updated' to remove details.

The story becomes relevant again, since certificate authority Comodo detected and reported issuance of nine bogus certificates. I must commend Comodo for detecting and reporting this promptly. The bogus certificates are now listed in Certificate Revocation Lists (CRLs) which, unfortunately, very few software packages actually use. Microsoft has taken the suspenders-and-belt approach of distributing a patch to identify the bogus certificates and mark them as "untrustworthy."

I'm going to summarize the Comodo story, compare it to the Verisign '01 story, and ruminate about progress, or rather lack thereof, in public-key cryptography.

What happened at Comodo?

Nothing happened at Comodo itself. An affiliate with the identifier "UTN UserFIRST Hardware" had several login accounts compromised - essentially the attackers intercepted user IDs and passwords. One of the compromised accounts allowed the affiliate to issue PK certificates signed by Comodo. Once the attackers could log in, they could issue whatever certificates they wanted.

Since Comodo public key certificates are recognized by every major browser, the fraudulent certificates would allow their owner to masquerade as those sites. The targets included live.com, google, gmail, yahoo, skype, and mozilla. Comodo issued a security advisory that listed these targets and noted that these are part of the communications infrastructure, not the financial infrastructure.

Moreover, the attack was tracked back to a site in Iran. This doesn't prove that the attack originated in Iran, since the attacker may have penetrated the computer in Iran and simply exploited it to launch the attack.

Why attack these sites?

There are different theories. One popular theory is that the attackers represent a government that wishes to eavesdrop on dissident groups. If a dissident uses a bogus SSL certificate when connecting to one of those sites, the government could launch a bucket brigade or man-in-the-middle attack that allows eavesdropping on the communication. This fits certain Western expectations of the current Iranian regime.

However, a masquerade of these sites might also support a two-stage financial attack on end users. In the first stage, the attack compromises email accounts at GMail, Yahoo, and so on. In the second stage, the attacker looks for a similar user ID and password on different financial sites. The attack can begin by using the GMail or Yahoo password. If those don't work, then the attacker performs a password reset. Since they have already compromised the email account, they can intercept the password reset and take control of the financial account.

The financial attack seems less likely, if only because the attacker included Skype in the targets. I can imagine how one could build scripts to coordinate an attack between email and financial sites. Incorporating Skype effectively would complicate matters unless the attack focused on using SMS-sized messages.

Comparing this to the 2001 Verisign/Microsoft Incident

In the 2001 incident, a soon-to-be-former Microsoft employee induced a colleague at Verisign's certificate authority to issue a certificate with Microsoft's name. This employee's soon-to-be-former job involved ordering certificates, so he used social engineering and an established working relationship to issue the certificate.

As far as anyone can tell, the incident was simply a "proof of concept" attack. The attacker simply wanted to demonstrate that a respected authority could issue a bogus certificate containing Microsoft's name. As far as I'd ever heard, the bogus certificate was never spotted "in the wild." In fact, the certificate was specially constructed to sign code, and not to authenticate web sites. This was in the early days of such protections - lots of sites routinely uploaded patches, Javscript, and other software without verifying its source or integrity.

As with this latest incident, the certificate authority added the bogus certificate to its CRL and Microsoft issued a patch that specifically looked for that certificate. And, as with the latest incident, observers lameted about how poorly our software handles CRLs. This has, again, led Microsoft to patch its software directly to address the bogus certificates instead of ensuring that it uses CRLs correctly.

Comodo's Culpability

A brief search of the Net indicates that Comodo may be the king of low-cost SSL certificates. A few affiliates even advertise "free" Comodo certificates. To support such an efficient operation, I don't doubt that Comodo meets some minimum security requirements, but these minimums are obviously too low. What's the point of demanding two-factor authentication on any web site if an SSL certificate authority can be tricked by intercepting a simple user name and password?

Post category: 

Comments

I don't know which is worse, 1, A CA with poor security practice. 2, Browser designers who make user based certificate managment almost impossible. It has been sugested that browser implementors lump in every CA root certificate simply to avoid being sued by CA's or their customers. I do not know what the truth of this is but why oh why do they make managment of certificates by users so darn difficult that even relatively competent users cannot hope to master it with their supplied solutions. As for CA's most of them have business models aimed primarily at minimising cost not at maintaining sensible security levels. We have just recently seen RSA (kind of) admit thatt they had been hacked and many of their two factor hardware tokens potentialy compromised. And we have seen with Stuxnet that "code signing" certificates are not given the protection they should be. Realy we should be asking ourselves if we can trust those people up stream of us in the trust chain, because we are seeing increasing examples where those at the top of such hierarchical authN/Z systems being targeted by hackers because this give a much better ROI than attacking the other end of the trust chain. Maybe we should say enough is enough and look into other non hierarchical systems where the attack space is localised to the point of attack and does not spread out in the way a compromised hierarchical system does. However we also need to find a method of persuasion to make the browser implementers sort their act out with regards certificates such that even novice users should be able to manage certificates at will.

That's an interesting observation. Now that every desktop seems to contain CA software, people have more flexibility. And more ways to get into trouble.

I found myself imagining if there might be a way to detect a masquerading certificate - for example, it says ebay.com but the private key belongs to some hacker. It's a hard problem: the same data paths that led the victim to the bogus site will intercept any attempts to verify the certificate.

It seems like there might be some benefit in adding countersignatures to certificates - bringing back the web of trust - except that I'm not sure how well it's supported by today's PK software.

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer