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."
... when you don't do anything that needs to be secure, over it.
IS that what this is saying?
...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.
I agree that any attempts for security by proxy will always have vulnerabilities. If you haven't checked the code yourself, you can never trust it 100%. If no one can check the code but crackers with fuzzing tools, then you can't trust it at all.
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.
My little Linux and tech blog
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.
Current wireless solutions in practice don't have something like https usage.
;) ) they can't decrypt each others sessions. Not sure if this is 100% true given the track record ;).
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?).
Which is a fuzzer. And most of the vulns are DOS and reboots.
Not saying wireless security is a not an issue, but the pdf is an ad.
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
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.
Ironclad Security only exists when you have Chuck Norris on the shift. Do we really have to discuss this? (Plutonite)
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. If people demand more encryption, suppliers will give it to them, but it comes at a cost and no wireless designer is going to put their product at a competitive disadvantage by using encryption that's stronger than what's "good enough" for most users.
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.
"If you are going through hell, keep going." - Winston Churchill
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!
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
Microsoft Excel? I don't even ask that much -- just that Microsoft Works.
...the right of the people to keep and bear arms, shall not be infringed.
"Simply share the onetime pad between the computer and access point over a wired connection"
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 you might want to connect to one particular network for one specific three minute period. I'll let you work out how big it would be if you had to be able to connect at any time during a period of several days.
There ARE ways to beat 'thermorectal cryptoanalysis' (i.e. shoving blowtorch up someone's ass), military have been using it since forever.
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.
Ever heard about "teh directional antenna" stuff?
http://www.heise.de/english/newsticker/news/62328
In fact, it is quite relative. So relative, in fact, that it remains true that anything created by man can in turn be undone. It would be foolish to assume that there exists an end to the war of codes, that being the battle between the encryptors and decryptors.
- 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
What a lot of people may not be realizing as they buy newer WAP and WAP2 protected 802.11g and n gear is that if they leave the ability to connected legacy 802.11b devices, they've left open the WEP vulnerability. Everything has to be upgraded, and that can get too expensive to do at once.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
The fact that I'm piggybacking off of an unprotected wireless network right now might serve your point.
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.
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.
Need a Python, C++, Unix, Linux develop
Point taken. I should have more appropriately phrased it as "I think you're understating the pervasive reality of implementation flaws." Sorry, I tend to jump into this battle swinging because I regularly deal with development teams that think security was finished in the design phase. As such, they don't see the need to write secure code or perform code reviews. It's my biggest professional headache, and seems to be the prevailing attitude across the industry. Until that view changes, we're not going to see a large-scale improvement in the state of software security.
This WPS business is a giant turd.
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.
They're using their grammar skills there.
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.
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.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Because more and more techniques are crammed into different subsystems without isolation from others and without the computer having any model of itself. What i mean is: let's dictinct "broken by design" and "implementation bugs". About the first one we cant do much on a short timescale, because a new design (e.g. mandatory encryption/authentication) requires user education (how to distribute keys) about bugs ii can only say: wireless network driver are doing things which are not driver-like (e.g. WPA). If we could isolate the "high entropy exchange" WPA part completely from the comparatatively straighforward hardware access and let the higher layer run in userspace, we would have won a lot. But as long as every hardware vendor is focused on getting the own hardware to the market quickly they will continue to pack crappy drivers.
actually, I would argue that it's facile assumptions like yours that are the main reasons why so many software products (commercial or otherwise) are riddled with security holes.
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?
somewhere, somehow, every programmer will make a mistake. whether it's bad design or a genuine bug, but there are plenty of dedicated professionals and amateurs who will find it for you.
The reason girls and Windows users don't understand UNIX is because all the documentation is in Man files.
Wow, what a case of the emperor has no cl..
*EUGH!!!! MY EYES! MY EYES!*
Jesus! What is WRONG with you!
Chas - The one, the only.
THANK GOD!!!
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 for saying something I didn't say.
Need a Python, C++, Unix, Linux develop
Not everyone who buys software can read code or understand the hardware which it controls.
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.
My little Linux and tech blog
I know that's a joke, but it does show a good point. Crypto is not just about math. The math behind RSA is pretty sound, but it is pretty hard to get TLS right.
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 their own services.
You could start supporting trusted roots that will sign keys for free, but then it is really hard to make sure that the free service is properly checking the credentials of everyone that submits keys to them, and you never really know how secure those root keys really are.
You could also just support connecting to unsigned services, but then that opens many possibilities for man in the middle style attacks, especially if the attacker is able to downgrade the crypto during the initial handshake.
I think the most difficult thing about all of this, is how do you communicate this information to a typical user. PKI is pretty complicated, and if you just lock the service out every time there is a hiccup in the exchange, most users will just get aggravated, and use a different product (as an example, see vista's new security warnings). If you are too lax about what you allow, you put users at risk.
No matter where on the spectrum a vendor lands, attacks are possible.
actually, part 2 is partially 'obsolete' many skilled crackers now work for that various organized crime syndicates, and they would get a nice bullet in the head for disclosing how their latest crack is compromising x million computers.
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 blocks for 'unpatched' systems. 3. 'malware' sites etc. 4. the piece de la resistance I backed up my motherboard bios to a floppy diskette, then compared the dates to dl the 'same' bios from the motherboard manufacturer, and they had different md5 sums. working computers with a bios not provided by the manufacturer.
the root-kit was so stealthy only the various corrupted media, and a few inconsistencies like auto run disabling when certain dvds were put in that it was nearly impossible to tell anything was wrong. and since most computer places ignore the bios, thinking that bios virus would 'wipe' the bios, making it worthless, rather than replace it with working code that makes it a haven for mafia hackers... the infected backup media was how i determined how long i was rooted but in truth it may have been longer, if cd and dvd based root-kit re-installers were just getting started 3 years ago..
since then I've switched to infra recorder, for windows PCs, and making all cds and dvds 'finalized' so no additional sessions can be added. (infra recorder does this by default)
I don't know what i'm going to do when i get a BD-R drive, since it may take a while for open source to burn both data and video BD-Rs, and I will be getting a BD-R some time in the next 2 years...
https://www.gnu.org/philosophy/free-sw.html
...used together with wireless, this makes one hell of a tight drum.
Speaking in theory to generate cryptographically useful pseudo random bits you need a seed only as big as a key for your favorite symmetrical algorithm. So we aren't talking about generating gigabytes of real random bytes (which would be indeed hard to get without any traffic) but about generating 10-20 bytes (during the whole previous life of the router!) random enough that you can't bruteforce it. Still you say how do you generate different pseudo random data with a device that is identical with the one in your lab. Well if the devices are identical and they are fed the same data yes they will give you the same output. However in order to reproduce this you will need:
- access to all data stored on the flash (not only mac, serial number but all saved credentials)
- access to all start/stop times of the router during its lifetime down to mili/microsecond
- access to all traffic the router saw ever (over wireless AND over wired network). This is harder than it looks as wireless traffic looks different to different receivers so you would need to physically modify the router and tap inside it to get the traffic
This is not dry theory, it is as real life as it gets (see http://en.wikipedia.org/wiki/Urandom for reference). Even if you save the random seed only in the RAM you still don't have access to the ROM and to all the traffic the machine sees for that session (or if you do have access it is game over already).
Yes there might be bad implementations but this is far from broken even in a thought experiment. We know how to make it work and any *nix has a nice implementation already.
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.
- Michael T. Babcock (Yes, I blog)
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
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!?!
For a typical household Laptop --> Router configuration the following is probably the best way to do it:
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 just no way to get a secure wireless transmission due to the very nature of wireless. Granted you could get better speed with a hardware accelerated encryption, but it has the disadvantage of being considerably harder to patch should a vulnerability in the implementation be discovered.
Now just to spell it out: No, you can't avoid doing the key exchange over a trusted channel, regardless of protocol, OpenSSH can't change this, and no other protocol can. Yes, you need to trust whoever supplies the hardware. Yes, you need to secure the physical access to the router / computer or trust whoever manage it to do so. Yes, OpenSSH isn't invulnerable, it may or may not have flaws, but good luck finding a more secure solution that is freely available.
I dare guess that in the vast majority of situations you are more likely to screw things up and make yourself vulnerable if you try some more "innovative" solution than if you just use SSH. Wireless is not a secure medium, SSH is designed to secure communication over insecure channels, it's what it does. It's open , widely scrutinized, and relies on peer reviewed algorithms. Long story short, if SSH isn't good enough for you then you should probably be using a wired connection.
The only major disadvantage I can think of is that SSH may be a bit tricky to set up for the typical user. The solution then is to create a nice cuddly fronted which guides the user through the process. I.e:
"Hi, to secure your connection please choose a passphrase. Good passphrases are... blah blah blah"
"Please use the suplied CAT5E cable to connect your Laptop to your router."
"Congratulations, your router is now ready to accept secure wireless connections from your laptop."
The catch to this scheme is that you do at some point need to make a secure physical connection between the router and the laptop. This could be avoided by pre-loading every router with a key based on its serial number or something, but this is obviously less secure ( thou perhaps insignificantly so ).
There have been numerous vulnerabilities in various IPSEC implementations which have been detected by third parties.
I'm still waiting.No, no you aren't.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I'll phone up the secretary and ask her for the connection info so that I and my fellow investors at Venture Vultures, Inc can talk to her boss in private. Could she email the keys to us? Thanks.
Social hacking is far easier than beating mathematics with brute force.
Find me a person who knows how to even FIND the IPSec keys and will also give them up, and I'll be impressed.
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 between networks are very fun.
- Michael T. Babcock (Yes, I blog)