Radioactive

Thomas Ptacek | February 21st, 2006 | Filed Under: Defenses

I have a theory about avoiding speeding tickets. It’s simple and it’s easy to test and it’s worked reliably for me over the last 5 years. I used to get a lot of tickets, so pay attention:

Pull over before the lights come on.

You’re doing 85 down I-90 at 10:00PM. Blow past an underpass and see headlights pulling on to the road behind you. What you do now is, pull over. Before the blinky lights come on. Turn off your engine, turn the dome lights on, roll down the window, put your hands on the wheel.

You will now play out one of four scenarios:

1. It’s not actually a cop. You have no problem.
2. It’s a cop, but he keeps going. You have no problem.
3. It’s a cop, and he pulls over behind you. He walks up to your window and asks, “why did you pull over?”. You respond, “I saw you pull out behind me and realized I was going way too fast. I’m sorry.” He goes back to his car for the requisite 10 minutes, comes back, and says “I’m letting you off with a warning, but slow down!”. You have no problem.
4. It’s a cop, she pulls over, you do everything outlined in scenario 3, and you get a ticket anyways. This has never happened to me. Scenario 3 has happened to me a lot. But even if I did get a ticket, I wouldn’t have a hard time convincing myself that I was getting that ticket no matter what I did.

My explanation for this is that cars on the road obey the same laws as dogs do in the wild: when two dogs fight, and one loses, he rolls over and shows his belly and the dominance hierarchy is established and everyone goes away happy, or at least, breathing. And that’s the same thing you’re doing with a police officer by paying attention and pulling over before she has a chance to pull you over.

I do have a point.

Several months ago Matasano published some initial results testing iSCSI SAN technology. We got an advisory out with Network Appliance, but haven’t published much since. We have not been sitting on our hands. Matasano is currently averaging over 4 months from disclosure to public advisory: we don’t publish without vendor coordination. To put it in perspective: we had stuff queued up when the first iSCSI advisory came out. And NetApp iSCSI is the only advisory we’ve published so far!

Since then, in addition to testing iSCSI, we’ve had a chance to take a whack at iFCP. iFCP is one of the two Fiber Channel equivalents to iSCSI (the other is FCIP, and if you know why there are two of these, you know more than I do about SAN tech). One sentence refresher: SAN protocols like iFCP and iSCSI let your OS pretend to have a physical block-based disk drive attached, when really the disk commands are being proxied over the network.

iFCP was not much fun. Here’s why: from what we saw, against a market leading vendor, iFCP has basically no “built-in” security. Instead, iFCP wants to be run on a backchannel network, or through an IPSEC tunnel. In the environment we tested, there was no iFCP login for us to defeat. We could fuzz Fiber Channel commands or the iFCP framing, but, what’s the point? I could be wrong —- our iFCP engagement did not take place under conditions as favorable as our iSCSI work —- but access to iFCP seems like gameover.

It’s hard for me to argue that this is a bad thing. The lack of superficial (or worse, complicated) security mechanisms forces operators to confront the fact that SAN security requires network architecture support. And as a pentester in this engagement, I have an idea of how the cop might feel when I pull over preemptively —- she could write the ticket, but what’s the point? It won’t make her feel any better.

Some protocols and network services are just radioactive. Rationalizing their exposure to arbitrary network clients or attempting to mitigate vulnerabilities with countermeasures like “strong authentication” is playing to lose. The SAN protocols are an example. So are routing protocols. So is SNMP. Labeling individual vulnerabilities in these protocols without recognizing that they are fundamentally scary is like labeling a container full of plutonium with its atomic number, weight, density, and boiling point, but not having the big yellow “radioactive” pictogram on it.

So one of the things I liked about RSA was meeting Peter Lindstrom, and one of the things I’ve been meaning to discuss with Lindstrom is his industry request for a “materials safety data sheet” for software. And, what I think is, he’s right (and the comments about that stupid “Software Facts” label are a straw man response).

But we’re getting ahead of ourselves. In particular: both the MSDS and the “Software Facts” label try to be predictive of vulnerabilities. But I’ll argue that, at least to start with, my clients don’t need to be able to predict vulnerabilities, and any labeling practice is going to fail at that anyways. We need to know which protocols are radioactive and which ones are going to combust. And I think there’s a better metaphor to play on than either the MSDS or (gag) food labeling.

Here’s my SWAG.