CCC Create a Rogue CA Certificate

t3rmin4t0r writes "Just when you were breathing easy about Kaminsky, DNS and the word hijacking, by repeating the word SSL in your head, the hackers at CCC were busy at work making a hash of SSL certificate security. Here's the scoop on how they set up their own rogue CA, by (from what I can figure) reversing the hash and engineering a collision up in MD5 space. Until now, MD5 collisions have been ignored because nobody would put in that much effort to create a useful dummy file, but a CA certificate for phishing seems juicy enough to be fodder for the botnets now."

Comments

Alright this Internet is ruined

[Anonymous Coward]

Let's go make a new one.

Re:Alright this Internet is ruined

[Alrescha]

"I wonder how broken the intarwebs would be to me if I simply deleted all the MD5-based root certificates from my box? Would I even notice?"

I think a better idea would be to simply delete all the certificates from your box (CA certs included!). Then start marking individual web certs as trusted after you inspect them yourself.

A.

Rouge CA?

[realmolo]

I prefer teal CAs, myself. Or possibly burnt sienna CAs. Sometimes fuschia CAs.

It's ROGUE you dumbass.

Re:Rouge CA?

[nsushkin]

I prefer teal CAs, myself. Or possibly burnt sienna CAs. Sometimes fuschia CAs.

It's ROGUE you dumbass.

Surely you meant FUCHSIA

Why trust the PKI?

[characterZer0]

Why does your bank not give you a compact disc with their public key on it when you sign up for an account?

Re:Why trust the PKI?

[fastest fascist]

Using that would probably be more hassle than your average user is willing to put up with. A bigger wtf is, in my opinion: Do so many banking services really rely on a single login/pass combo per user for authentication? When banking security comes up here, I see people worry about having their login+pass revealed, which makes me think that's the only verification their banks use.

My bank at least also uses a one-time pad system, namely a numbered list of 100 pre-generated codes. So I log in using a username and pass, and then to actually do something with the on-line banking system I'm asked to provide the code that relates to a randomly chosen number between 0000 and 0099. A code can only be used once. So basically if the phishing site manages to get hold of a few numbers from a user's passcode list, the chances are still pretty slim they'll be able to do anything with them.

Of course, if they scam hundreds of people, they will get a few successes, but not very many.

Re:from the ... dept?

[DoofusOfDeath]

Oh noes! What department of Slashdot did this article come from? ...

Hold on - I'll check the signature.

Re:from the ... dept?

[TypoNAM]

I hate replying to myself, but if anybody hasn't noticed that CmdrTaco has been trying to tell us something and by this article he has apparently given up:

Alan Cox Leaves Red Hat
Posted by CmdrTaco on 10:11 AM -- Tuesday December 30 2008
from the bet-wherrever-he's-going-he'll-have-electricity-and-heat dept.

The Fight Over NASA's Future
Posted by CmdrTaco on 08:15 AM -- Tuesday December 30 2008
from the still-no-power-at-my-house dept.

Storm Causes AT&T Outage Across Midwest
Posted by CmdrTaco on 08:55 AM -- Monday December 29 2008
from the guess-who-this-includes dept.

So he's without power and worse no internet at his home, aww poor CmdrTaco. Somebody please think of the slashdot editors! Anybody got a spare generator and fuel? ;)

CA's using MD5

[xaosflux]

FTA, the following common CA's are still using MD5.

RapidSSL
C=US, O=Equifax Secure Inc., CN=Equifax Secure Global eBusiness CA-1

FreeSSL (free trial certificates offered by RapidSSL)
C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Network Applications

TC TrustCenter AG
C=DE, ST=Hamburg, L=Hamburg, O=TC TrustCenter for Security in Data Networks GmbH, OU=TC TrustCenter Class 3 CA/emailAddress=certificate@trustcenter.de

RSA Data Security
C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority

Thawte
C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com

verisign.co.jp
O=VeriSign Trust Network, OU=VeriSign, Inc., OU=VeriSign International Server CA - Class 3, OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign

Re:its only the CA's that use MD5 so the question

[gclef]

It's in their slides. As of 2008, there were some big names still using MD-5:

RapidSSL
FreeSSL
TrustCenter
RSA Data Security (!)
Thawte (!)
verisign.co.jp

Re:from the ... dept?

[MBCook]

Let's put up a poll to see what we can all do!

• I'll put Taco up at my place
• I'll donate some food
• I'll donate some fuel
• I'll donate some CPU time
• Taco is a big boy, he can help himself

A nice piece of work

[Animats]

That's a nice piece of work. I'm very impressed.

Practical conclusions:

• The weakest trusted CA in the world compromises the entire public key infrastructure. What they've been able to do is not just create a phony SSL cert. They've been able to create a trusted but phony certificate authority root certificate which can be used to sign other certificates.
• MD5 has to go. The PKI infrastructure already supports SHA-2, which is considered better; MD5 is only there for legacy certs. So an upgrade doesn't require end-user browser changes; it can all be done by CAs and web sites.
• It's not that hard to do this attack, but it does take some resources. They used a farm of 200 Playstation 2 machines to attack MD5. This is well within the capabilities of, say, the Russian Business Network.
• RapidSSL and FreeSSL seem to be the current weakest points in the system. "Out of the 30,000 certificates we collected, about 9,000 were signed using MD5, and 97% of those were issued by RapidSSL." Worse, those two issuers issue certs with ascending non-random serial numbers, so that, with careful timing, they can be induced to issue a cert with a known bit pattern, which is required for this attack. Probably, RapidSSL and FreeSSL's trusted root cert should be pulled from IE and Netscape, and all certs from those sources re-issued using SHA-2 hashes.
• I don't think the RapidSSL and FreeSSL root certs are EV-enabled, so this specific attack probably can't be used to generate phony Extended Validation certs. Also, the EV standards require SHA-2 or better hashing, not MD5, which is more of a legacy hash algorithm. So the EV cert world is probably still secure.

Missing option

[pjt33]

I'll set fire to CowboyNeal. That kills two birds with one stone: fuel and food.

Re:its only the CA's that use MD5 so the question

[perp]

If I understand the CCC's paper correctly, as long as *even one* of the CA certs trusted by the browser uses MD5, it is possible (with considerable effort) to create an intermediate CA cert that can be used to sign a cert for any FQDN, say paypal.com. Then with a little DNS poisoning, the user is directed to an https site, with a correct domain name and (if the user looks, not bloody likely) a perfectly good certificate that looks like it was signed by a cert that was signed by a cert trusted by the browser.

You don't have to create many rogue certs, all you have to to is create one rogue intermediate CA cert that can sign as many certs as you like, all of which will be accepted with the default browser config. This is what the CCC has done.

Reality check for Mozilla

[Burz]

First, this issue is about banks (for instance) verifying themselves to the client, not the other way around, so not sure how OTPs and such figure into this.

Overall, between the drama over one of Comodo's trustee CAs handing out certs without verification (for mozilla.com no less) and this MD5 attack, there is a lesson on this for Mozilla:

Trusted CAs aren't the epitome of web safety. In fact, they are LESS safe than one of those "Invalid" (to use Mozilla's ill-chosen words) self-signed certificates under some circumstances.

I put the ranking of https safety as follows:

1. Any self-generated cert (even self-signed) which has been directly copied from the service provider (bank, etc.) and imported into the browser.

Though this is the most secure, it is a shame that the user may receive warnings from other Firefox users who visited the site about the cert being "Invalid", undermining confidence in this most secure method of using certs.

2. Any self-generated cert (even self-signed) verified by SHA1 fingerprint "out of bank" (e.g. letter or phone call or even email) then imported into the browser. Unfortunately the easiest method to initiate this procedure (visit the site, verify then click on a button to import) is now somewhat broken in Firefox and will quite inappropriately undermine the user's confidence in what is otherwise a very secure cert.

3. Relying on the browser-trusted CAs. Unfortunately there now many of them which are obscure even in the tech community, and some are sloppy and incompetent.

Re:No weakness

[Just Some Guy]

Maybe it's my naivety, but wouldn't a hash have to be of infinite length to be able to be used in a way that guarantees no collisions?

That's what I thought he was saying at first, but it's not. For an n-bit hash, the birthday paradox says you'll need to try an average of (n/2) bits to find a hit. The problem with MD5 is that you can find collisions in much fewer than 2^64 attempts. So sayeth Wikipedia:

On 18 March 2006, Klima published an algorithm[9] that can find a collision within one minute on a single notebook computer, using a method he calls tunneling.

So yes, all fixed-length hashes will have an infinite number of collisions. It's just that some hash algorithms make it a whole lot easier to find some of them.

collision attacks are easy to identify

[conspirator57]

note that the collision attack requires a bit of junk in the cert to make the hash be the same as for the original... this means the junk will not look like the rest of the cert. the rest of the cert is formatted and the collision noise will look mostly random. a simple test for unexpected randomness in the cert data (including Netscape comments) would reveal this sort of mischief. it just takes a bit of code on the browser to look for it. shouldn't even degrade browsing performance too much.