Comodo Certificate Issue – Follow Up

Johnathan Nightingale

30

This is a follow-up to the previous Mozilla report about the fraudulent certificates issued by Comodo last week.

On 15th March 2011, a RA partner of the Comodo CA suffered an internal security breach (Comodo incident report). The attacker used the RA’s account with Comodo to cause 9 fraudulent certificates to be issued.

The domain names of the certificates were as follows:

  • addons.mozilla.org
  • login.live.com
  • mail.google.com
  • www.google.com
  • login.yahoo.com (x3)
  • login.skype.com
  • global trustee

These certificates were issued between 6 and 8pm on 15th March from the UTN-UserFirst-Hardware root, without the use of an intermediate certificate. The attack was discovered almost immediately by an internal Comodo check, and the certificates were revoked (via both CRL and OCSP). The compromised RA account has been suspended.

So far, according to Comodo, the only OCSP activity seen relating to these certificates has been two hits, one from the attacker’s IP and one from another very close by, plus hits from testing by Comodo and the notified companies. This suggests that the certificates have not been deployed in an attack, though it is possible that the attackers would block OCSP requests as well.

The IP address 212.95.136.18 appeared to be associated with the attack. According to Comodo, this IP address is an ADSL connection in Iran. From the OCSP traffic mentioned above, we think the attacker is aware that the certificates have been revoked.

Risk Analysis

Given the above, we do not believe that there has been a root key compromise. Nevertheless, an attacker armed with these fraudulent certificates and an ability to control their victim’s network could impersonate the sites in a way that would be undetectable to most users.

With particular regard to Mozilla, the certificate for ‘addons.mozilla.org’ would allow the attacker to imitate the addons.mozilla.org website, and potentially deceive users into downloading malicious software. However, they would not be able to interfere with automatic updates, either to Firefox or to addons. These mechanisms use different domain names, and updates to Firefox also do additional checks to match the certificate issuer to the expected value (which is not UTN-UserFirst-Hardware).

Mitigating Risk

On being informed of this issue by Comodo at 9.47pm GMT on 16th March, Mozilla considered a number of technical avenues. Although Comodo’s revocation is a significant mitigating step, we thought that additional measures made sense and eventually decided to hard-code a blacklist of the certificate serial numbers into Firefox. We therefore produced RC2 of Firefox 4 (released as Firefox 4 final on 22nd March), with two additional code patches (1, 2). These patches disable these specific certificates, plus one additional certificate issued to us by Comodo for testing, making a total of 10. These fixes were also included in updates to Firefox 3.5 and 3.6, also released on 22nd March. As soon as all the patched versions were released, we made a release announcement with some details of the problem.

Mozilla did not publish the information we received prior to shipping a patch. In early discussions, we were concerned that any indication that we knew about the attack would lead to attackers blocking our security updates as well. We also recognized that the obvious mitigation advice we might offer (to change Firefox’s security preferences to require a valid OCSP response in all cases, or to remove trust from Comodo’s certificates, or both) risked causing a significant portion of the legitimate web to break as well.

Additionally, neither we nor Comodo have found any evidence of access to their OCSP responder being blocked, either in Iran or anywhere else. We have also found no evidence of any other sort of attack.

In hindsight, while it was made in good faith, this was the wrong decision. We should have informed web users more quickly about the threat and the potential mitigations as well as their side-effects.

Mozilla has requested that Comodo do the following:

  1. Publish a full account of exactly what happened. (So far: they have published an incident report and a blog post.)
  2. Monitor their OCSP logs for evidence of use of these certificates, or evidence that access to their OCSP responders is being blocked from any geographical locations. (So far: no sign of use or blocking.)
  3. Cancel all relationship with the RA concerned. (So far: the RA is suspended.)
  4. Change their practices to use intermediate certs rather than issuing directly off the root, and use a different one for each RA.

Ongoing Discussion

Unfortunately, the practice of issuing certs directly from the root eliminated some possible steps we could have taken to mitigate the problem. We are concerned about the amount of trust Comodo seems to have placed in RAs whose network security they did not oversee.

Comodo appropriately revoked the certificates immediately and notified the major browser vendors so that more proactive actions could be taken. We are still working with Comodo to find more information on how the breach occurred and what measures they plan to put in place to prevent future recurrences.

This issue raises many questions about the systems surrounding authentication and security on the web. We intend to have a vigorous discussion about what technical and policy changes we can make to significantly improve the situation. You can join the discussion in the mozilla.dev.security.policy forum.

30 responses

  1. Google reklama wrote on :

    So, what you’re saying is that Comodo is in a position to keep everyone silent about a big screw-up like this and that’s OK?!

  2. Paul van Brouwershaven wrote on :

    @Taylor Hedberg
    I think this would not be practical for any kind of product but if there is a safty problem with your car you would be happy if there was a product recall. Just like with any faulty commodity.

    COMODO customers must be offered refunds for any certificates purchased through this CA and Mozilla / Microsoft should force a product recall!

    All affected parties (Google, Mozilla, Microsoft, Skype, Yahoo etc) should seek the full warranty to be paid on this mis-issued COMODO certificates.

  3. toko online wrote on :

    thank you for it

  4. uU wrote on :

    “I’m single hacker with experience of 1000 hackers” Is that Persian for script kiddy?

  5. Richard Whitehouse wrote on :

    The only forseeable way of fixing PKI, and this type of attack is to use DNSSEC and which can be used to verify the certificate is the correct one (for how this works, see Dan Kaminsky’s blog on the subject – http://dankaminsky.com/2010/12/19/dnssec-ch4/ ).

  6. justmoi wrote on :

    What about CAs not issuing certificates if they already exist? That plus blacklisting top100 domains except for the checked owner in case of renewal should make these attacks a bit more difficult.

  7. drs m sembiring wrote on :

    ya, saya cukup kagum atas karya ini

  8. mhn wrote on :

    check this:
    mozilla addon’s certificate
    http://pastebin.com/X8znzPWH

  9. Daniel Veditz wrote on :

    justmoi: there’s a proposed specification for that, but it’s not going to help if a CA gets hacked. Similarly Comodo should have had processes in place to automatically check domain ownership but those got bypassed in this attack.

    There are similar proposal that would have _browsers_ check that the CA in the presented certificate matches the expected CA. These show more promise because it’s a check independent of the potentially-compromised certificate authority. One proposal requires DNSSEC support first, the other is to remember which CA you saw last time.

    mhn: that addons certificate is the one fraudulently issued in the Comodo hack. It has been revoked.

  10. Sonic Games wrote on :

    That’s what I like about this blog. Full release of any security issues, I wonder if Comodo can be blacklisted?

More comments: 1 2