Video Screencast Help
Website Security Solutions

This morning's MD5 attack - resolved

Created: 30 Dec 2008 • Updated: 18 Dec 2012 • 30 comments
Tim Callan's picture
0 0 Votes
Login to vote

Earlier today at the Chaos Communication Congress in Berlin, three researchers presented a paper in which they had used an MD5 collision attack and substantial computing firepower to create a false SSL Certificate using the RapidSSL brand of certificates. The live presentation should be available for download as well.

I'm happy to announce that this attack articulated this morning has been rendered ineffective for all SSL Certificates available from VeriSign.

We applaud security research of this sort and are glad that white hats like the "MD5 Collision Inc." group make a point of investigating online security. This group went to great lengths to keep its findings private, and unfortunately that included ensuring that VeriSign did not receive any of this information ahead of the actual presentation, rendering it impossible for us to begin work on mitigating this issue prior to this morning. So I'll caution you that these responses are preliminary, and if it turns out that any of the information we've received is inaccurate, my responses may change. Fortunately, VeriSign has already removed this vulnerability. Here are some likely questions and their responses based on what we know as of this morning.

Q: Is the information in the paper and presentation accurate?
A: As mentioned, we only receive this information this morning. Our preliminary view doesn't reveal any inaccuracies in the information presented.

Q: How will VeriSign mitigate this problem?
A: VeriSign has removed this vulnerability. As of shortly before this posting, the attack laid out this morning in Berlin cannot be successful against any RapidSSL certificate nor any other SSL Certificate that VeriSign sells under any brand.

Q: Does that mean VeriSign has discontinued use of MD5?
A: We have been in the process of phasing out the MD5 hashing algorithm for a long time now. MD5 is not in use in most VeriSign certificates for most applications, and until this morning our roadmap had us discontinuing the last use of MD5 in our customers' certificates before the end of January, 2009. Today's presentation showed how to combine MD5 collision attacks with some other clever bits of hacking to create a false certificate. We have discontinued using MD5 when we issue RapidSSL certificates, and we've confirmed that all other SSL Certificates we sell are not vulnerable to this attack. We'll continue on our path to discontinue MD5 in all end entity certificates by the end of January, 2009.

Q: Is Internet security broken?
A: Hardly. The presenters of this morning's paper stressed that it took them a long time and a great deal of computational power to succeed in their collision attack. VeriSign has already eliminated the attack as a possibility.

Q: How many certificates are affected?
A: Zero. No end entity certificates are affected by this attack. The attack, when it worked, was a potential method for a criminal to create a new, false certificate from scratch. Existing certificates are not targets for this attack.

Q: What happens to customers who have certificates in place using the MD5 hashing algorithm?
A: Today's research revealed a potential attack that required the issuance of new certificates. Existing end entity certificates are not at risk from this attack. Nonetheless, any customer who would like to do so can replace any MD5-hashed certificate free of charge. Until further notice VeriSign is suspending its normal replacement fees for these certificates. Because this replacement is not necessary to ensure the continued security of sites, we are not requiring the replacement of such certificates, as we have previously with the likes of weak Debian keys.

Q: The researchers stated that Extended Validation SSL is a defense against this problem. Is that true?
A: Yes. The Extended Validation SSL Certificate standards prohibit the use of MD5. So no EV certificate in compliance with the standards uses MD5. I can tell you factually that no EV SSL Certificate on the VeriSign, thawte, or GeoTrust brands uses MD5.

Q: These researchers have discussed their desire to maintain secrecy so that the hammer of legal action couldn't be used to prevent publication. Does VeriSign intend to sue these researchers?
A: Security researchers who behave ethically have no reason to fear legal action from VeriSign. Since its inception VeriSign has been one of the world's leading forces for online security, and the company has consistently used its resources and expertise to assist online security's progress. In fact, VeriSign is itself a white-hat security research firm (through our widely respected iDefense Labs), and we understand the concept of "ethical hacking." We're disappointed that these researchers did not share their results with us earlier, but we're happy to report that we have completely mitigated this attack.

Comments 30 CommentsJump to latest comment

Concerned Citizen's picture

Tim, this seems a bit dismissive. This issue has existed and been exploitable for years, during which somebody may have requested a valid cert that allowed them to create an evil CA. Is Verisign doing anything to check old CSRs for signs of collision attacks?

+1
Login to vote
anonymous's picture

You write that the researchers "ensured that Verisign did not receive any of this information ahead of the presentation". Be honest, now: Is that really a full and accurate description of what really happened? Are you claiming that the researchers did not approach Verisign at all? Or are you saying that the researchers approached Verisign with the information but Verisign was unwilling to agree to the conditions that the researchers requested that Verisign abide by? Somehow I can't help but suspect that it's the latter...

+3
Login to vote
anonymous's picture

You write that the researchers "ensured that Verisign did not receive any of this information ahead of the presentation". Be honest, now: Is that really a full and accurate description of what really happened? Are you claiming that the researchers did not approach Verisign at all? Or are you saying that the researchers approached Verisign with the information but Verisign was unwilling to agree to the conditions that the researchers requested that Verisign abide by? Somehow I can't help but suspect that it's the latter...

+2
Login to vote
HD Moore's picture

Thanks for the response! Glad to hear that the RapidSSL no longer uses MD5 for signing. One thing that your blog post does not address is whether the attack used by the researchers has already been carried out. Prior to the switch to SHA1 today, someone could have abused this flaw to generate a CA certificate that would be valid for many years. It seems like the only way to be sure would be actually revoke ALL MD5-signed certificates or the top-level certificate itself. I understand this would be costly and impact all of your RapidSSL customers, but what other assurance does the public have that there is not a rogue CA certificate floating around?

-2
Login to vote
Dominic White's picture

Great response! Although, while existing issued certs aren't affected, there is potential of using them to collide with another rouge CA cert afaik. Thus there is risk to the PKI but not the certs, which is potentially worse.

0
Login to vote
Zviratko's picture

great if true.

However, isn't there one bit missing to the puzzle - disabling MD5 algorithm in all client SSL libraries for certificate validation as well? How can a browser tell that CA doesn't issue MD5 signed certs? Maybe I'm just confused but it looks to me that any CA can be faked with ~$50K hw and some effort.

+1
Login to vote
Jordan's picture

For those that are interested, it looks like this is the location for requesting a replacement:

https://products.geotrust.com/geocenter/reissuance...

If a forum post solves your problem please flag is as the solution

-1
Login to vote
Paul van Brouwershaven's picture

It looks like the VeriSign "Class 3 Public Primary Certification Authority" is signed with a
md2WithRSAEncryption which is also insecure.

This root is also used for signing the EV root, check: www.verisign.com

You can check this at:
http://www.networking4all.com/en/support/tools/site+check/

-1
Login to vote
sumdood's picture

Q: What happens to customers who have certificates in place using the MD5 hashing algorithm?
A: Today's research revealed a potential attack that required the issuance of new certificates. Existing end entity certificates are not at risk from this attack.

Are you sure about this? While the actual existing MD5 cert itself may not be vulnerable to being spoofed, it is the CA validation that is spoofed on a rogue website, as a result if a user visits this rogue site, they will not know the difference between the legitimate and rogue site. Yes the existing legit site is still secured, but at that point the user is now redirected to the rogue site, so saying that existing certs are unaffected is true but the overall security of the transaction is still compromised.

+2
Login to vote
Scott Nelson's picture

The root certificate for Thawte Premium Server CA uses MD5 -- doesn't that make things signed by that certificate vulnerable because they can forge that certificate?

+3
Login to vote
NoInfo's picture

What does "in all end entity certificates" mean ? Does this mean that Verisign will continue to use MD5 that is known to b weak/broken for over a year in intermediate or CA certificates ?

-2
Login to vote
Alexander Sotirov's picture

I am one of the researchers who presented this work at the CCC congress yesterday.

We did in fact notify Verisign and all other affected certificate authorities through a trusted intermediary a week before the presentation. Verisign was made aware that we've made improvements to the MD5 collision attack published in 2007 and that they need to stop using MD5 as soon as possible.

In addition, we feel that the MD5 collision results from 2004-2007 served as a sufficient warning to any CA still using MD5.

Your assertion that "that VeriSign did not receive any of this information ahead of the actual presentation, rendering it impossible for us to begin work on mitigating this issue prior to this morning" is false and I'd like to see it corrected.

Alexander Sotirov

+4
Login to vote
Jan Minář's picture

The post goes to great lengths to explain that the SSL system has been fixed, in an expedient manner, kudos to VeriSign. If it only were so!

The SSL system remains broken as long as there is at least one Certification Authority still issuing MD5-signed certificates. The researchers mention at least one other CA other than RapidSSL that still uses MD5.

Even after all the CA's that currently still issue MD5-signed certificates cease to do so, previously obtained rogue certificates can still be used. Rogue CA's set up using these certificates will still be able to issue new rogue certificates. The litmus test is quite trivial: as long as the proof of concept rogue CA created by the researchers is operational, the SSL system has not been fixed (barring workarounds that specifically target their particular rogue certificate).

-4
Login to vote
Tib's picture

The attack is mitigated unless it has already been exploited before RapidSSL stopped using MD5 for issuing certificates. How can you tell whether organised crime (or governmental services, or anybody else) has already used this exploit to get a certificate with CA rights from RapidSSL between the time it was known that the attack was theoretically possible and the time the research team mounted the attack?
In order to fully mitigate the attack, it is at least necessary to modify SSL implementations to refuse any certificate with CA rights, certified by RapidSSL, or use a white-list to allow those already delivered with their exact footprint, and apart from that only allow server certificates certified by RapidSSL (this does not protect against rogue server certificates, though).

-4
Login to vote
Mitchell's picture

I was very surprised when I first read the paper talking about this. While there is an ongoing discussion about full-disclosure, it seems responsible to at least give the vendors some heads-up.

+2
Login to vote
Pul S.'s picture

Does this effect Radius servers at all?

+3
Login to vote
Ryan Upton's picture

Greetings Tim,

The CCC's demonstration leveraged a collision attack where a valid CSR was supplied and it's twin was actually used- that twin being an intermediary CA certificate able to sign any number of certificates for any purpose.

This VeriSign response addresses only one of the issues exploited by CCC to make this attack possible (the signing of MD5 CSRs). The others, to summarize are; one- a failure in process to randomize portions of the certificate (serial number at least), two- an automated registration and validation process, the third they describe is an unchecked chain length in signatures.

Will VeriSign address these other process issues in your several CAs?

Also, In the CCC scenario, it seems that a similar attack should it already have occurred would still leave a viable Intermediary CA cert today, and so still be a risk. Have Verisign considered or identified any means to review CSRs already signed for signs of this or similar attack(s)? I am aware that the cryptographic attack described by CCC is advertised as undetectable, but you may also have logs for CSR processing and signatures, or other metadata which could infer such attack traffic (in addition to cryptographic analysis of the attack on MD5 and identification by that means).

-RSU
Ryan S. Upton, CISSP

-3
Login to vote
Premila Melvin's picture

Does your replacement strategy apply to the exisitng md2 hashed verisign certificates too?

-2
Login to vote
Allen Kelly's picture

Lots of feedback here on this posting, and it may take me a while to work through all of them. I'll keep plugging at it. In response to this comment: Yes Ryan, you're correct that there are other methods of defending against this attack than solely the removal of the MD5 algorithm. Migrating to SHA-1 was the fastest and safest response since we were expecting to do so anyway and simply had to accelerate a deployment into our freeze period. We do agree with the suggestion to introduce factors into our serialization and issuance time to make them less predictable, and we're working on them as well.

With regard to your second question, yes we're investigating whether or not there is any method of detecting previous versions of this attack in the past. Should such a detector be possible, we will implement it in the most effective manner available.

-4
Login to vote
Allen Kelly's picture

Alexander,

Here are the facts as I understand them.
- The "trusted intermediary" was under a strict NDA with you and didn't feel it could reveal anything that was actually actionable or useful. Your NDA prevented the intermediary from telling us what would be announced, by whom, or when.
- You didn't invite us to view the presentation in person or on the webcast. Had VeriSign not discovered by other means that this presentation was coming, we may not have had the opportunity to hear what you had to say until after the fact.
- In addition to Microsoft and Mozilla, at a bare minimum you briefed The Washington Post, Wired Magazine, CNET, and IDG News Service prior to your announcement. You also briefed one or more active security bloggers. Based on the reports from these people, it appears that you obtained promises from them not to share with us either.
- You stood on stage in front of a room full of people and explained that you had actively sought to prevent us from finding out. You had a slide thanking the lawyers who helped you prevent us from finding out.
- VeriSign acquired the RapidSSL product line as part of its acquisition of GeoTrust in September of 2006. That's when we began our process of learning the code base and transitioning various technology decisions that had been made by the previous ownership, including moving off MD5. Therefore it gives an inaccurate impression to discuss 2004 as the starting date for mitigation of this vulnerability.
- VeriSign has a long history of treating ethical security researchers well and encouraging research of this sort. We've been public in our congratulation of the good work you did finding this flaw, and we took immediate action. Had we been briefed ahead of time, the flaw would have been inactive by the time you revealed it to the world.

It seems there's an interesting and productive conversation brewing in the press about disclosure methods and what's appropriate. I'll rely on that dialog to explore those issues. For that dialog to be productive, we should be clear on the facts in this case. The facts above are those I'm aware of. I don't know how to interpret that as briefing VeriSign. If you took other actions to make sure we knew about this flaw, they never made it to me. Feel free to explain what else you did to inform VeriSign, as I'd certainly like to give credit where it is due.

-tlc

+1
Login to vote
Allen Kelly's picture

Premila,

VeriSign no longer issues MD2 certificates. The existing certificates in the field will age out as they expire. That's the good thing about certificates. The attack as detailed in Berlin has no applicability to these certificates since we're not issuing new ones.

-tlc

0
Login to vote
Allen Kelly's picture

I don't see how servers would be relevant to this issue. That's because it's not an attack against an existing site or certificate. It's an attack that uses a newly issued certificate to create other false certificates.

-tlc

-2
Login to vote
anonymous's picture

Tim, you stated that the intermediary was not able to reveal anything that was "actually actionable or useful".

That seems directly contradicted by the emails released by the researchers, which show that Verisign received a recommendation to stop using MD5 and migrate to SHA-1:

http://www.phreedom.org/blog/2009/verisign-and-res...

It seems to me that a recommendation to stop using MD5 and to migrate to SHA-1 is both actionable and useful. It is useful, because simply taking that step alone is enough to stop their specific attack. It is actionable, because the recommendation is specific enough that it can be immediately implemented (as Verisign indeed did do).

It appears that your characterization is simply demonstrably false. How do you respond to this?

+2
Login to vote
NoName's picture

Tim,

You stated that "the team went to great lengths" to "ensur[e] that VeriSign did not receive any of this information ahead of the actual presentation".

However, now that the researchers have published their communications with the intermediary they used to inform Verisign, it seems clear that this is inaccurate:

http://www.phreedom.org/blog/2009/verisign-and-res...

Those emails indicate that Verisign did receive key information about the vulnerability and how to mitigate it, and so it is not accurate to say that Verisign did not receive "any" information. In fact, it would appear that VeriSign received significant information, enough to address the flaw.

Tim, you also stated that this "render[ed] it impossible for us to begin work on mitigating this issue prior to this morning". However the emails published by the researcher makes clear that VeriSign did receive enough information to begin work on mitigating this issue. VeriSign received a disclosure on Dec 23 that a vulnerability in MD5 allowed forging certificates, and encouragement to migrate from MD5 to SHA-1. To my thinking, that is enough to begin work on addressing the issue. Moreover, from the emails released by the researchers, we see a statement on Dec 29 from Jay Schiavo at VeriSign that "We are working on making system changes to stop using MD5.", so not only was it possible to begin work on addressing the issue before CCC, VeriSign in fact did so. This directly contradicts your Dec 30th statement that it was "impossible" to begin work on addressing this vulnerability. How do you account for this?

-2
Login to vote
Robert David Graham's picture

According to Alexander's post, you were notified of "successful generation of colliding x509 certificates signed by real certificate authorities which still use MD5" and "that RapidSSL and FreeSSL (also owned by Geotrust) use MD5 and are vulnerable to this attack".

This seems complete to me. What more information would you have needed?

-3
Login to vote
Gregory's picture

If the method engineered by the researchers has already been discovered and used by hackers, than any organizations currently utilizing a certificate within their chain (be it the root, an intermediate, or a leaf), could potentially be the victim of a man-in-the-middle attack. Because we have no way of knowing whether or not this is the case, organizations should consider mitigating risk by replacing certificates using the MD5 hash function.

Given this condition, more needs to be don. http://tiny.cc/ns4b8

+1
Login to vote
Allen Kelly's picture

One question I've received a few times is whether or not there's a way to know if someone engaged in this attack prior to the CCC presenters. Our cryptoanalysts believe that there may be consistent artifacts from a collision attack like this one that we could use to build a "collision detector." Such a detector would allow us to search the historic certificate base for candidates of such a collision in the past. The effectiveness of this detector is enhanced if we do not reveal how it would work, and therefore I won't be offering any detail on this subject. Should we find anything that we public needs to know about, we'll tell you. Otherwise you can count on the fact that we're using everything we can create to the fullest extent possible.

A related question I've been hearing is how likely it is that such a collision happened prior to this announcement. While axiomatically it's impossible to prove a negative, it appears unlikely that such an attack took place prior to this one. Therefore the intersection of ability and motivation is extremely low.

Start with ability. This team consisted of seven world-class researchers and cryptographers assembled from around the world. These cutting-edge thinkers dedicated considerable time to the problem without any promise that it would yield results. In addition to successfully pulling off an MD5 collision attack - no mean feat in itself - they combined it with some other clever sleuthing to assemble the complete attack they needed. It's unlikely that an equally qualified cryptographic team is available to work on a project like this one in an underground setting. This team was also well funded. Their bank of 200 PS3s is costly enough to put this attack out of reach for all the script kiddies in the world. Only a resource rich organization such as an online criminal gang would have had the ability to pull off this attack.

Certainly such organizations exist in the world, but that's where motivation comes in. The criminal gangs are looking for different prizes than professional security researchers are. Online criminal gangs make money by stealing personally identifiable information, taking over accounts, or building botnets. Highly successful and well understood methods already exist to accomplish these ends. Phishing and malware continue to run amok and continue to offer good returns. Spear phishing is on the rise. DDoS extortion is an obvious and lucrative use of an available botnet. Where is the motivation for a criminal gang to head down an obscure line of investigation when other such fruitful avenues are available? It isn't there.

Professional security researchers are another matter. These are people who have chosen as a vocation to expand the boundaries of our collective understanding. There is no value for them to write papers and give presentations about by-the-book attacks like phishing and malware. Their purpose is to explore new avenues, even if the criminals are best off focusing on the tried-and-true classics. So it makes all the sense in the world that professional security researchers would explore an attack like this one long before organized crime would.

-3
Login to vote
James Brady's picture

Tim,

You provide an eloquent explanation of the basic reasons we shouldn't consider a rogue CA other than the POC existing very likely.

How many bits of security would you ascribe to that unlikeliness?

These sound like handwaving excuses that serve to make a serious, ongoing breach in security seem like no real problem. Except it is, in a completely unacceptable fashion for a company whose image is predicated on two words: Trust and Security.

-4
Login to vote
Arkadaslik Sitesi's picture

im, you stated that the intermediary was not able to reveal anything that was "actually actionable or useful".

That seems directly contradicted by the emails released by the researchers, which show that Verisign received a recommendation to stop using MD5 and migrate to SHA-1:

Tanks.

+1
Login to vote