Thursday, January 8, 2009

The Register's take on the MD5/SSL crack

Under the very appropriate rubric of "As usual, the truth is a little more complicated," The Register picks up on two points I glossed over in my previous post on the MD5/SSL crack. Before I get to them, let me quote myself from a different previous post:
The basic trust issues are clear enough, but the kind of mental ju-jitsu needed to think through all the various counter-measures and counter-counter-measures is hairy in the extreme. True black belts are relatively rare, and I'm not one of them.
Caveat lector.

Point 1.
Recall that crackable root certificates are in the process of being replaced. In particular, Verisign subsidiary RapidSSL has replaced its tainted root certificate. The register counters:
But there's nothing stopping anyone who might have used the attack before that date to masquerade as RapidSSL and issue counterfeit certificates for any website of their choosing (think Bank of America, HMRC, or any other sensitive online destination).
My understanding here is that there is just such a thing, namely that modern browsers don't rely on a fixed set of trusted root certificates. So, our enterprising cracker puts up a site spoofing my bank, using a bogus certificate, signed by an imposter of RapidSSL's root certificate:
  • My browser makes an HTTPS connection to my bank. As part of the SSL handshake, it asks the purported bank "Who are you?".
  • The site responds "I'm FooBank. Says right here on this certificate."
  • The browser takes the certificate and examines it. The certificate says it's signed by RapidSSL's old root certificate (or it says it's signed by some other certificate that's been signed by RapidSSL's etc., etc.).
  • Without the knowledge that the old RapidSSL root cert has been spoofed, my browser would say "RapidSSL root cert XYZ? Looks OK to me. Go ahead and serve me."
  • With the new information, the browser says "RapidSSL root cert XYZ? Don't know about that one. Sorry." My browser does of course know about RapidSSL root cert NewImprovedXYZ, but that's not the root certificate the cracker is claiming signed the site's certificate saying it's FooBank. Same CA (RapidSSL) but a different certificate.
Microsoft's advisory on the subject states that "When visited, Web sites that use Extended Validation (EV) certificates show a green address bar in most modern browsers. These certificates are always signed using SHA-1 and as such are not affected by this newly reported research."

Firefox doesn't use a green bar, and Mozilla's own advisory on the subject (dated December 30 2008 and linking to Microsoft's) is a bit vague, but (without checking the code and getting further bogged down in details) it looks like Firefox has a couple of safeguards in place as well. It would be nice if they had a more definitive security statement, but the upshot is this: It is possible for browsers to reject certificates signed by fishy root certificates and only accept ones signed by root certs that use stronger hashing (e.g, SHA1) than MD5.

Further, the lead researcher in question, Alexander Sotirov, states, in the blog post I previously linked to
Only 5 hours after our presentation, Verisign stopped using MD5 for all new RapidSSL certificates, successfully eliminating this vulnerability [emphasis mine].
So it would appear that it's enough to revoke the offending root certificates, of which there are a known quantity, and the rest of the system will behave appropriately.

Point 2: The article also brings up a broader and more troubling concern:
More generally, what [Verisign product marketing VP Tim] Callan seems to gloss over is the truism VeriSign and the rest of the security community have repeated so many times that it's become a cliche: Hacking is no longer the province of script kiddies[*], but rather sophisticated and well-funded criminal enterprises. It's hard to imagine these groups wouldn't spend huge amounts of money to buy the credentials that would allow them to spoof any website in the world.
The particular concern driving this is that maybe someone else has already quietly duplicated the Sotirov team's substantial effort and has bogus certificates ready to go, or they're about to do so. That may be but, thanks to the recent efforts, the window for using them is rapidly closing. There's no particular evidence that someone beat the White Hats to the punch on this one. You would expect a massive spike in phishing attacks, and that hasn't happened. So far, at least.

As far as I can tell, no one is currently assuming that no Bad Guys have the resources to crack MD5 and forge root certificates. Sotirov's team tipped off everyone they could as soon as they had the goods (albeit carefully and indirectly in the case of the CAs). The CAs in turn appear to be acting with all deliberate speed to plug the holes. They are not currently assuming that they have a lot of time to act.

The more worrisome problem is that MD5 has been known to be vulnerable, and better alternatives have been available, for some time, but only now are the CAs actually ditching MD5. This indeed was based on the notion that it was highly unlikely that Bad Guys would be able to put the theoretical weakness of MD5 to practical use. More precisely, it was based on the calculation that the likelihood times the cost of a crack was more than [I meant "less than"] the cost of fixing the root certs. Now that Sotirov et. al. have published, the likelihood has increased and the cost of not acting along with it.

What if the CAs had been wrong? What if the Black Hats had won the race? In that case, there would likely have been a huge mess. Major banks would have been spoofed and potentially large numbers of customer accounts compromised before the banks took down their sites and breathed heavy fire at the CAs, who in turn scrambled to revoke the bad certs. The bank sites would then be down for however long it took for the CAs to fix their certs, plus however long it took for the CAs to convince the banks that, no, really, it's all safe now. Banking by phone and at, um, actual banks would continue. I'm reasonably sure that credit card transactions at stores would either not be affected or would be easier to fix since they don't use the public internet.

Parallel to that, the banks would have been scrambling to refund customers their fraudulent charges, reset the magic numbers on every account in sight and convince the customers that no, really, it's all safe now. The browser vendors, who appear already to have done what they could have, would face a similar PR nightmare anyway.

A huge mess, but I wouldn't quite call it "betting the internet". Nonetheless, I can't quite shake the nagging feeling that, one of these days, someone is going to bet wrong, or make a rational bet but still lose. That doesn't seem to have been that case this time, but who knows what comes next?

[*] I can't help including my reflexive grumble here: Hacking was never the province of script kiddies. The two are about as far apart as you can get and still have a computer involved. But I'm using "hacking" in its older sense here.

3 comments:

Allen L. Kelly said...

Great article!

David Hull said...

Thanks, and sorry for the slow reply. As you may have noticed, I did end up chastising your employer, but I also specifically let them off the hook. So I suppose that's either even-handed or wishy-washy. Take your pick.

David Hull said...

Doesn't the part about banks assume their cert chains included at least one weak (i.e., MD5) link?