A Look at the State of Wireless Security

An anonymous reader brings us a whitepaper from Codenomicon which discusses the state and future of wireless security. They examine Bluetooth and Wi-Fi, and also take a preliminary look at WiMAX. The results are almost universally dismal; vulnerabilities were found in 90% of the tested devices[PDF]. The paper also looks at methods for vendors to preemptively block some types of threats. Quoting: "Despite boasts of hardened security measures, security researchers and black-hat hackers keep humiliating vendors. Security assessment of software by source code auditing is expensive and laborious. There are only a few methods for security analysis without access to the source code, and they are usually limited in scope. This may be one reason why many major software vendors have been stuck randomly fixing vulnerabilities that have been found and providing countless patches to their clients to keep the systems protected."

Comments

OSS

[Anonymous Coward]

What we need is a strong, coordinated, open-source effort to create new standards for networking devices, rather than rely totally on proprietary software.

Re:Security is relative

[Marcion]

If you meet a skilled hacker, no matter what you throw at him/her they will be able to beat it. However most security holes aren't a huge deal because as long as there isn't a .exe that Joe Script-Kiddy can execute its not going to be exploited.

You are missing the vital link here.

1. Skilled Cracker will find your security hole.
2. Skilled Cracker will then brag about it on a forum and provide example code.
3. Not-so-skilled cracker-wanabee will fill it out and package it as a .exe
4. Joe Script-Kiddy executes the .exe

On the Web, this cycle does not take very long. Imagine 1+2 happens on Friday, by the time you come back to work on Monday your server is being accessed.

This is both onerous and a company fishing 4 work

[postbigbang]

If you RTFA, you'll see that there are lots of wireless holes. It's a constant battle to keep things patched-- when the vendors elect to issue one. It's also a company that's done a lot of work, and is now looking for more work to do. It reminds me a bit of Symantec's Macintosh threat PR.

This doesn't excuse the rotten wireless security we have today, it nonetheless doesn't provide models for improvements or other advice or recommendations on how security can be improved.

Re:Wireless security is perfect.....

[The Mighty Buzzard]

On the up side, if we're talking a wireless setup with the weak signal most home setups have, anyone attempting to crack it is also within physical ass-kicking distance. Minimalist security, a fair IDS, and a lead pipe are all you need unless we're talking something with a larger coverage than most WAPs.

Conflict of interest

[lsw]

vulnerabilities were found in 90% of the tested devices
.... said the vendor that sells testing software......hooray for independent research

Re:Obvious wireless security solution

[igb]

I love it when hands are waved with this degree of enthusiasm. If only it were that easy. Let look at the problems your ``end of wireless security problem'' has to solve.

• You need to prevent a `man in the middle' attack, in which I bring up a rogue base station in the area and have everyone bind to me. Your solution doesn't provide even for a shared secret which I expect the base station to know, so there's nothing to stop this from working. So we're going to need something which a base station can use to prove that it's my base station. What? Certificates? Shared Secrets? All the problems we already have, in fact.
• The fine article is mostly about implementation problems, not protocol problems. Both SSH and SSL have been prey to plenty of implementation problems which allow suitably crafted clients to crash, hijack and otherwise mess with servers. You've got all those problems.
• And most catastrophically, generating `random keys' in small embedded devices is really, really hard. Getting hold of enough entropy is a small SME router to produce strong keys on a regular basis is difficult. Making sure that initialisation vectors are suitable chosen is hard.

Here's a thought experiment for all `simple' solutions. Imagine I have a router in my lab, the same model as the one I'm attacking. I capture the packets the supplicant sends to initiate an association, and I play them into my captive router. I have the clock on the captive router set an appropriate distance behind the clock of the router I am attacking, and the MAC address set the same and ideally the serial number (they're usually helpfully printed on the outside). What magic is it that makes the key my captive router generates be something other than the key the router I'm attacking generates?

ian