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)
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
"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.
- 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
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
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"?
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