ie8 fix
madison

Zero Day

Ryan Naraine, Emil Protalinski and Dancho Danchev

An easy fix ignored

By | December 30, 2008, 3:07pm PST

Summary: Guest post by Chris Eng In the wake of this morning’s 25C3 presentation by Alex Sotirov and Jacob Appelbaum, most of the coverage I’ve read so far has focused on the technical details and real-world impact of their findings. Rightly so — their paper describing the attack is a fascinating read filled with enough gory details [...]

Guest post by Chris Eng

An easy fix ignoredIn the wake of this morning’s 25C3 presentation by Alex Sotirov and Jacob Appelbaum, most of the coverage I’ve read so far has focused on the technical details and real-world impact of their findings. Rightly so — their paper describing the attack is a fascinating read filled with enough gory details to make any security practitioner salivate.

To summarize, the crux of the attack was the fact that certain certificate authorities (CAs) still use the MD5 algorithm to sign SSL certificates. The researchers exploited this implementation by harnessing some existing academic research on MD5 chosen-prefix collisions and sprinkling in a few additional tricks.

The most frustrating part of this whole debacle is that it should have never happened.

Like any widely-used cipher, MD5 has been scoured for weaknesses by crypt-analysts since its introduction in 1991. The first significant cracks in the surface appeared at the CRYPTO 2004 conference in August 2004, when Xiaoyun Wang presented a paper entitled Collisions for Hash Functions that described a method for producing MD5 collisions.

[ SEE: SSL broken! Hackers create rogue CA certificate using MD5 collisions ]

History has shown repeatedly that cryptanalysis is an evolutionary process. Each subsequent compromise builds on top of prior work, and each new attack is more practical than the last. The Wang presentation should have been a wake-up call that the clock was ticking on MD5. But, aside from the security community, nobody paid much attention.

At the time, I was employed as a security consultant for @stake, and I can remember revising all of our deliverable templates to remove any mention of MD5 from our best practices or boilerplate text. Even some of my own colleagues were split on whether that was necessary, since the attack didn’t have any practical implications yet. I agreed that we had no reason to act like the sky was falling, but it would only be a matter of time until a practical attack would be discovered. As such, our customers should be advised, at the very least, to eradicate MD5 from their code going forward.

But people tend to be lazy. The typical enterprise mindset can best be summarized as “if it can’t hurt me today, stop bothering me,” and that probably won’t change anytime soon. For an enterprise application, the risk is bounded. If you choose to use a weak hash algorithm in your custom web application, you only hurt yourself and your customers. Apparently, that is a risk people are willing to take, even though switching hash algorithms is a fairly trivial code modification.

A few years later, right on cue, Marc Stevens released a master’s thesis entitled On Collisions in MD5 (.pdf), detailing a chosen-prefix attack against MD5. This was a significant breakthrough and one crucial step closer to the practical, real-world attack revealed today in Berlin.

It’s an absolute travesty that the CAs failed to act not only on the Wang research, but on every other MD5 attack that has materialized since. Any organization who is in the business of selling trust should take all possible measures to be trustworthy, and the CAs failed miserably in that regard.

* Chris Eng is senior director of security research at Veracode.  He is currently removing root CAs from his web browser.

Kick off your day with ZDNet's daily e-mail newsletter. It's the freshest tech news and opinion, served hot. Get it.

Topics

Ryan Naraine is a journalist and social media enthusiast specializing in Internet and computer security issues.

Disclosure

Ryan Naraine

The most important disclosure is of my employment with Kaspersky Lab as a member of the global research and analysis team. Kaspersky Lab is a global company specializing in anti-malware and secure content management technologies. I do not own stocks or other investments in any technology company.

Biography

Ryan Naraine

Ryan Naraine is a journalist and social media enthusiast specializing in Internet and computer security issues. He is currently security evangelist at Kaspersky Lab, an anti-malware company with operations around the globe. He is taking a leadership role in developing the company's online community initiative around secure content management technologies.

Prior to joining Kaspersky Lab, Ryan was Editor-at-Large/Security at eWEEK, leading the magazine's and Web site's coverage of Internet and computer security issues and managing the popular SecurityWatch blog, covering the daily threats, vulnerabilities and IT security technologies. He also covered IT security, hacker attacks and secure content management topics for Jupiter Media's internetnetnews.com.

Ryan can be reached at naraine SHIFT 2 gmail.com. For daily updates on Ryan's activities, follow him on Twitter.

9
Comments

Join the conversation!

Just In

RE: An easy fix ignored
lovedong 13th Sep
Thanks for the wonderful article 3! replica hermes bags
0 Votes
+ -
Who identified these CA's as being trustworthy in the first place? No one. They are self-appointed holders of our trust.

This was the major criticism of the certificate process in the first place, and the fact that they continue to use a weak encryption method is confirmation that the criticism has merit.

We must be watchful of the CA's, and pressure them to not only "appear" trustworthy, but to actually "be" trustworthy. In the long run, being trustworthy is probably cheaper for the CA's anyways.
0 Votes
+ -
RE: An easy fix ignored
lovedong 13th Sep
Thanks for the wonderful article 3! replica hermes bags
0 Votes
+ -
Indeed, Chris.
Narr vi 30th Dec 2008
Thank you for stating the case so directly and
eloquently.

2004 is four years...

Let's hope the CA's will re-issue their certificates
immediately, to be picked up in January browser
updates.

Regards,
Narr vi
0 Votes
+ -
RE: An easy fix ignored
Gropi Updated - 31st Dec 2008
I just want to understand the practical implications of this right now.
Do I need to remove all root-CAs with MD5 as a hashing function?
The two online banking sites I do use authenticate themselves through a VeriSign-Certificate that is signed with MD2. What about this one?

Or is it only important if theses CAs continue to sign certificates that they issue with MDx?

Which CAs refrain from such a practice? Why is there nothing on their websites about this? I mean, they just had the worst thing happen and I hear nothing from them.

Edit: Not on the front page, but still something, at least https://blogs.verisign.com/ssl-blog/2008/12/on_md5_vulnerabilities_and_mit.php
0 Votes
+ -
What are the alternatives?
jayanth78 31st Dec 2008
Given that some of these trustworthy CA's have not been so, but what are the alternatives? Its not like ordinary people are going to check their SSL certificates and CA's in their browsers. And if removing these CA's from chain of trust means interruption to business then people might not be willing to do it.

We need the coordinated action from browser makers and CA's to put a workaround ASAP, and eventually switch their hash algorithams. Don't assume people will act on any o this proactively.
0 Votes
+ -
Act proactively??
twaynesdomain 31st Dec 2008
You have an excellent point that should be drawing a LOT of "Well of course, and along those lines we ... ". But being proactive is nothing that fits the paragigm of any of today's companies, I don't think. It's just so much easier to be re-active than pro-active; let someone else do it and if I'm still alove by then I'll follow suit. I know of VERY FEW companies, departments, teams, groups or even people who give proactivity anythign but lip service and a buzz-word to pull out when it might pull some free PR. Try using that word around some of the decision makers and watch the initial blank stares! They ain't the pause that refreshes! It's especially vacant from a lot of R&D & Advanced R&D departments! Hell, they can't make a program work the first several iterations, how can they be expected to be proactive?
---
0 Votes
+ -
RE: An easy fix ignored
Greg.Higgins@... 31st Dec 2008
It's simple really. The browser makers need to stop accepting or installing MD5 based certificates. In the mean time, those of us who are aware can remove MD5 based certificates from our browsers. When we visit sites that offer insecure certificates, we can contact the site, explain why we're not doing business with them, explain the trust issues, etc. It won't be long before the certificates are out of circulation.
0 Votes
+ -
RE: An easy fix ignored
chriseng 31st Dec 2008
Exactly -- the problem with asking "what can be done by the average consumer? is that there is very little people really can do, without a major disruption to their daily activities. Sure, they can remove the six root CAs mentioned in the presentation that use MD5, but they?ll be unable to browse the majority of the sites they rely on every day, without adding certificate exceptions in every case. And if you?re blindly adding exceptions, you might as well be accepting everything, because you still have no idea whether or not you?ve connected to the real endpoint or not. Until those CAs have reissued all their certs and companies have installed them (not likely to happen anytime soon) it?s unrealistic to ask people to stop trusting those CAs. Convenience trumps security for the vast majority of the population.

The CAs should immediately plug their holes -- replacing MD5 with SHA-1 or SHA-2, replacing the sequential serial numbers (seriously, how embarrassing is that), instituting a random delay in the automated certificate generation process. Incidentally, all of those things would have been called out in a routine security design review by any security consultant worth their salt, had RapidSSL commissioned one.

The vulnerable CAs should also conduct an in-depth analysis of all the MD5 certificates they have issued, in an attempt to detect whether anybody else has quietly carried out the same exploit in the past. Section 7 of the Sotirov, et al. paper provides some suggestions on the types of anomalies to look for.

What I really hoped to get at with this article was to reiterate how important it is to be proactive rather than reactive about security, especially when it's something that requires such minimal effort.
0 Votes
+ -
RE: An easy fix ignored
birumut Updated - 4th May 2011
Great!!! thanks for sharing this information to us!
seslisohbet seslichat

Join the conversation!

Formatting +
BB Codes - Note: HTML is not supported in forums
  • [b] Bold [/b]
  • [i] Italic [/i]
  • [u] Underline [/u]
  • [s] Strikethrough [/s]
  • [q] "Quote" [/q]
  • [ol][*] 1. Ordered List [/ol]
  • [ul][*] · Unordered List [/ul]
  • [pre] Preformat [/pre]
  • [quote] "Blockquote" [/quote]
ie8 fix
Click Here
ie8 fix

The best of ZDNet, delivered

ZDNet Newsletters

Get the best of ZDNet delivered straight to your inbox

Facebook Activity

White Papers, Webcasts, & Resources
ie8 fix
ie8 fix