My next class:

Comodo RA Compromise

Published: 2011-03-23. Last Updated: 2011-03-23 18:11:20 UTC
by Johannes Ullrich (Version: 1)
6 comment(s)

Finally Comodo spoke up to let us know more about the certificate issue we have been covering this morning with Firefox and Microsoft releasing "certificate black list" updates. [1]

Comodo states that none of the keys and signing/intermediate CAs were compromissed. Instead, systems at an affiliate were compromised to trick the affiliate into signing fraudulent certificates. The attacker obtained username and password to log into the partners systems, and was thus able to to issue the fraudulent certificates.

According to Comodo, the breach was discovered quickly and they are pretty sure that the attacker only issued the now blocklisted certificates.

 

[1] http://blogs.comodo.com/it-security/data-security/the-recent-ca-compromise/

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords: comodo ssl
6 comment(s)
My next class:

Comments

"The attacker obtained username and password to log into the partners systems"

Didn't they use certificat-based login ? :)

Denis

Mar 23rd 2011
1 decade ago

Denis, they use RSA tokens!

Steven

Mar 23rd 2011
1 decade ago

I am wondering, my latest Chrome shows all the newly revoked "User Trust" certificates in addition to the two revoked Verisign certs that were always there.

But FF 3.6.16 shows zero (0) certs in its certificate blocking list, why is that?

Pevensey

Mar 23rd 2011
1 decade ago

Famous last words - "pretty sure that the attacker only issued the now blacklisted certificates." Why should an affiliate be able to issue certs for mail.google.com and login.live.com. It is unlikely they own those domains. Why didn't Comodo catch this before the certs were issued? The risk associated with high profile domains would seem to in dicate human intervention.

Jz

Mar 24th 2011
1 decade ago

"Why should an affiliate be able to issue certs for mail.google.com and login.live.com. It is unlikely they own those domains. Why didn't Comodo catch this before the certs were issued? "

You seem to be suggesting that CA's should have a list of special domains that get special treatment. Maybe they should, but that becomes an extra feature of their systems that has to be managed and that means the CA needs more skilled humans managing it. Skilled humans are expensive, and Comodo competes on price.

Ultimately this is a demo of the intrinsic flaw in how the X.509 trust model is used in the real world of TLS/SSL. Users can look at the scores of trusted CA root certs in their browsers and operating systems and have no hope of competently selecting which ones are in fact worthy of their trust. The X.509 model assumes that the decision to trust certain signers is made correctly, when in effect it is barely made at all. Users trust their software providers completely, and the software providers generally shy away from expressing distrust or even skepticism of self-proclaimed CA's.

One can argue that this event proves Comodo unworthy of membership in the set of CA's whose root certs are widely trusted by default. However, such an argument would rest on the dubious axiom that membership in that club is carefully vetted and exclusive to CA's who have proven worthiness at some level above this breach. In fact, this case demonstrates that Comodo is capable of detecting and mitigating a specific sort of breach. I don't know that about the overwhelming majority of CA's that I "trust" operationally.


Bill Cole

Mar 24th 2011
1 decade ago

Has Comodo issued a CRL that could easily be imported in SSL aware devices that support that sort of thing? I'd like to make sure I can tell my bosses that we will not allow folks to visit sites with the fraudulent certs, but I'm not sure how to guarantee that.

Jason

Mar 24th 2011
1 decade ago

Login here to join the discussion.


Top of page
Diary Archives