Monday Dec 22
Dec
30/08
A Layman’s Explanation of the CA Certificate Vulnerability
Updated on Wednesday, 31 December 2008 01:07
Share

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.

  Section 1  Section 2 Section 3 Section 4 Total
Length 2 4 2 3 9
Original 42 2069 52 837 3000
Clone 1 99 1206 52 1643 3000
Clone 2 13 1792 52 1143 3000
Clone 3 86 2204 52 658 3000

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

# # #


25 Comments
  1. CommentsNetwork Security Blog » An Explanation of the CA Cert Vulnerability even I can understand   |  Tuesday, 30 December 2008 at 3:08 pm

    […] you’re like me and don’t have the time to read the entire original article, read “A Layman’s Explanation of the CA Certificate Vulnerability”.  You’ll get the gist of what’s going on without getting too lost in the […]

  2. CommentsBrowser Security Fail, MD5 broken, CA gone rogue « Amrit Williams Blog   |  Tuesday, 30 December 2008 at 5:49 pm

    […] analysis (here), (here), (here), (here), (here), (here), (here), (here) and (here) Possibly related posts: (automatically generated)Dealing with Oracle Certificate […]

  3. CommentsInteresting Information Security Bits for 12/30/2008 at Infosec Ramblings   |  Tuesday, 30 December 2008 at 6:56 pm

    […] usual, JJ helps make a very technical topic quite understandable. Security Uncorked >> A Layman’s Explanation of the CA Certificate Vulnerability Tags: ( exploit ssl md5 cert […]

  4. CommentsSSL Certificates Vulnerable to Attack | Security Watch   |  Tuesday, 30 December 2008 at 7:04 pm

    […] excellent post on his blog as to why we should not panic with regards to this issue, as does the Security Uncorked blog.  The Errata Security Blog also highlights that not all certificates based on MD5 are […]

  5. CommentsMr. Bump   |  Wednesday, 31 December 2008 at 12:00 am

    Kudos…great post! I knew checking your site daily for the last several weeks would pay dividends down the road!!

  6. CommentsBumpInTheWire.com » Blog Archive » Wanted: Information on the SSL certificate vulnerability   |  Wednesday, 31 December 2008 at 12:41 am

    […] Its pert near impossible to go to any nerd site today and not read about it.  My personal favorite was JJ’s.  After a disappearing act for the better part of two months she comes out swinging for the […]

  7. Comments??? ????? ???? ???? ?????? ??? MD5 collisions « OWASP Greek Chapter   |  Wednesday, 31 December 2008 at 7:40 am

    […] ???????????? ??? ??? ??????? ????? ??? ??? ?? ??????? ???????? ?????????? ???, ??? ?? ?????????? ??? ??????????? ??? CCC ?????? ??? ??? ????????? ??? ???????? ??????? ?????? ??? ??????? ??? ??? ????????? ???. ??? ??? ????????????? ??? ????????????? ??????? ????????? ??? ???. […]

  8. CommentsToddH   |  Wednesday, 31 December 2008 at 12:41 pm

    Nice writeup JJ!

  9. Commentsjj   |  Wednesday, 31 December 2008 at 12:50 pm

    LOL I know.. I’ve been slacking ;)
    Thanks for the link!
    -jj

  10. CommentsAa'ed Alqarta   |  Thursday, 01 January 2009 at 8:17 am

    Imagine malware authors and phishers start combining rogue ca certificates and infect users’s systems and redirect them to a “fake bank website with valid certificate” … boom !

    read more …

    http://extremesecurity.blogspot.com/2008/12/kaminskys-dns-bug-rogue-ca-certificates.html

  11. CommentsNetwork Security Blog » Welcome to 2009   |  Friday, 02 January 2009 at 12:14 pm

    […] been taking a bit of a blogging and podcasting holiday, which I only broke to link to JJ’s excellent post on the CA certificate vulnerability.  I’m still vaguely on break until next week, but I thought I’d let everyone know […]

  12. CommentsMrObvious   |  Friday, 02 January 2009 at 3:12 pm

    The reason this is so problematic is that the browsers have MD5 root certs “built-in”, hence creating the implicit trust.

    So…. Why not just delete all the MD5 root certs out of your browser? Problem solved!!

    Or better yet, Microsoft, Firefox, etc. could simply issue an update for the browser to not allow/use MD5 root certs.

    Any CAs that still use MD5 root certs (which should have been replaced by now anyway) simply need to work to get their non-MD5 root certs “installed” into the updated browsers. Microsoft has provided a “root cert update” in the past, so this should not be a big problem.

  13. Commentsjj   |  Friday, 02 January 2009 at 6:52 pm

    MrObvious,
    It’s a little more complicated than that. Because CAs sign their own certs with MD5, we can’t simply ‘turn off MD5′ support in the browsers. For example,they have the EV (extended validation) support in newer IE browsers.

    It’s a process, not a switch.

    There’s more good info on what some browsers are doing in this technet article.. http://blogs.technet.com/swi/archive/2008/12/30/information-regarding-md5-collisions-problem.aspx

    -jj

  14. CommentsMrObvious   |  Saturday, 03 January 2009 at 12:35 am

    Its not really that complex. For example, EV certs can’t use MD5. Whether this is enforced by the CA issuing the certs or the “browser” that processes and validates the certs in the chain and then displays the “EV green bar”, it doesn’t matter. While both should be enforcing this, it is really the “browsers” responsibility to enforce it. The “browsers” can do whatever they want. If they want to enforce non-use of MD5, they can simply not support it. If the “browsers” don’t want to support root certs with MD5, they can simply delete all MD5 root certs from thier distribution and then don’t allow installation of root certs with MD5 signatures, and don’t process/validate MD5 certs the cert chain.

  15. Commentsjj   |  Monday, 05 January 2009 at 11:06 am

    More pingbacks..

    Information Week article by George Hulme..

    http://www.informationweek.com/blog/main/archives/2008/12/the_not_quite_e.html

  16. Commentsjj   |  Monday, 05 January 2009 at 11:08 am

    More pingbacks…

    Information Week Analytics article by Mike Fratto..

    http://www.informationweek.com/blog/main/archives/2008/12/yes_trust_in_th.html

  17. Comments» Good post on the cert MD5 hack   |  Monday, 05 January 2009 at 11:35 am

    […] over at Security Uncorked wrote a great post on the MD5 CA hack.  She called it "A Layman’s Explanation of the CA Certificate […]

  18. Commentsjj   |  Monday, 05 January 2009 at 11:42 am

    Mr. Obvious,
    Right.. and that’s exactly what they’re working towards.. EVs were the first step in that direction..
    -jj

  19. CommentsLinks for January 5, 2009 « Steve Mullen’s Blog   |  Monday, 05 January 2009 at 4:39 pm

    […] Security Uncorked – A Layman’s Explanation of the CA Certificate Vulnerability […]

  20. CommentsMitchell   |  Tuesday, 06 January 2009 at 7:10 am

    Thank you! You wouldn’t believe how much I needed this explanation.

  21. Commentsjj   |  Tuesday, 06 January 2009 at 10:41 am

    Thanks Mitchell!
    Good luck on the blog- I’ll be checking it out…
    -jj

  22. Commentsjj   |  Tuesday, 06 January 2009 at 10:53 am

    More pingbacks..
    Blog post at Techdulla

    http://techdulla.wordpress.com/2009/01/06/ssl-cert-fun/

  23. CommentsForrest   |  Tuesday, 06 January 2009 at 2:03 pm

    Great post JJ!!

    -ff

  24. CommentsBrowser Security Fail, MD5 broken, CA gone rogue | Roy Firestein   |  Saturday, 24 January 2009 at 10:09 pm

    […] analysis (here), (here), (here), (here), (here), (here), (here), (here) and […]

  25. CommentsQ Times » Blog Archive » MD5 insecurity affects all internet users   |  Wednesday, 18 March 2009 at 6:08 am

    […] “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,” Jennifer Jabbusch, CISO and network security specialist at Carolina Advanced Digital, wrote on her personal blog. […]


Leave a Reply