Slashdot Log In
A Look at the State of Wireless Security
Posted by
Soulskill
on Sun Feb 17, 2008 01:30 PM
from the tubes-of-the-ether dept.
from the tubes-of-the-ether dept.
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."
Related Stories
Submission: Wireless Security: Past, Present and Future by Anonymous Coward
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Wireless security is perfect..... (Score:3, Insightful)
IS that what this is saying?
Re:Wireless security is perfect..... (Score:5, Insightful)
Parent
Re: (Score:3, Insightful)
Re: (Score:2)
If only we could contain the wireless signal (Score:5, Funny)
Re: (Score:2, Insightful)
Re: (Score:3, Insightful)
Re: (Score:2)
Re: (Score:2)
I run a 256 bit AES OpenVPN with 2048 bit DSA keys over it. Before that I used to run IPSEC with 3DES of an RC4 PPTP tunnel. Either one works perfectly fine for most stuff you want to be secure. It is not much slower on modern systems either because things like the new Core2 laptops do the wireless crypto in software anyway.
It looks like I am not the only one. I look for a relatively big telecoms company and it ha
Re: (Score:2)
You mean like the Internet? ;-)
OSS (Score:5, Insightful)
Patch and Penetrate is Security through obscurity (Score:3, Insightful)
For most of readers here it will no doubt be obvious, but sadly this is lost on many people who buy software, even those who buy software for large companies.
Re:Patch and Penetrate is Security through obscuri (Score:2)
Not everyone who buys software can read code or understand the hardware which it controls. Not everyone who can do both - or thinks he can - can be trusted to detect every flaw.
Re: (Score:2)
Sure, but that does not affect my point, that often people are pretending that something can be trusted when there is no basis for that trust.
If you can't read code then you have even less basis on which to trust it. Likewise, I am not a lawyer so I have no basis on which to trust the contract with my ISP.
This is both onerous and a company fishing 4 work (Score:5, Insightful)
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:They are pointing to real issue (Score:4, Informative)
This has nothing to do with the classic issue of "wireless security", such as the relative strength of WEP versus WPA or WPA2. Some attack works by sending control frames, i.e. the cleartext packets that are used to establish the wireless connection in the first place, without any security being applied. Other attacks allow a station to abuse its connection privileges -- instead of merely consuming a wireless service, it can take over the whole device.
The same technique was demonstrated by Cache & Maynor with Wi-Fi in the summer of 2006. The lessons were quickly learned on the "client" side of the Wi-Fi networks. For example, the validation tools for Windows wireless drivers now include tests against fuzzing attacks. The technique is well known, and the tool advertsied in the article is just one of many available solutions.
However, the article points to an interesting area, the quality of implementation in "appliances" such as Wi-Fi access points. PC and Mac drivers may be well tested now, but who knows what software is run in the average access point? Also, it is much easier to download a new driver for a PC or a Mac than to update the firmware in an access point. So, we may expect to see some interesting exploits against various appliances...
-- Louarnkoz
Parent
Problem with wireless (Score:4, Interesting)
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
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?).
That pdf is an AD for Codenomicon Defensics (Score:3, Informative)
Not saying wireless security is a not an issue, but the pdf is an ad.
Conflict of interest (Score:3, Insightful)
The problem with security,,, (Score:5, Interesting)
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.
Re: (Score:3, Interesting)
The second one had strong WPA encryption with heavy logging and intrusion control.
Re: (Score:3, Interesting)
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
Re: (Score:2)
It turned out that it's easier to work without active VPN connection using only built-in Windows wireless. Besides, we have some additional security on VPN.
Re: (Score:2)
Not sure what you mean by this. You still obviously use the built-in Windows wireless on the clients, no different from a coffee shop or a hotel and even easier since I didn't have the stupid little initial splash page that most of those have. Then you just run a VPN on top of that. Since the people with laptops had to know how to use the VPN when they were offsite (e.g. hotels, coffee shops, whatever) it was very easy to train them just to think of our wireless network as being offsite.
There was one o
Re: (Score:2)
The outside VPN client required stupid Intel VPN, which is very annoying and not very stable.
Re: (Score:2)
Ha-ha! He said 'biometrics'!
Seriously, you made some good points, but biometrics have nothing to do with real security. Imagine if people were issued random passwords at birth, could never change them, had them tattooed over their bodies, using ink which would leave traces of some of their passwords on anything they touched, and had to give them to a wide variety of companies for 'security'; you'd write that off as crazy... but that's biometrics.
WEP Vulnerability Remains (Score:2, Informative)
wifi protected setup (Score:2)
No one has ever gotten it to work. I don't know why they put it in routers.
I prevents you from actually connecting to an AP.
I guess this is the security. If you can't actually connect to an AP you can't hack it.
My wireless security is fine (Score:3, Funny)
I use WPA. I know it can't be GEt V1AgrA N()W cracked. I made sure this thing was set up GET YOUR p3n!s enlarged NOW!!! as it should be.
Why does nowadays computing stink the way it does? (Score:2)
"Look at the state of wireless security" (Score:2)
*EUGH!!!! MY EYES! MY EYES!*
Jesus! What is WRONG with you!
Re:Security is relative (Score:5, Funny)
do you got some of these skilled hackers ? i have a large semiprime to factor
Parent
Re:Security is relative (Score:4, Funny)
plz send me teh codes. I need them for a schol project. thnx.
do you aslo have teh codes for discrete logs? I need teh codes for that too. plzthnx.
Parent
Re: (Score:2)
If you have never connected to a machine before, how do you know it is the machine that you want? This applies to wireless access points, as much as it does to any other service over the internet. You can force people to get their stuff signed by some trusted root keys, but then it becomes prohibitively expensive for the home users to set up thei
Re: (Score:2)
For example, a hacker won't be able to access the net without being present in the building.
Another way: use hardware authorization tokens which are forbidden to be taken from the building.
Re: (Score:3, Informative)
Get the token at the manufacturing plant that makes the things, or someplace in the supply train. Compromise an individual who has authorized access to the inside of the building.
Tokens are useless until they are initialized. It's possible to compromise individual who has authorized access, but it's much harder. You probably won't be doing it unless you need to steal something VERY important.
Your example with Tony Blair is a bad one - there was no security breach, it was that just low-level security did not know the true situation.
Re:Security is relative (Score:5, Insightful)
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.
Parent
Re:Security is relative (Score:5, Interesting)
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 [schneier.com]
Parent
Re: (Score:2, Insightful)
Re:Security is relative (Score:5, Informative)
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.
Parent
Re:Security is relative (Score:5, Interesting)
Parent
Re: (Score:2, Interesting)
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: (Score:2)
Re: (Score:2)
do you make the assumption that because you're using tough encryption algorithms, your software can't be hacked? is all your software free of unchecked buffers? are all the libraries that you bind to? how's your memory allocation and deallocation? do you encrypt end to end, but store encryption keys in plain text? world readable?
som
Re: (Score:2)
I am not assuming that just because you have good algorithms and are implementing tested protocols that everything will be fine. I'm just saying that assuming that there are no such things and a deplorable lack of security is therefor acceptable is stupid.
It is possible to implement software that has very few or no vulnerabilities. It isn't easy, but it's possible. That it isn't being done is deplorable, not "no big deal".
Anyway, I think if you re-read what I wrote you'll discover you're attacking me f
Re: (Score:3, Interesting)
I'm still waiting.
Re: (Score:3, Insightful)
If you have a wired connection, you don't need wireless.
Ah, but, you say, you just download a big enough file that you won't need to update it.
But my wireless connection is around 5 megabytes per second, so to support that much traffic with a one-time pad, you'd need every pad to be 900 megabytes. For every three minutes you're using the network.
Which is a metric fuck-load of data to have to carry around just in case
Re:Obvious wireless security solution (Score:5, Insightful)
- 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
Parent
Re: (Score:3, Informative)
Re: (Score:3, Interesting)