A Layman’s Explanation of the CA Certificate Vulnerability

Well, since I’m now known for my dummied down versions of current security issues, I figured I’d go ahead and toss this one out there for you. There will be plenty of supergeeky explanations, including the full write up from the research team (links below). If you want a plain english (yes, not German) explanation, here you go…

What Vulnerability?

Today, December 30th here in the US, at 9:15am Eastern, an international team of researchers presented their real-world process of creating a rogue CA certificate at the 25th Chaos Communication Congress in Berlin. The session’s true title and topic was closely guarded and appeared as something like ‘vulnerability of Internet infrastructure’ until early this morning. “MD5 considered harmful today: Creating a rogue CA Certificate” is the actual research title that is now displayed.

MD5: The Underlying Issue

We’ve known for years that MD5 has vulnerabilities of enough volume and significance to make it ineffective, at best, in today’s world. So what is MD5? MD5, or Message Digest 5, is a commonly used hash algorithm used for checksums, password storage and other applications. The algorithm is about to reach it’s 20th birthday. In the security world, that makes it about 210 years old and way past its useful life.

About Hashes

Crypto has been one of my specialties, so if you read my blog, I fully expect you to understand hashes. However, many of you pass along these tidbits to management, so I’ll make sure our bases are covered and I’ll throw this in to save you the trouble. A hash function takes a block of data and spits out a fixed-size output based on a computation. Hashes are one-way, so a long string of data gets smooshed into maybe 128 or 256 bits, but there’s no way to take the hash and work backwards to extrapolate the original long string.  They’re used as ‘fingerprints’ to be sure the original data has not been altered. If the hash value is different, then something in that original block of data is different. One little bitty change can drastically affect a hash output.

But the complication comes in what we call collisions. Since we’re starting with a long string of data and ending up with a short (128-256 bits usually) output, we do run the risk of original strings that would result in the same hash… and that’s the ‘collision’. Two sets of data that are different come up with the same hash. It happens, but it happens most often in MD5, which is why we want MD5 to go bye-bye.

Real example. Let’s say we have a string of text… I used the first paragraph under What Vulnerability… my MD5 hash of that paragraph of text is: a050cf3d9342083bd37b79211a20c34b. MD5 took the 501characters and gave me a hash that’s 32 characters long.  Now, if I hash the complete text up until this sentence, it’s 2809 characters (until I go back and spellcheck probably). That hash is 0d3763487d1290f9f1317e37284f2c7a. So again we have a 32-character output, the size of which is not proportional in any way to the length of the original text. You see how this can get messy with a simple algorithm and short fixed-length output. Even a single space has a 32-character MD5 hash. Eventually we’ll find something, short or long, that gives us the same output as another something else.

Connecting the Dots: Hashes and Certs

So, what does a hash function have to do with CA certificates? Well, like everything else, we check the validity of certificates with their hash. If we can produce a fake certificate with the same hash as a real certificate, we can trick browsers and applications into thinking our faux cert is the real deal.

How do we get make a collided-hash cert? Well the gentlemen that conducted the research have the full write up (links below), but in general, they were able to reverse-engineer a collision by using their bank of PS3s to compute what would be necessary to change in the input data. In other words, they controlled as many variables as possible (including when certificate was generated and the serial number) in order to offset the effects of data they could not modify in the certificate.

For a super dumbed down version, let’s say there are 4 sections to this certificate, and 1 section we cannot modify. Let’s say our certificate is made of numbers, and we need the numbers to add up to 3000. Totally making this up for demonstration purposes, this is not how certificates work. Each section has a fixed length, so section 1 is 3 numbers long, section 2 is 4 numbers long, section 3 is 2 numbers long and section 4 is 3 numbers long.

So in this crazy little example, we can’t change Section 3, but we can modifiythe content of sections 1, 2 and 4 to still make the total equal 3000. Clones 1 & 2 don’t work because Section 4 is the wrong length, but in Clone 3, we hit jackpot. Again, this is a really simplified example, especially since we can easily come up with a variety of Clones that would equal 3000, but you get the point.

The method by which they executed the attack is amazingly sexy and technical and I’d encourage you to look through the links below if you want to read all the cool stuff and see photos of their PS3 computational cluster force.

Whos’ at Risk?

Directly, anyone using a certificate with an MD5 hash signature. The boys identified a handful of CAs still using MD5 today, the list includes:

• RapidSSL
• FreeSSL (by RapidSSL)
• TC TrustCenter AG
• RSA Data Security
• Thawte
• verisign.co.jp

Indirectly, everyone, regardless of what hashing algorithm your certificate is using, Keep reading the next section to find out why.

What Does it Mean?

At best.. or worst.. depending on if you’re the attacker or attackee… an attacker could create a fake web certificate and trick your browser into thinking you’re really at PayPal or Bank of America, when in fact you’re on their server. In their research, they actually took this to the next level and created not only a rogue certificate, but a rogue certificate authority (CA), which are the things that sign certificates. Not only could they create a single rogue cert with this attack, now they could generate unlimited rogue certs from their rogue CA… Probably by now you see why people are a little unsettled.

Unfortunately for now, there’s not much that can be done, except for putting pressure on the (real) CAs to move to more secure hashing functions, like newer flavours of SHA. Many certificate users will probably panic today, ripping out old certs and replacing them with new SHA-signed versions, but this hardly addresses the issue and would only prevent a direct certificate attack. Should someone create a rogue CA or break into the chain anywhere up farther in the tree, you’re still SOL.

You can change out your certificates, but you’re certainly not guaranteed any protection from this attack, at least not until the CAs join the rest of the world in laying MD5 to rest.

Vulnerability Footnote

A couple of folks have asked why updating the certificates on customer servers will not help. I didn’t do a good job explaining that piece. It ‘could’ help, but this vulnerability is a little different than our run-of-the-mill varieties, in that the attack doesn’t actually happen on or against YOUR server. An end user is redirected or subverted to a site managed by an attacker, but appears to the end user to be you. In this case, your server(s) is not attacked, your authenticity is. So updating the certificates is not analogous to installing a patch to protect against malicious bots or scanners.

Again, until the problem is fixed throughout the entire certificate tree, fixing a single certificate is like putting a Band-aid on a paper cut finger when someone has slashed open your forearm.

 *Band-Aid is a registered trademark of Johnson & Johnson Consumer Companies. Thank you.

Links

• Write-up and research explanation in HTML
  http://www.win.tue.nl/hashclash/rogue-ca/ 
• Presentation Slides
  http://www.win.tue.nl/hashclash/rogue-ca/downloads/md5-collisions-1.0.pdf 
• Blog from Alexander Sotirov
  http://www.phreedom.org/research/rogue-ca/

# # #