A Look at the State of Wireless Security 107
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."
Wireless security is perfect..... (Score:3, Insightful)
IS that what this is saying?
Re:Wireless security is perfect..... (Score:5, Insightful)
Re: (Score:3, Insightful)
Directiona antenna (Score:1)
http://www.heise.de/english/newsticker/news/62328 [heise.de]
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
At the present time, you can't have both.
Your choice.
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
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.
Your forgetting possible charges of assault and the difficulty of tracking the MAC ID back to a physical location. You could add breaking and entering to the charge list so you can be sure your beating up the right person...
Re: (Score:1)
Re: (Score:1)
I relayed that wisdom to the frail old lady who lives next door and she laughed while she reloaded her P229.
If only we could contain the wireless signal (Score:5, Funny)
Re: (Score:1)
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:1)
Re: (Score:2)
You mean like the Internet? ;-)
Re: (Score:2)
Re:Security is relative (Score:5, Funny)
do you got some of these skilled hackers ? i have a large semiprime to factor
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.
Re: (Score:1)
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: (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: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.
Re: (Score:2)
I found out recently that my computers have been rooted since at least 3 years ago, and I've found a number of 'methods' paid hackers use to keep systems infected. 1. adding a session to a cd/dvd/bdr that auto installs the root-kit on windows. and 2. scanning broadband bloc
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]
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.
Re:Security is relative (Score:5, Interesting)
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)
Bzzt! Wrong! (Score:1, Insightful)
Bzzt! Wrong! I really hope you aren't a wireless hardware designer.
Encryption algorithms (especially the "unbreakable" algorithms you allude to) take time/computing power to encrypt and decrypt at each end of the wireless link. The level of encryption used is always a practical trade-off between security and transfer rate/hardware complexity.
Re: (Score:1)
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:2)
There have been numerous vulnerabilities in various IPSEC implementations which have been detected by third parties.
No, no you aren't.
Re: (Score:1)
Social hacking is far easier than beating mathematics with brute force.
Re: (Score:2)
In my configurations (and I specified well-configured, did I not?), I install the keys on the VPN gateways and nowhere else. I keep copies of the public keys on backup media, and in case of a system failure, a secondary set of new keys can be installed and used (for which the public keys have already been distributed) but to which the customer has had no prior access.
IPSec VPNs configured at borders
OSS (Score:5, Insightful)
Re: (Score:1, Interesting)
Re: (Score:1)
Standards and software are not the same thing. How would an FOSS implementation of existing standards be insufficient in freeing us from relying totally on proprietary software? How would a new standard guarantee that we won't rely on proprietary software? Are the current standards not implementable in FOSS? What makes new standards different?
If the issue is lack of open-source drivers because there are no ava
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
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?).
Re: (Score:1)
Re: (Score:2)
As for wired security, you can configure decent switches so that clients can only see traffic from a "blessed" server (or network/port) but not each other (not even each other's broadcasts).
The problem as I mentioned is even if _public_ WiFi service providers want to provide better security, it's so _hard_ with the current WiFi technology an
Re: (Score:1)
Re: (Score:2)
I don't expect WiFi to provide VPN. It's just not nice to get broken stuff when it could have been avoided.
Back when WiFi was first starting out the technology was there (SSL was already around, they could have just copied the ideas), but the WiFi bunch gave us crap instead. To compound the problem they kept rolling out broken stuff to fix broken stuff.
Certificates do not hav
Re: (Score:2)
Re: (Score:2)
What ATT does further upstream is between them and you.
What happens at the sites, affects the people running those sites too.
If someone sets up an AP and pretends to be Starbucks, it can create a fair amount of problems, even if it's not Starbucks fault. If it's too much hassle maybe Starbucks might just stop providing WiFi access.
Someone could still jam the network, but such attacks are more detectable.
Re: (Score:2)
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).
Yes they do. It's called Opportunistic Encryption and you can get it for free on Linux (at least on Ubuntu) by just installing "openswan".
That's not implemented at the wireless solution level though. It's done with IPSEC.
If you install openswan on your computer at home and your laptop then you can contact your home computer securely without additional configuration.
Re: (Score:2)
Did you read the "Starbucks" bit? and the "current wireless solutions in practice" bit?
How would Starbucks provide a safer WiFi service for its customers? They most certainly can't tell patrons to install openswan etc.
The last I checked, Google/Yahoo don't support "Opportunistic Encryption", even Slashdot doesn't.
Anyone solely using Opportunistic Encryption obviously lives in a very isolated corner of the Internet compared to everyone
Re: (Score:2)
Anyone solely using Opportunistic Encryption obviously lives in a very isolated corner of the Internet compared to everyone else, if anyone tries to attack their computer/data it'll probably be by accident. There's no significant money to make by targeting such niches.
Don't worry about the money. Just install OE on any public servers and on your computer, and tell other people about it. That's all you can do. That, and try to make openswan OE work with windows OE (which is Kerberos-based, and probably only normally works in an AD environment.)
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.
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
Re: (Score:3, Informative)
Re: (Score:3, Interesting)
Conflict of interest (Score:3, Insightful)
Wireless Security = Oxymoron (Score:1, Flamebait)
Re: (Score:1)
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)
Re: (Score:1)
Re: (Score:1)
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!
802.1x (Score:1)
Uh, so where are the holes coming from? (Score:2)
So, I focused on this quote:
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.
If source code auditing is so expensive, and there are so few ways to analyze these code packages, where are all the holes coming from? Yikes, if external parties can find holes in 90% of the setups out there, imagine what they could do if the stuff was open source!?!
Use SSH. (Score:2)
Laptop with OpenSSH Client --> Horribly insecure wireless protocol --> Router with OpenSSH Server and wired connection.
Set the router to reject/drop wireless connections to everything but the SSH port, same with the laptop, and you're pretty much done for the vast majority of applications. Yes, the encryption slows down your connection, but unless you encrypt the data AT SOME POINT then there is