03.25.11 - 08:39am
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:
- Publish a full account of exactly what happened. (So far: they have published an incident report and a blog post.)
- 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.)
- Cancel all relationship with the RA concerned. (So far: the RA is suspended.)
- 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.
Category: Firefox, Security | | 30 Comments »
