BreakingPoint Labs

Attacking Critical Internet Infrastructure

Update: The presentation went off without a hitch and the full paper describing the attack, including proof is now available.

Taking a page from L0pht Heavy Industries, Alexander Sotirov, Jacob Appelbaum, and a team of researchers whose identities have to remain secret for now are making the theoretical possible this Tuesday at the 25th Chaos Communication Congress in Berlin. The details of their presentation have been heavily censored leading up the event, with only a handful of security researchers, journalists, and collaborators given early access to the materials. Fortunately, I was one of them, and I wanted to take the opportunity to talk about their research, why it is important, and why the pre-conference secrecy is justified.

First things first; the reason for secrecy. Their research combined a known weakness in one area with a massive resource investment in another to show that a third party was vulnerable to a practical attack that affects the security of all Internet users. Security researchers often release code and technical documentation to demonstrate a flaw, but in this case, they went a step further and used the attack in the real world to obtain proof that it works. This process required interaction with a third party that will likely do whatever they can to save face once the details become public.

To prepare for the fallout, Alexander and Jacob have been working with a legal team to review their work and advise them on the best way to disclose the issue without finding themselves at the receiving end of a lawsuit. From my own conversations with Alexander, I don't believe they broke any laws, but in the past few years there have been multiple unjustified legal actions and threats against researchers who have tried to warn the public about serious security issues.

The last ten years have shown us that it is usually better to ask for forgiveness than permission when it comes to vulnerability disclosure. Vendors have a financial interest in protecting their reputation and this is apparent in the number of pre-disclosure threats they make; however, once the proverbial cat is out of the bag, it is cheaper to address the problem than to proceed with legal action, since that legal action will usually result in even worse publicity for the vendor. If your organization is withholding vulnerability information due to concerns over a legal reaction from the affected vendor, then you have already lost the game and are doing a disservice to every user that relies on that vendor's product or service.

Switching back to the actual presentation; there are three things that make their research impressive. First, their work involved serious collaboration between academia and independent security researchers. This type of coordination is tough to manage and nearly impossible to actually publish anything under terms everyone can agree to. Jacob's previous work on cold-boot memory attacks faced similar challenges and the end result was partial disclosure of the developed tools (the BitLocker code was never released). Second, their research required massive computational resources that had to be utilized within a specific window of time. Although computing costs have dropped significantly over the last few years, the researchers estimated that commercially available computation resources such as Amazon EC2 put the technique within the grasp of a profitable criminal organization, large botnet operator and certainly state sponsors. The attack only has to be performed once in order to reap rewards for a long time afterward (months, if not years). This one-time investment model could pay for itself many times over if it was used to provide services to criminal organizations. Finally, they actually did it. This isn't a pie-in-the-sky talk about what may happen or what someone might be able to do, this is a demonstration of what they actually did with the results to prove it.

Their live presentation will be available online via streaming video, it is scheduled for Saal 1 at 3:15pm (8:15am CST, 9:15am EST, 6:15am PST) on Tuesday, December 30th. Keep an eye on the schedule in case their timeslot is moved.

13 comments
Tags:

This vulnerability is closed

Posted by Tim Callan at 2008-12-30 14:57
Tim Callan here, Vice President of Product Marketing for VeriSign. As mentioned in this post, the researchers did not choose to share the detals of their attack with us, so we had to learn the specifics at the same time as everyone else. Nonetheless, the attack has been rendered ineffective against any SSL Certificate from VeriSign on RapidSSL or any other brand. More information is available on my blog at https://blogs.verisign.com/ssl-blog/2008/12/on_md5_vulnerabilities_and_mit.php.

Disagree: This vulnerability is closed

Posted by HD Moore at 2008-12-30 15:37
Hi Tim,

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?

We're investigating

Posted by Tim Callan at 2008-12-30 19:35
HD,

We're looking into the question, trying to find what would be a consistent marker. If we find one, we'll apply it to the certificate base just as we did to find the weak Debian keys. That's the easy scenario. Let's discuss the scenario where no such marker exists. It is a grave and monumental responsibility to revoke a business's certificate, especially in the circumstances where that business did nothing wrong. It's tantamount to shutting down the Web site, and the economic hardship of so doing can be significant, up to and including the death of the business. Not an idea to be taken lightly. At the same time I can appreciate the danger of the rogue CA. At the end of the day it comes down to risk/reward scenarios, just as it does in all security matters. What do we consider the likelihood that this scenario happened? We have a team of top researchers working on this task a long time with non-trivial funding. Sure, it's within the means of a large criminal organization to do the same thing, but isn't a whole lot easier to just grow your botnet? In a world where you can still send out spam with the subject line "Your account has been frozen" or "Discount Cialis" and take people's money, how likely do we think that these gangs have chosen to investigate this possibility? If the answer is "infinitessimally low," then it would be cavalier to damage all these honest businesses.

I'm not saying I have all of the answers. After all, I've been living with this information for less than a day (a long day, granted). But these are the questions we'll have to think about as we work through this matter.

-tlc

Versign and Debian keys

Posted by Juergen Schmidt at 2008-12-31 07:13
Tim Callan wrote:

> We're looking into the question, trying to find what would be a consistent marker.
> If we find one, we'll apply it to the certificate base just as we did to find the weak Debian keys.

This is really a quite revealing statement if you take into account that even now -- more than half a year later -- there are still weak debian keys signed by Versign out there being used for sensitive transactions.

bye, ju

Debian keys also being managed out

Posted by Tim Callan at 2008-12-31 12:59
If you want to talk about Debian keys, it's the same story here. VeriSign has a comprehensive management process by which we work with the sites to get the weak Debian certs removed from the infrastructure while not arbitrarily shutting down someone's business at a critical moment. This process is well under way and we're confident with the progress being made. As I've written elsewhere, the ability to revoke a certificate is a weighty responsibility and we take that action very, very seriously. This process is well under way, and we chose to start at the points of highest risk, which are closed down. Just as I've written in a response further down this page, doing so is a complex, multi-stage process that has to be executed correctly and in sequence in order to have the desired effect.

I'm sneaking out of a family obligation to have this dialog, so I don't have the time to write a whole treatise on VeriSign's Debian response. I'll try to get one up on my blog soon, and when I manage to do so, I'll come back here and let you guys know.

-tlc

Except that it isn't?

Posted by Jacob Appelbaum at 2008-12-30 17:11
Hi Tim!

We asked Microsoft to talk to Verisign under specific constraints. You said that you weren't told about this before the public presentation and that is false. Verisign was informed directly by Microsoft.

What more did you need to know other than not using MD5 four years after it was broken? And one year after attacks on X.509 with MD5 signatures was demonstrated?

In addition, Verisign was specifically informed that this was real and presently under intense research.

In addition, you're still issuing certificates with MD5, right?

How is this closed? How isn't that just some marketing spin?

Serial number generation

Posted by Kris C at 2008-12-31 06:40
Hi Tim,

Thanks for participating in the discussion. My concern which I feel is as equally valid as the ceasing of MD5 sum usage, is the serial number generation process, and I've not heard much from the CAs on this. Will something be done so that certificate signing uses a non-sequential number generator? Preferably a more advanced PRNG?
Thanks in advance!

Serial number generation

Posted by Edward Vielmetti at 2009-01-02 10:02
The point about serial number generation is a key one (and a real one). This attack would have been much harder if sequence numbers had not been guessable.

Sequence number attacks go back at least as far as R.T. Morris, "A Weakness in the 4.2BSD UNIX TCP/IP Software", CSTR 117, 1985, AT&T Bell Laboratories, Murray Hill, NJ, as referenced in RFC 1948 in 1996.


Similarly there was a timing attack (the 'six second delay') that some future more secure system would seek to skew to add some more bits of randomness to the mix.

I beg to differ

Posted by Cappella at 2008-12-30 20:29
Hi Tim,

We have seen your response in Wired and in Verisign's blog. What I want to say has mostly been covered by HD and Jacob, but I want to add one important point.

From risk management point of view, you cannot claim that there are 0 certificates affected out there. It is not a matter how many certificates are affected, it is how many fake certificates that can be generated with this rogue CA certificate, and coupled with the DNS vulnerability attacks, it can seriously impact a localised network (think COMPANIES).

As what I usually tells people in detecting malware, you don't see any malware on your systems does not mean that there is no malware on your systems, it just mean you did not see it, that's all. Same thing, there is no known attacks out there does not mean the exploit is not out there, it is just what the researchers had explained, they had not seen it in the wild, but that does not mean it has not happened. So here is my challenge to you: Prove that there is no exploit out there.

Your statement in Wired "All the information that we have is that MD5 is not any kind of significant or meaningful risk today" is seriously misleading, if not outright irresponsible. Granted that you just know the research results today, I suggest that you digest the whole research again before you make that comment. Bottomline is this: MD5 is weak, it should be replaced, and continuous use of it introduces risks. It has been shown consistently over the last 10 years that when a theoretical cryptography break is possible, a real-world practical example will follow. Think WEP and WPA. Honestly, I expect Verisign to do better than this with a team of world class researchers.

We hope that the vendor sends a responsible and clear message that this finding could have an impact, and encourages customers to quickly switch to EV certificates ASAP. All the things you said on Wired and Verisign's blog, frankly speaking, is just spreading a false sense of security to the common folks out there.

Theoretical proof should be enough

Posted by Joff at 2008-12-31 06:40
Theoretical proof/knowledge of MD5 collision should be enough to take action. The presentation today was an excellent demonstration of a practical implementation. The researcher's showed that with enough time and resources, MD5 collisions can be exploited. It is understandable that the challenge to move CA certs away from MD5 signing is a difficult problem but it must be addressed.

There's a false assumption here

Posted by Tim Callan at 2008-12-31 12:46
A lot of the dialog around this discussion makes the false assumption that we aren't and haven't been phasing MD5 out. In fact we have been. Think about the timelines on this one. VeriSign acquired GeoTrust in September, 2006. That was the very inception of our relationship with the RapidSSL product line, our first opportunity to begin to learn the technology and platforms and customers. In case some of us on this dialog haven't been through the process of absorbing a large, established business, a whole lot of learning needs to take place. It's more than just the single technology question we're focused no today. There are literally thousands of equivalently important questions, most of which have answers that are not obvious. You're learning a group of people, a culture, nomenclature. You're digging into practices and physical security and authentication standards and process controls and audits. Even the metrics that both companies use can turn out to mean different things when you drill down on how they're actually measured. It's kind of like if you moved to a new country where they spoke a language you never had heard before and your assignment were to learn the local cuisine and write a cookbook. Before you can even get around to working on the cookbook, you have to learn how to speak to people, and where the food markets are, and what people consider to be a delicacy and what they don't. Similarly, the day we take over this business we need to evaluate:

- Internal technology platforms
- Partner technology platforms
- Customer applications
- Customer usage and attitudes
- All the practices and policies surrounding the business

And you're doing so across dozens of product lines and thousands of partnerrs and hundreds of thousands of established customer relationships.

This process identifies a series of items that need addressing. Perhaps they were deemed acceptable to the previous company but not to the new one. Perhaps the new company is going to put emphasis on a product line or customer base or application that the old company did not. Perhaps it was something that the old company was going to embark on anyway. Once you've built this list, you put together a prioritized migration strategy and execute on it. That's what we've been doing since the acquisition, and we're soon to be complete with our MD5 phase-out, which has been in the works for a long time. MD5 is only one specific component of a broad range of standards, policies,and technology platforms that needed some kind of work. We don't get into the details of all that with outsiders, but we've made radical positive changes to this set of product lines since they came under VeriSign's umbrella, one of which is the one we're discussing right now.

Moving past SHA-1

Posted by Dustin D. Trammell at 2009-01-15 13:28
As a leader in your industry, I sincerely hope that you intend to champion moving past SHA-1, and doing it as quickly as possible. Nearly everything I've seen regarding the proposed solutions to this attack have involved migration to SHA-1. SHA-1 is scheduled to be decertified by NIST in 2010, and NIST has already recommended moving away from SHA-1 to SHA-2 (256, 512, etc.). Collision attacks have already been demonstrated against SHA-1 back in 2005, and if history (and this recent incident) tells us anything then things will only get worse for SHA-1 from here. By not moving directly to at least SHA-2 (until the winner of the NIST hash competition is known), these vendors are likely setting themselves up for similar attacks in the (relatively) near future.

Unfortunately not many certificate validation systems such as OpenSSL, major browsers, etc., are currently able to validate SHA-2 certs by default. OpenSSL systems, for example, must call OpenSSL_add_all_algorithms() before they will validate SHA-2 certs because SHA-2 isn't supported by default. Verisign needs to be pushing (and potentially assisting) the certificate validators toward more secure hash algorithms, and then beginning the migration away from SHA-1, because SHA-1 is in the same boat MD5 was 4-8 years ago.

Disclosure timeline released

Posted by HD Moore at 2009-01-07 07:49
Alex has posted a complete disclosure timeline to his blog:

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

Videos

More >


Interact





LinkedIn

YouTube

Newsletter


Subscribe to BreakingPoint Labs blog by email:

Type in your email, hit submit and quickly verify your address.


Subscribe to our RSS feed