Layer 8

Why the MD5 cert hack doesn’t matter.

(Donning my asbestos undies in preparation for any possible flamage that may result ...)

The blogosphere is all a-twitter (heh) about the presentation today by Sotirov, Stevens, Applebaum et al., showing how a less-than-likely combination of clever steps can create a man-in-the-middle opportunity to insert rogue signed certificates from a “trusted” CA. Thierry Zoller’s great summary is here; Rich Mogull has the most reasoned “Don’t Panic” explanation of it here.

What I’m here to say is, I don’t really think this matters all that much except to security researchers. Here’s why: normal users’ trust has very little to do with certificates.

I remember seeing Bruce Schneier speak at some conference (it might have been TRISC), and mention as an aside that the wi-fi service being offered at the conference used some authentication that included an expired certificate. He noted wryly that plenty of security folks were using the service anyway—even security folks tend to click through a cert warning when they believe, rightly or wrongly, that the risk is low.

And let’s talk about the vast, vast, VAST majority of intertube users out there, the ones who don’t understand this stuff anyway. Let’s talk about your mom and my mom, or your boss and my boss. There are two kinds of users here: the ones who don’t understand and are deathly afraid of their computers, and the ones who don’t understand and aren’t troubled by it.

The ones who are afraid of their computers tend to panic whenever they get a pop-up anyway. You have to talk them through reading the certificate warning, loading an exception, or whatever, and eventually you just end up saying, “Mom, just click Continue, it’s okay.” They will hold their breath, close their eyes, and click whatever they need to in order to make the pop-up go away so that they can get to their oldie radio station or Jane Austen fan site or whatever.

The ones who are NOT afraid will click Continue without reading further, because they’re annoyed by any kind of pop-up and don’t want to take the time to figure out whether it’s really a problem. They don’t want their computer telling them what to do; they want to tell IT what to do, and what they want to do is get to their brokerage site, or their fantasy football, or whatever. (Yes, have you noticed the raging stereotypes in here? I raised ‘em myself from tiny hatchlings.)

My point is, these folks would still be susceptible to phishing even without the MITM component. I really don’t see an appreciable increase in risk here, even if you suddenly find all of China and the RBN hitting the magic combo that these researchers did. The ONLY place where I would see this making a difference is in host-to-host communication, where an application that suddenly gets a cert error will just die instead of saying, “Aw, the hell with it,” and clicking through. Someone will have to go troubleshoot the application and figure out why the SSL is failing, and then they’ll catch it. In that case, a MITM attack will go undetected because it won’t raise an error.

People everywhere are hyperventilating and saying OH NOES, NOW I CAN’T TRUST ANYTHING ON TEH INTERNET!!! To which I say, dude, you’re already choosing what to trust and what not to trust, and it’s based on a whole bunch of other factors that have little to do with certs. Certificates were a nice idea, but they were a security dweeb’s answer to trust, not a businessman’s answer to trust. They’re already too far under the covers to be understandable or useful to anyone outside of a small IT subset.

We need to move on to a better, business-oriented trust model anyway. This is just another crack in a wall that wasn’t all that great to begin with.

Posted by shrdlu on Tuesday, December 30, 2008
(5) Comments • Permalink •

Next entry: From the other side of the hiring desk ...

Previous entry: A meaningful degree of FAIL.

Comments

.(JavaScript must be enabled to view this email address)

on 12/30 at 04:21 PM:

Stop hating that’s like saying 0days don’t matter because granny never updates anyways. Every vulnerability matters and should be addressed properly. I am sure that you would recognize something was amiss if you started receiving certificate errors, it would be a clear indication that someone was trying to orchestrate a MITM attack against you and you would react accordingly.

Another other problem is that many times just because someone is the first person to report a vulnerability, that does not mean that they are the first to have discovered it.

This post also sounds comparative to saying that an XSS vulnerability doesn’t matter because a much worse SQL injection vulnerability is present. Which would also be wrong as they are both vulnerabilities and both would need to be addressed. Just because one problem exists doesn’t mean that another doesn’t matter.

LonerVamp

on 12/31 at 04:03 PM:

RE: Anonymous:

I understand where you come from, but this *should* change nothing for the average consumer (or normal user).

1) They can’t do anything about it. The “do something” part of this weakness is on the shoulders of the CAs and PKI in general.

2) Their behavior shouldn’t change. They shouldn’t be doing sensitive things over open/untrusted networks anyway.

3) This is still computationally prohibitive, as the researchers acknowledge. Could someone have done this already? Sure, but the chances are slim. Now, if just one single rogue CA root gets out, the game changes quite dramatically until browsers get updated and those bad certs that depend on it get flushed out.

shrdlu

on 12/31 at 05:00 PM:

Anonymous, what you’re missing is a sense of proportionality (aka risk analysis). Yes, it’s a vulnerability, but does it effectively raise our risk in a significant way? I’m arguing not (and so is Schneier, btw).

LonerVamp, what you said, except that another key to most attacks will be getting someone to follow a link to the fake site with the rogue cert—which people already know how to do. There *might* be an appreciable increase in nexus MITM attacks (say, if you’re spoofing a wi-fi portal), but given the difficulty of the attack, I wouldn’t expect it to be accomplished very much before they clean this up. Generally, you’re going to have to drive the traffic to your site in order for them to be fooled by the cert, and that’s the biggest part of the attack. The lack of a warning pop-up is, as far as I’m concerned, just icing on the cake.

Security researchers tend to get too hot and bothered over very elegant, very obscure hacks that don’t translate into clear and present danger in the real world. Protesting “but it’s a VULNERABILITY!” doesn’t help your case in front of a CIO who wants to know whether he should be shutting down the T1 right now.

This is where FAIR does such a good job in injecting common sense into the evaluation of a vulnerability. How much work is it going to take to exploit the vulnerability? How much knowledge does it take on the part of the attacker? How often is an attacker even going to get a chance to try it? How likely are you to be targeted by such an attack? What can the attacker get out of using the exploit? What mitigating controls do you have in place?

I’m not a hater; I think it’s an impressive and elegant hack. I just don’t think it (or many other 0days) deserve equal amounts of PH3AR and loathing until you’ve analyzed the actual risk beyond the theory.

.(JavaScript must be enabled to view this email address)

on 01/02 at 07:13 PM:

I think even though there is probably a low probability of this vulnerability being exploited in a big way, it’s not a vulnerability that should be ignored. The problem is that this isn’t like every other phishing hack out there. You can always tell you’re being phished with previous attacks. Looking at the bad cert or the fake URL or whatever else. I understand the average user (the parents example always works) will not understand these things, but thr problem now is that even if they do, they won’t be able to tell. All manner of other attacks or compromise attacks are fairly easily detected. “Don’t open email with subject blah blah mom” or “Don’t click any links from places you know you don’t do business with dad”. What do you tell people now? On the topic of the computationally prohibitive nature of this vulnerability. These guys spent a few months and 18 hours on a Playstation cluster and came up with the exploit. Do you really think some large multi-national criminal enterprise doesn’t have those kind of resources? When 10s or 100s of millions of dollars are being made every year on identity theft and the like, that kind of thinking is naive at best and outright dangerous at worst.

on 01/04 at 10:33 PM:

@plaidhat—There’s a difference between ignoring a vulnerability and prioritizing it appropriately in light of the myriad other issues we face, the inevitable limited budget we have to work with, and the effect on our credibility every time we raise red flags over relatively low probability issues (shrdlu’s CIO observation). Shrdlu’s post simply articulates the reasons she believes this particular vulnerability is a low priority. Bottom line—if the practical effect of the vulnerability in terms of an increased frequency of compromise (how often people are duped) isn’t significant, or the magnitude of loss on a per compromise basis (which this issue shouldn’t affect), then its overall practical significance is minimal.