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)

Microsoft Advisory about fraudulent SSL Certificates

Published: 2011-03-23
Last Updated: 2011-03-23 18:05:29 UTC
by Johannes Ullrich (Version: 3)
10 comment(s)

Update: Looks like the update is marked important, but will not install automatically. You may have to run Windows Update to install it

Update 2: And Comodo just published an advisory: http://blogs.comodo.com/it-security/data-security/the-recent-ca-compromise/
also not that this is still the same issue we talked about this morning with respect to Firefox 4.

 

Microsoft just released an advisory [1] alerting its customers that a total of 9 certificates where issued using the leaked/stolen CA certificated from Comodo.

The affected domains are according to Microsoft:

  • login.live.com
  • mail.google.com
  • www.google.com
  • login.yahoo.com (3 certificates)
  • login.skype.com
  • addons.mozilla.org (already known from an earlier announcement by Mozilla)
  • "Global Trustee"

The advisory states that Comodo has revoked these certificates and listed them in its revocation list. Microsoft also is releasing an update that will blocklist these certificates.

Of course, this issue is "serious", not just considering the household brand names affected. Probably even worse then the possible man in the middle attacks that may have happened is the simple fact that this fundamentally breaks the trust model of SSL. SSL is using a "trust pyramid", A few certificate authorities are trusted to issue certificates to entities they trust. Of course this trust should be based on some kind of verification and the ability to secure the private key that goes with the root certificates and the signing certificates based on it. This event more and more looks like the trust pyramid was really more a stinking pile of doo . No surprise given the rush to the "no paper work required bargain basement certs". I recently started using free certs from startssl.com just for that reason: At least startssl doesn't charge me for not verifying who I am.

In short: Patch... and hope you will be ok until the next time this happens. It would be nice if Comodo would come forward with details. It was probably the APT Monster that ate it.

 [1] http://www.microsoft.com/technet/security/advisory/2524375.mspx

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

Keywords: comodo ssl
10 comment(s)

Firefox 3 Updates and SSL Blocklist extension

Published: 2011-03-23
Last Updated: 2011-03-23 13:01:43 UTC
by Johannes Ullrich (Version: 1)
2 comment(s)

At the heals of yesterday's Firefox 4 release, we today got 3.6.16 and 3.5.18. As usual, Mozilla will provide security updates for some older browsers after the release of a new major version. If you are not planning to update to Firefox 4 soon, you should update to the newest 3.x version.

This wouldn't be worth a full diary (usually we just publish a "one liner") if it wouldn't be for one interesting change: Mozilla decided to add some new blocklisted SSL certificates.

SSL certificates are usually considered valid if signed by a trusted certificate authority. My version of Firefox 4 on a Mac includes certificates from about 80 trusted organizations. If a certificate authority finds out tht a certificate was signed by mistake, they may add the bad certificate to a revocation list. Each certificate includes a URL for a revocation list, and the browser may check if the certificate is listed as revoked.

However, browsers are not required to check revocation lists. In addition, if a certificate authority is compromised, it may lead to compromised revocation lists as well. The black list feature in Firefox (same feature exists in Chrome) lists a small number of certificates that the browser will not trust.

The recent addition is rumored to be due to a compromised certificate authority, which has been used to issue fraudulent certificates. [1] In particular it is suggested that a certificate for "addons.mozilla.org", the site used for Firefox plugins, was created using the compromised CA.

 

 [1] https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion

Also see:

https://github.com/ioerror/crlwatch#readme
https://www.eff.org/observatory
http://blog.mozilla.com/security/2011/03/22/firefox-blocking-fraudulent-certificates

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

Keywords: Firefox ssl
2 comment(s)

Firefox 4 Security Features

Published: 2011-03-23
Last Updated: 2011-03-23 10:28:43 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)

Like no other release before it, Firefox 4 includes a number of significant security features. These features are addressing attacks that are in particularly hard to avoid by developers and in which the browser is more so the victim then the server.

These attacks, Cross Site Scripting (XSS), redirects to HTTP pages from HTTPS and Clickjacking use vulnerable web applications more as a mirror to bounce attacks into the browser. The browser can provide meaningful protection against these attacks, unlike for more server centric attacks like sql injection, for which the attacker is in full control of the client.

XSS and Content Security Policy (CSP)

We have seen a couple of prior attempts to assist browsers to detect XSS attacks. All of these attempts, (the NoScript plugin or the IE 8 "X-XSS-Protection:" header had the same problem: They had no idea what kind of script to expect on a particular page. In some cases, they could prevent reflected XSS just by comparing strings sent by the browser to strings being returned by the server. Neither NoSpring nor IE 8 did a sufficient job in preventing XSS and many users or web developers turned it off due to high false positive rates.

CSP takes a different approach: It uses server headers to tell the browser what kind of content to expect. That way, the browser can make a more intelligent decision as to how to block content that does not match the policy communicated by the server. I will probably discuss this feature in more detail in the future, but if you are interested, last months Monthly Threat Update webcast covered the main points. [1]

One CSP feature I would like to point out: The server may communicate as part of its policy a "Report-URI" which the browser can use to report any violations of the CSP. This is not only great to detect attacks, but even more so to detect legitimate features on your site that are not sufficiently covered by your policy.

If you would like to experiment: Just add "?csp=Y" to any isc.sans.edu URL. It will enable our test CSP. Right now, it is not very restrictive as I am still refining some of our content. We do also have a little CSP test page at http://isc.sans.edu/tools/csptest.html which highlights some of the features.

Strict-Transport-Security

Another neat feature to tell the browser more about how to connect to a given site. If the "Strict-Transport-Security" header is set, the browser will refuse any attempt to connect to the site via HTTP. The threat model here is that an attacker will inject a redirect to the HTTP version of the site while the user is browser a non HTTPS site (any site, not just the target). This could lead to the disclosure of confidential information like authentication cookies. Sure. This attack can be mitigated in part by setting the "secure" option of your session cookie. But it may not be so easy if the injection of the redirect happens during the login process.

This header has two parameters: A "max-age" indicating for how long this rule should be obeyed and a "includeSubdomain" parameter that will extend the rule to all subdomains. This header should be used on all HTTPS only sites.

Other changes

A few other changes:

- X-FRAME-OPTIONS Header: it can be used to prevent a site from being included in a frame. This option exists in other browsers as well (IE, Safari, Chrome). Some of the recent 3.6 versions of Firefox already included it and NoScript implemented it. CSP implements a more fine grained restriction on framing.

- User-Agent Header: Firefox 4 uses a less verbose user agent header which makes it a bit harder to track users

- Do-Not-Track Features: More about this later. It does signal sites if you don't want to be tracked.

[1] https://www.sans.org/webcasts/isc-threat-update-20110308-94078
[2] https://developer.mozilla.org/en/Firefox_4_for_developers#Security

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

0 comment(s)

Comments


Diary Archives