Slashdot Mirror
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."
Let's go make a new one.
http://dictionary.reference.com/browse/rouge
I prefer teal CAs, myself. Or possibly burnt sienna CAs. Sometimes fuschia CAs.
It's ROGUE you dumbass.
Dude this has got to be the most offtopic comment ever
Oh noes! What department of Slashdot did this article come from? Its the end of the world as we know it! ;)
This space is not for rent.
The commies are creating their own CA!! PANIC!!!
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Why does your bank not give you a compact disc with their public key on it when you sign up for an account?
Go green: turn off your refrigerator.
These certificates are at the basis of truth on secure websites. MD5 has been known to have vulnerabilities for a loooong time (2004 according to the link article). Why do not banking services keep up to date with the state of the art crypto ?
The Wise adapts himself to the world. The Fool adapts the world to himself. Therefore, all progress depends on the Fool.
All Your CA Are Belong To Us
some CA's use MD5 the question really should be which ones
they point to a rather doomsday scenario of having a problem with all SSL Certificate Authorities
this is not the case
only the ones that use MD5
so the question really is what is the list of SSL Certificate Authorities that do this ?
regards
John Jones
http://www.johnjones.me.uk
There's no way he'd fit in there. It would have to be at least... 3 times as big.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
It's important to note that this sort of collision is not taking advantage of any of the known weaknesses in MD5, rather it's brute force.
This is just to head off the inevitable screaming of "MD5 is broken for everything anyway!!!".
I've had enough abrasive sigs. Kittens are cute and fuzzy.
The fact has always been that MD5 collisions can be calculated with rainbow tables for all sorts of reasons... Why weren't all CA's using SHA-1? It's trivial enough with the openssl from apt-get.
THL phish sticks
What's the big deal? Just use another hash.
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
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
I'm not familiar with the details of certificate use, but as far as the cryptologic component there seems to be a reasonable fix, that will not require any change from end-users or invalidate existing certificates (apart from changing the hash).
The attack is based on finding a hash collision between certificates A and B, having the CA signing A, and using the signature for B. If the CA were to make a small change to A before signing it the attack would be foiled, since it requires active participation from the CA.
Suppose the CA started to add a few random bits to each certificate before signing it. The applicant is told what these bits are, so that they can use the signed (modified) certificate to verify themselves to users. With just a few extra bits this would make the attack unfeasible. Does this make sense?
ftfa:
* RapidSSL
* FreeSSL (free trial certificates offered by RapidSSL)
* TC TrustCenter AG
* RSA Data Security
* Thawte
* verisign.co.jp
A lot of people in the twitterverse seem to think otherwise, but this is not a major breakage of the Internet. See my commentary at O'Reilly: http://broadcast.oreilly.com/2008/12/the-sky-is-not-falling-on-toda.html
interestingly enough they used playstations to do so
That's a nice piece of work. I'm very impressed.
Practical conclusions:
I'll set fire to CowboyNeal. That kills two birds with one stone: fuel and food.
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.
There are two kinds of sysadmins: paranoids and losers. I'm both kinds.
Networking4all created a tool to check if a certificate in the chain has been signed with a insecure algorithm
Example:
http://www.networking4all.com/en/support/tools/site+check/?fqdn=www.verisign.com
You can check all sites on:
http://www.networking4all.com/en/support/tools/site+check/
If I understand correctly, it's only a problem for certificates that use only a MD5 fingerprint. For two of the CAs they mention in their paper as doing this, it doesn't seem to be the case: Amazon Germany (certificate from Thawte) and Commerzbank (from TrustCenter) have both MD5 and SHA-1 fingerprints. Good luck generating a rogue certificate that generates a collision in both fingerprints...
I would assume all recent certificates have both fingerprints. Anyway, making sure that the certificate you just got from your online banking site has both fingerprints wouldn't be paranoia anymore...
From TFA, the CAs that use MD5 are these:
* 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
OK, that's it! I'll only accept chartreuse and lavender certificates from now on. Maybe ivory, too.
That is all.
Of all the industries that are slow to implement change in cryptographic practices, banking is by far the slowest. Part of this is bureaucratic inertia, part of this is lack of trust of newer algorithms until "proven" safe, and still part of this is reliance on legacy HSMs in their server facilities. Even the NSA has mandated a faster transition to better crypto (e.g. Suite B) than banking. Banking is still using 3DES instead of AES128, although for practical purposes brute-forcing 3DES at 112 bits of effective security isn't that much worse than AES' 128 bits. Banking won't move quickly unless someone starts stealing many thousands of high-profile accounts, but it'll be a bit like a buffalo stampede.
Still, it's mind-boggling that MD5 is still in use by anyone at this point given that it is susceptible to collisions. NSA Suite B is very clear that SHA2 256 is the minimum acceptable hash, and so it should be elsewhere regardless of your symmetric or asymmetric crypto. Back in the day when RSA512 was still used for PKI because of limited computing power, there might have been an excuse to stick to MD5. And yet, we all moved on to RSA1024 and RSA2048 because RSA512 was broken too. SHA2 is free, and it works. It really is time to move on from MD5 for all uses.
Funny enough that the entire security of the Internet as most users see it is based on the MD5 hash of the browser binary...
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.
Any CA that still uses MD5 should be removed from the list of trusted CAs in all browsers, with immediate effect.
Wouldn't setting security.ssl3.rsa_rc4_128_md5 to false prohibit these kind of attacks?
Strange bunch of hackers. Don't expect some rouge students here, one is Arjen Lenstra, which is a well known figure in the security scene.
Very interesting to see that not only do they issue certificates using MD5 signatures (a very stupid thing to do) but they haven't even bothered to make sure that only leaf certificates can be issued. Or there are probably other CA certificates already issued under these root CA's, making matters even worse.
The article was very well written and thus easy to read. I'm only concerned about the recommendation of the authors to do nothing if you've been issued an MD5 certificate yourself. Doing nothing does not seem to be a very good advice. I would myself go to another shop and get a SHA-1 signed certificate (or even a SHA-2 signed certificate for those not concerned with low level browsers). At least your customers will know that there is no man in the middle due to the MD5 issue, and you show that you care for your clients' security.
Hopefully SHA-1 will hold up a bit longer, because last time I looked (a year ago or somewhere in that order), there were zero (0!) certificates that were self signed using SHA-2, which is not a good indication of the current state at all.
Gosh, that's the second CA I've disabled within Firefox just this week. Interesting times.
I can see this going the way of the digital picture frames.
Build it, and they will come^Hplain.
Ouch.
With reasonable men I will reason; with humane men I will plead; but to tyrants I will give no quarter. -- William Lloyd
what's a rouge certificate - why does the colour matter? ah, I see, maybe the OP mean a rogue certificate!
It's not quite as bad as it sounds. Their attack relies on guessing the certificate serial number and date correctly, which is easy with the CA they chose: RapidSSL uses a completely automatic workflow, issues certificates exactly 6 seconds after the signing request and uses sequential serial numbers. If the CA randomizes the signing date and serial numbers, they can prevent this attack. If this CA does that, and they've promised they will do this and/or switch to SHA-1 ASAP, then this hole is patched, for now. If at least one other CA exists which uses MD5 for signing certificates AND uses sequential serial numbers AND has predictable timing, then that CA is indeed an avenue to attack.
They have to guess these parameters because it's a collision attack: They can not create a new document with the same MD5 hash value as a given document (an existing certificate in this case). They can only create two documents with the same MD5 hash value, if they can add some arbitrary (random looking) bytes to both documents. They use the public key in the legitimate certificate to hide this "garbage". Consequentially the legitimate certificate is non-functional because the key in the certificate isn't an actual public key to which they know they private key. When the CA signs their legitimate certificate, with the right serial number and at the right time, it signs a document which is crafted to have the same MD5 as the other certificate. All other data can be chosen directly by the attacker and just has to conform to the formal specification of a certificate signing request (and look unsuspicious, hence hiding the garbage in the key). The other document (certificate) also has to be a formally valid certificate and can use arbitrary serial numbers and dates, as long as the garbage is hidden in a field that is ignored by the browser (Netscape comment field in their example).
To the hell with backward compatibility. Browsers should already have stoped accepting MD5 signatures by 2004. It was broken by that time, the fact that there was no known exploit did not make it any less bad. By that time people aready used alternatives and tought it would be broken soon, so why did CAs wait?
I hope that, now, the main browsers stop accepting it, and with all that noise about the way Firefox handles certificates, I hope it moves soon. Too bad we have IE6 that probably won't receive any kind of update.
Rethinking email
Good conclusions. You write that RapidSSL and FreeSSL should be pulled from IE and Netscape.
Interesting point about this is, that there is only approx 30 Trusted CA:s in Windows Vista. Compared to how many in XP? 80-100 or so?
Seems that some have already been pulled?
I joined two users too late.
And that is what was done.
Link
You are being MICROattacked, from various angles, in a SOFT manner.
They use the public key in the legitimate certificate to hide this "garbage". Consequentially the legitimate certificate is non-functional because the key in the certificate isn't an actual public key to which they know they private key.
So there is another check which would prevent this attack. The CA should verify the public key passed on to them, it would be a lot harder to create a request which would cause a collision. It seems to make sense to check in some way that the public key you are signing does indeed match a private key owned by the entity you are signing it for.
Yes, there are lots of band-aids you can put over this vulnerability, but it would certainly be easier to just switch to a better hash algorithm. The important bit is that not all MD5-using CAs are automatically vulnerable to this attack, although this should really serve as their wake-up call. The complete predictability of the signed data (due to predictable timing and sequential serial numbers) is what makes this attack possible.
You're on /. and you've actually seen panties?
Stop making shit up.....
"City hall" in German is "Rathaus" Kinda explains a few things......
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.
"If still these truths be held to be
Self evident."
-Edna St. Vincent Millay
I solve this problem by not wearing underwear.
Thus rendering large portions of the SSL-enabled Web inaccessible, or at least having them throw up certificate warnings.
There really isn't a good solution here, given how poorly trained most users are, and how difficult it is to actually push updates to them.
Don't thank God, thank a doctor!
On the other hand (and I think it is more serious). why there are so many CA certs installed by default? Why do I (apperently) trust anything signed by TURKTRUST ELECTRONIK? ;-)
The problem is that you only need to be able to spoof ONE "trusted" CA to be able to forge SSL certs for any site on the net, regardless of where that site's "real" SSL cert was issued. It doesn't matter WHICH CA you actually use.
In this exploit, the attackers managed to obtain an "intermediate CA" certificate--this is a certificate used to sign other certificates on the CA's behalf. This means they could issue a certificate for ANY site, and it would look to all browsers like it was issued by the trusted company. Yes, this is possible--read the article.
Let's say Citibank has a real SSL cert is issued by Verisign, who doesn't use MD5. Now let's say I'm a black hat who's somehow phished traffic headed to Citibank (e.g. by a DNS poisoning, clever spam, etc.). I can issue an SSL cert to my phishing site that's "signed" by a trusted CA (I think they spoofed RapidSSL) that claims to be issued to Citibank.
The browser has no idea that Citibank's SSL cert "should" be issued by VeriSign. It sees an SSL cert that's "properly" signed by a trusted CA, and greenlights the page. No warnings about untrusted CA's, no self-signed certificates, no nothing.
Once you can spoof a Trusted CA, whose root certificate comes distributed with your favorite browser by default, you have the keys to the kingdom.
While I agree it's not a good solution and until the problem is fixed there isn't going to be one. Some people are just too stupid to learn, others are too lazy and the rest don't care until it affects them, and that leaves everyone else to fix the problem or make sure that you break their fingers for them so they don't get their bank/cc/*insert various money exchange* information stolen.
And you can bet there will be hell to pay the first time it happens and people will scream bloody murder because it will be anyones fault but theirs for not learning in the first place.
Om, nomnomnom...
Mail the support e-mail of your favorite browser demanding they drop Trusted CA status for any of the CA's still issuing MD5 signed certificates until they stop issuing them. There's a list of the problem CA's in TFA and elsewhere here. There's simply no reason to allow this kind of security hole to keep existing.
Constraining the content allowed in certificate files should improve the robustness of certificate files.
This approach is notable in that it requires updating SSL implementations to be more stringent -- but it generally shouldn't require changes in the x509 data. Some considerations:
IANAPC,BIRACBBS!
Probably wears 'em.
Not to mention that many governments would not need to break the root CA.
They could just "ask" the CA to write them as many certificates as they like. Given what the Bush Administration's already got away with, there's no reason to assume any CA is really secure in any country.
With SSH, a certificate/key change would at least be flagged as suspicious, but would a browser even so much as raise an alert as long as the new certificate is properly signed and all that?
Indeed. I've been boggled by the byzantine labyrinth of certificate authorities when for most situations the mechanism used by SSH is better.
If needed, Opera 9.50 and newer versions can automatically disable rogue root certificates.
http://my.opera.com/yngve/blog/2008/04/08/new-in-kestrel-faster-root-certificate-updates
This machine will translate any language that ever has existed, unfortunately it will only translate them into an incomprehensible dead language.
Ce que vous pensez est des moutons merde.... c'est vraiment Tasty Wheat.
Crazy Gibberish!!
To add the two, I got an inline ad to this in this thread. (Konqueror helpfully offered to open it in KWrite.)
Fight hunger. Filet a politician and send him to a 3rd world country of your choice.
My bank at least also uses a one-time pad system, namely a numbered list of 100 pre-generated codes.
Just to let you know, that's not a one-time pad. Unless you can only perform 100 logins with that pad. "If a one-time pad is used just twice, simple mathematical operations can reduce it to a running key cipher."
$5 / month hosted VPS on linux = awesome!
> These certificates are at the basis of truth on secure websites.
"Secure Website" is an oxymoron.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
It's not a magical MD5 sum cracker, it's just a way of having an index of pre-computed strings that checksum to various values.
The only ubiquitous usage that is vulnerable to this attack is Microsoft SAM database. Many one-off applications similarly implement unsalted hashes. Unices salt passwords and are therefore not inclined to suffer. It doesn't matter the hashing algorithm in use, they are not particularly differently susceptible to this sort of attack. Note also that cracking the hashes in the SAM database is not even required, as NTLM has the client provide the pre-computed hash instead of password. It's really an extra-braindead architecture.
XML is like violence. If it doesn't solve the problem, use more.
# the below are bash functions for checking cert files
/dev/fd/0 -text -noout |
# and web servers cert signature algorithms.
# note: they are non-recursive, i.e. you see the algorithm
# used to sign the cert, not the algorithm that was used
# to sign the cert that signed the cert.
# morty: call like openssl_cert_signature_algorithm CERT_FILE
openssl_cert_signature_algorithm(){
local file
local algorithms status
for file in "$@"; do
algorithms=$(
openssl x509 -in "$file" -text -noout |
grep -i "Signature Algorithm"|
sed 's,^ *Signature Algorithm: *,,'|
sort -u)
case "$algorithms" in
*md5*) status=BAD;;
*sha1*|*sha2*) status=GOOD;;
*) status=unknown;;
esac
echo "file: $file status: $status algorithms: $algorithms"
done
}
The following can be used to test a server:
# morty: call like: openssl_server_md5_signature www.google.com:443 www.amazon.com:443
openssl_server_md5_signature(){
local server
local algorithms status
for server in "$@"; do
algorithms=$(
openssl s_client -connect "$server" </dev/null 2>/dev/null | \
openssl x509 -in
grep -i "Signature Algorithm"|
sed 's,^ *Signature Algorithm: *,,'|
sort -u)
case "$algorithms" in
*md5*) status=BAD;;
*sha1*|*sha2*) status=GOOD;;
*) status=unknown;;
esac
echo "server: $server status: $status algorithms: $algorithms"
done
}
Why? It would be much better to just remove the MD5 support from the browser.
Do you care about the security of your wireless mouse?
According to the article, the CA does verify it. Only the first part of the modulus is random garbage created by the collision algorithm. Once they have a collision, they can choose the rest of the certificate, so they choose the remaining part of the modulus in a way that together with the random garbage make up a valid RSA modulus.
Do you care about the security of your wireless mouse?
If I understand the CCC's paper correctly, as long as *even one* of the CA certs trusted by the browser uses MD5,
Not quite, but close. It doesn't matter what the CA's cert uses, what matters is the encryption the CA uses to sign *your* cert. The difference here is that everyone need not have to get their browser updated with new root certs to avoid this problem. All that needs to happen is that CA's need to stop signing certs with md5.
Windows is a bonfire, Linux is the sun. Linux only looks smaller if you lack perspective.
Kaminski is an internet Meme. Complaining that a security story mentions him is like complaining that Cmdr Taco isn't related to sex godesses (who would you most like to have home for a beer? Jolie / Johansson / Pressly / Bundchen / Aston / Casta / Cmdr Taco). You just seem like a total pervy loser.
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
These people are the only ones that keep amazing me for well over a decade.
Hats off to them, they made me go "WTF?" list twice today, a list that kaminsky _barely_ made it into a couple of months ago.
You're on /. and you've actually seen panties?
Stop making shit up.....
Psssst. I know this great lingerie shop that's got racks and racks of the things, all out on display... do you wanna know the address?
OK, let me try if I can restate the problem first, then I'll give the question:
So:
1. You want the CA to *sign* a rouge certificate by having it fooled into signing a legitimate, hash-colluded one.
2. In order to do that, you must carefully choose the legit certificate and ask the CA to sign, while using the rouge ones for bad things.
Now clearly when asking the CA to sign, you ought to agree with some of the legal stuff from the CA. The problem I see lies in this scenarios:
(a) You use the bad certificate to do bad things that affect me.
(b) I somehow trace it back to the problem of the certificate being rouge/malicious, etc. I further backtrack the CA tree and found the one that sign your legit certificate.
(c) I file a law suit, and the CA that signed your cert will then know that its misused signature is for you. Then you'll get into troubles.
SO YOU'RE SHOOTING YOURSELF IN THE FOOT.
You can say that's the way it is, since one of your millions enemies may have framed you. Well, I think it's in many order of magnitude more difficult finding a hash-collisioned certificate to a random legit one. So I don't think so.
This isn't precisely accurate. As long as a CA trusted by the browser issues MD5 and the browser accepts the MD5 signature.
It is possible for a browser to trust a CA and choose to ignore MD5 signatures (there are patches to do this).
However, we're talking about a large number of installed Certificates which would overnight become invalid (one browser update at a time).