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.
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.
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.
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.
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?