Slashdot Mirror
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."
...in some kind of tube that we could install between the source and the destination.
What we need is a strong, coordinated, open-source effort to create new standards for networking devices, rather than rely totally on proprietary software.
do you got some of these skilled hackers ? i have a large semiprime to factor
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.
.exe .exe
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
4. Joe Script-Kiddy executes the
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.
My little Linux and tech blog
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
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.
---- Teach Peace. It's Cheaper Than War.
Lack of security in wireless isn't that huge of a deal. If you meet a skilled hacker, no matter what you throw at him/her they will be able to beat it.
Bzzzt! Wrong! I really hope you aren't a programmer.
There are encryption algorithms and protocols that are so good that nobody has figured how to defeat them, most likely even including the secret labs of various governments. Mostly what happens is that in practice they are misapplied or the person applying them doesn't understand them well enough and cuts a corner that results in a fatal implementation flaw.
What I really don't get is public standards that have this problem.
Those facile assumptions of yours as well as the pervasive defeatist attitude are likely the main reason there are so many problems in various commercial products.
Need a Python, C++, Unix, Linux develop
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.
Violence is like duct tape. If it doesn't solve the problem, you didn't use enough.
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.
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.
Hey KID! Yeah you, get the fuck off my lawn!
- 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