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.
I prefer teal CAs, myself. Or possibly burnt sienna CAs. Sometimes fuschia CAs.
It's ROGUE you dumbass.
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
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?
No, no, no. The 'rouge' is referring to the face colour and embarrassment of the legit CAs when it turns out that they're issuing SSL certs to www.we-will-hack-you-good.com
"City hall" in German is "Rathaus" Kinda explains a few things......
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/
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.
It's a problem for all websites. All you need to do is forge a certificate from Amazon that uses MD5 and redirect someone's browser via Wifi hacking or DNS redirection.
The browser doesn't know that Amazon didn't use Verisign's busted MD5 cert root.
æeee!
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.
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
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? ;-)
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...
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.
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
}
Oh, I don't know. "What you think is sheep shit .... it's really Tasty Wheat" seems about right to me.
XML is like violence. If it doesn't solve the problem, use more.
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();
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.