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

Re:Security is relative

[ushering05401]

On a related note... Humans are still the weakest link in any network.

While it is interesting to read about insecurities in wireless it always bears to mention that even many well configured wired networks are easily compromised through the human component.

I always think of this when reading about new network vulnerabilities: http://www.schneier.com/blog/archives/2006/02/proof_that_empl.html

Problem with wireless

[TheLink]

Current wireless solutions in practice don't have something like https usage.

Where "anonymous" users can securely communicate with servers (that can be validated - if the users actually care).

If you have a WiFi network secured using a naive shared key method, anyone with the shared key can decipher the access of the other users. This might be fine in your house, but not good in some public cafe.

Seems the way around this with current WiFi technology is to let every user use an account - username and password.
Apparently in this case even if users share the same username and password, using WPA2 or whatever (I can't be bothered to keep accurate tabs on below par crap ;) ) they can't decrypt each others sessions. Not sure if this is 100% true given the track record ;).

Assuming it's true, it would be much easier if Windows (and other O/Ses) would default to a standard username and password AND also check the cert of the AP (and issue warnings if it looks dodgy). You should be allowed to log in using a particular user account, or be prompted if the AP rejects the default.

Then people like Starbucks/BK/etc could use certs for their WiFi networks, and customer can have reasonably secured comms at least between themselves and the AP.

The WiFi Alliance should have copied the SSL _concepts_ and got the help of decent security people, rather than coming up with crap year after year (for how many years?).

Obvious wireless security solution

[Anonymous Coward]

I think that all wireless gateways should have an SSL/SSH,etc tunnel built into them. Every time a new computer connects to the network, a new random key would be created for the connection and tunnel all the data.

End of wireless security problem.

Re:Obvious wireless security solution

[igb]

Of course. Hence my point that this is a great deal more complex than the original poster implied, and has a great deal more opportunities for error. The article was essentially about using fuzzers to force restarts of an AP: if I can kill a router stone dead and force a reboot, the standard urandom mechanism will come up using the same saved state as on the previous boot. I like your idea of using reboot times, but the standard code (and if you can point to a consumer AP manufacturer who is doing security research, please let me know so I can buy their products) only saves one set of state and only does it when the init.d scripts run on the way down. Yes, you can re-write the saved seed out of cron, but standard distributions don't. And doing _that_ has the risk that if I can over power the embedded web server and get it to serve files (a reasonable assumption) I can get the current seed. And so on, and so on.

I don't say any of this is impossible. But it's nothing like as straight forward as ``just generate a random key'', and requires careful study of the risks. WEP is a prime example of how this process goes wrong: the idea wasn't totally unsound, but at every stage minor problems crept in until the reality was utterly useless.

ian

Re:Security is relative

[n0-0p]

You're completely ignoring the reality of implementation flaws. Unfortunately, you fit in with the majority of the industry. I suggest you pick up a copy of Mark Dowd's "The Art of Software Security Assessment". It's 1100 pages exploring implementation flaws in real code (from a guy who's cracked everything from OpenSSH to Sendmail and MS Exchange). That's the stuff that programmers need to learn if they want to stop writing swiss cheese code, but instead they just claim that their encryption protocols solve everything. Yeah, secure protocols and design are necessary, but a bad implementation will beat you every time.

The problem with security,,,

[FlyingGuy]

Always has been, and always will be, the users, sorry thats just the way it is.

I was in the military and crypto security is taken, very very very seriously. You fuck up and at minimum you will lose money, lose rank, lose your clearance or if you fucked up really bad you could go to prison.

The problem is in business if the VP of Sales and Marketing can't make his new toy connect to your wireless infrastructure because his new toy doesn't support the same protocols he will start whining and crying that its "too hard" and you can bet your Linux live DVD you are going to be carving out an exception for the fucktard. Then he will start showing off his new toy, and then low and behold more people start buying the same thing and you have a fight on your hands. At this point the fucking CEO has to get involved and make the call and chances are security is going to lose because the VP of Sales & Marketing brings in the $profit$ and you don't regardless of how well thought out your argument is or how logical it is. Then what is going to happen is that your shit will get hacked, and that very same VP or sales and Marketing will hang it around your neck and you will be screwed.

The only way around these kids of problems I think is two fold.

• Device Control. You must have control over the devices that attach to your network. It has to be in hardware. Joe VP wants to bring his laptop in, then the only way he can connect is through a a USB wireless device that the IT department issues, that is burned to his ID AND his hardware and your network that way it will only work if its in HIS laptop, connected to YOUR network using HIS login credentials ( via biometrics ).
• Policy. The adverse consequences for compromising the companies network security must be real, immediate and not left open to compromise. This has to come from the company owner if it is a private company or from the board if it is a public company.

Re:The problem with security,,,

[Cyberax]

In the last company I worked, we had TWO wireless networks. One worked for anyone with only minimal authorization (WEP key pasted on the wall) and it didn't have access to the corporate internal network.

The second one had strong WPA encryption with heavy logging and intrusion control.

Re:The problem with security,,,

[Jimithing DMB]

Where I last worked I set up one wireless network. It was completely open (no encryption at all) and firewalled to limit what you could do with it. You could then fire up the VPN client (the same one you'd use if you were totally offsite like in a hotel) and you'd have access to the internal network.

It really wasn't that hard to set up at all. We needed the VPN for offsite users anyway and so it seemed logical that wireless could simply be treated as if it were any other offsite network. When I set it up, WEP had already been proven mostly broken and WPA didn't exist yet. And what's the difference? Since it's a separate network you can treat it like any other open network. You get no illusion of security. Plus any random joe visiting us could hop right on the network with no trouble at all.

I do a similar thing at home actually. My router has an Atheros-based PCI card in it. I run it in master mode (which is unfortunately still only available when using MadWifi) and give it its own IP space. The firewall rules simply don't allow traffic to/from the wired network and the wireless network. If I need to get to my fileserver I fire up the VPN.

Re:OSS

[Anonymous Coward]

Majority of sold wireless devices (especially 802.11 base stations) already run with open source code. So the problem is not with proprietary software. In fact the problem might stem from companies wanting to save on software development costs and relying on "open source quality". It's expensive to have fuzzing tools and people running them in a coordinated manner.

Re:Security is relative

[Omnifarious]

You're completely ignoring the reality of implementation flaws.

I'm not. If you read again you'll see that I cite them as the reason why various implementations of cryptographic algorithms and protocols we know are well tested and secure fail in the field.

That book sounds really excellent though and I will have to check it out. I'm all for increasing my (and everybody else's) knowledge of how to avoid those sorts of flaws.

Re:Security is relative

[MikeBabcock]

Really now? Feel free to tell me how a 'skilled' hacker cracks a properly established IPSec tunnel using AES256 and pre-arranged 2048bit public keys.

I'm still waiting.