Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: Comodo RA Compromise SANS ISC InfoSec Forums

Watch ISC TV. Great for NOCs, SOCs and Living Rooms: https://isctv.sans.edu

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Comodo RA Compromise

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 blacklisted certificates.

 

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

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

I will be teaching next: Defending Web Applications Security Essentials - SANS San Francisco Spring 2020

Johannes

3699 Posts
ISC Handler
"The attacker obtained username and password to log into the partners systems"

Didn't they use certificat-based login ? :)
Anonymous
Denis, they use RSA tokens!
Steven

42 Posts
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?
Steven
7 Posts
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.
James

8 Posts
"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.


Anonymous
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.
Jasey

93 Posts

Sign Up for Free or Log In to start participating in the conversation!