Hole 196: Lessons Learned

I'm going wrap this up for now - but I'm not dismissing this whole affair any time soon, and neither should you.

OK, it's time to put this issue to bed, at least for now. But as I alluded in my initial missive on this topic, I've been continuing to think and investigate, and there are a couple of lessons here that need to be preserved.

First, I think it's wise never to underestimate the impact of any IT (or, heck, any other) security problem. Some have pointed out that there appears to be nothing new here - man in the middle/ARP cache poisoning/etc. has all been done before. So what? This particular attack has not been seen before, although, in retrospect, I'm not sure why, leading to the conclusion that it may have been successfully prosecuted in the field. There was, then, something to be learned here. And while I discovered that the client-isolation features of some enterprise-class WLAN infrastructure systems could indeed mitigate this attack (perhaps turning it into more of a cheap DoS exercise), these are proprietary solutions. So, IMHO, the standard should be amended, and the Wi-Fi Alliance really should take a leadership role when issues like this arise. The Alliance needs to stay at the forefront of all things Wi-Fi; no security issue is too small. In fact, I think they should establish a formal procedure for security issue reporting, and continue to encourage all suppliers of Wi-Fi gear to join for the good of the industry overall. Please, guys and girls, don't let this opportunity slip away.

I also spoke with Meru Networks, who informed me that their Wi-Fi virtualization capabilities include the generation of unique BSSID for each client. Hence, they should be immune to this kind of attack.

And, finally, I think it's wrong, given the lack of standard reporting mechanism, to come down hard on AirTight for how they brought this issue to light. We live in a competitive economic environment, and there was advantage to be gained here. OK, a short-lived advantage that not everyone seems willing to grant, but it's better that they brought this information forth, even in the form it took. Slack should therefore be cut.

The big bottom line: security isn't about what we know, it's about what we don't know. Dismissal of any security and integrity issue is potentially disastrous, as in "no way the shuttle's solid rocket booster will fail just because it's cold outside - light that candle!" Arrogance is just as bad as aggressive marketing. There are times that chances just shouldn't be taken, and even challenges dismissed as "existing" need further consideration. For example: much of the US military's command and control system is wireless. These guys have the firepower to ruin the day of just about everyone on the planet. You must know that there are people who sit up, night after night, building models of what might go wrong with security here - and no problem is deemed too small to ignore. Most enterprise networks, if you think about it, are equally mission-critical. In healthcare applications, for example, people could in fact quite literally die if security mistakes are made.

One final thought: Hole 196 requires an authenticated and thus trusted insider to work. What are the chances, many have asked? To those I would ask if they've every heard of social engineering. A successful attack here would require a little research and a good sales job - skills that many professional information thieves, I'm sure, possess. And what about possible variants on Hole 196, some possibly system-specific, that have yet to be explored?

Done? Only for now, and only on this particular topic. But on security overall - no, never, not even on a little network like mine.

• Wireless / Mobile
• AirTight Networks
• arrogance
• Hole 196
• Meru Networks
• wireless security