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.
Disagree: This vulnerability is closed
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
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
> 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
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?
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
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
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
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
There's a false assumption here
- 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
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
http://www.phreedom.org/blog/2009/verisign-and-responsible-disclosure/
This vulnerability is closed