My next class:

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)
My next class:

Comments

"This event more and more looks like the trust pyramid was really more a stinking pile of doo."

Spoken so eloquently!

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

Wow.
I don't get it... Why does it require a patch to fix this sort of problem? Shouldn't there be revocation infrastructure in place to handle this sort of event? What happens if a root key is compromised? Do we have to just stay off the internet until Microsoft blesses us with a patch?
@Pete

Please read either the Microsoft Security Advisory or the Comodo blog post. Internet Explorer (like Firefox) does not necessarily need this update; as Comodo has updated their CRLs and OCSP responders to provide revocation data. But because of the high profile of the domain names, Firefox and Microsoft decided to release an update that would help ensure that end-users knew these certificates were revoked. This way, the clients don’t need to rely on fetching a OCSP/CRL to know these certs are bad.
"...this fundamentally breaks the trust model of SSL"

You mean it used to be valid? :) Was that before, or after Verisign gave away a couple of microsoft certs...
Since HTTPS attacks involves DNS hijacking/poisoning most of the time, the CRL is worthless. If I can redirect login.live.com, I can also redirect crl.comodo.com.

I might not be able to give a signed OCSP back, but then I can timeout, which will make some software work.

Signed DNS (DNSSec) as a requirement and the public key in DNS would be the next step. This would help a lot. Preventing DNS hijacking is the important issue here.
DNSSEC; really NO.
Name resolution shouldn't be a high priority target for an attacker.

The existing DNS system is perfect for what it's supposed to do; like IP itself DNS is a best efforts service, you ask for a name and it gives you one or more IP addresses that probably point to the machine you're after and it does this as quickly as possible.

DNSSEC doesn't change this; connections will still fail, old data will still be cached. What DNSSEC does is improve the security of certain (actually broken) protocols that depend on the DNS structures being perfect. (actually, it can also slow things down a bit ...)

The fact is to use one of the compromised certificated you don't need to poison the DNS, you can get 'in the middle' many other ways; eg: ARP, routing, wifi hacks and so forth. DNS is just the one with the longest range; for the moment.

The only way to actually do the authentication of an unknown peer is the way kerberos does it, using a direct specific query to a trusted third party whom you can authenticate directly. If you do that you have the choice of how long to accept a cached 'ticket' with SSL certificates the 'ticket' is cached by the person providing it to you; probably for years.
Any idea why this would not be available on WSUS???
@Dale

Check your approved classifications in WSUS, this is classified as a critical update not a security update.
What is the risk of information loss to the domain user?

It takes 5 minutes to replicate a website. The hack was discovered 2 hours in. Not sure how soon certs were blocked, blacklisted. Would this mean some users have lost information including personal data? Should we be advising all to change their passwords? A lot can happen inbetween the point of certificate publishing and certificate black listing.

Diary Archives