Slashdot Mirror
Researchers Claim to Crack 802.1x WiFi
satsujin writes: "Researchers from the University of Maryland have released a paper on the weaknesses found in the 802.11x protocol. It looks like it might not be as strong as Cisco has contended."
← Back to Stories (view on slashdot.org)
...has alot more info on the security issues concerning this protocol.
The Unofficial 802.11 Security Web Page
I have a wireless setup at home and absolutely love it. I also assume that everything I do on the network is transparent and so take appropriate steps when the situation is called for. Props to all the developers of GPG and OpenSSH.
And - this type of thing will only eventually lead to us having a more secure wireless networking protocol. Aren't you glad that these guys have the freedom to this kind of research?
http://staging.infoworld.com/articles/hn/xml/02/02 /14/020214hnwifispec.xml?Template=/storypages/prin tfriendly.html
~shiny
WILL HACK FOR $$$
Here's the UMD Professor's 802.11 Research page
Because of this, a security administrator, or even a home user, has to assume that every packet sent over a wireless connection is intercepted. Until there is reliable encryption that takes prohibitively long periods to break (remember, WEP is broken, and the break is a relatively quick one), this technology is simply unsecure, particularly for corporate use.
Would authentication using Mac Addresses take care of this problem? Or at least mac-address checking... Each wireless client has a Mac Address, after all....
At least these guys are open to correcting the problem, unlike the goons who sat on Felten et. al.
"Win treats sysadmins better than users. Mac treats users better than sysadmins. Linux treats everyone like sysadmins."
Maybe this is a question of understanding, if some corporation was sponsering or developed these standards could they sue these dudes under the DMC?
http://monkeyserver.com --- weeeeee
I'm trying to design a secure wireless architecture for a multi-site, multi-floor deployment (with roaming). I have to deploy soon: within a month or so, and can't afford to wait until IEEE fixes the standards.
I see possible 2 ways to attempt this (with 802.11b or 802.11a when it's available):
- VPN over wireless
- 802.1x authentication with TKIP
Both have their pros and cons.
I demoed Bluesocket (VPN concentrator/firewall for building wireless DMZ networks), which works. I found it difficult to administer, lacking reporting, and wonder how many VPN tunnels it will handle.
I'd prefer to go with the new industry standard (TKIP and 802.1x auth), and segregate wireless traffic onto DMZs, protected by a custom machine running iptables/sport, to provide firewalling, routing, IDS, arpwatch, etc.
I can't use 802.1x if it's insecure, and I'm having a difficult time determing how insecure 802.1x is based on the articles I've read.
Assuming I used 128 bit WEP, TKIP with fast key rotation, EAP auth via 802.1x, and segregate traffic on a WDMZ with a firewall and IDS, what vulnerabilities are left to exploit?
If it's the MiM attack, VPN over wireless may have the same issue, unless I roll out strong mutual authentication via certificates. Doable, but very unwieldy.
I'd appreciate anyone's throughts on this matter.
- Eric
This standard has been extended for wireless use. The problem described in the paper is quite different from the problem of cracking WEP. 802.1x uses a similar method of authentication and encryption that SSL does. It also provides for the possibility of changing WEP keys periodically. Although WEP is quite flawed, that problem can be avoided by changing the key on a per client basis with greater frequency than is required to determine what the key is.
The problems described by the paper could only happen in an exceptionally poorly configured wireless deployment. For these exploits to work you would have to be using 802.1x with WEP encryption disabled. This would be a strange thing to do since one of the main purposes of using 802.1x is to get effective WEP key rotation. For the man in the middle attack, you would need to have an imporperly configured authentication server (usually RADIUS).
I don't want free as in beer. I just want free beer.
Concerning Speed: the Rijndael AES proposal gives 70.5 Mbits/s for a VisualC++ Implemetation of Rijndael on a P200. This should be fast enough for the clients. Can anyone provide accurate figures, e.g. for the current implementation used in gpg?
Above all: AES is a symmetric block cipher, so this has nothing to do with the security problems adressed, as these seem to be flaws in the protocol. (session hijacking, man in the middle, etc.) These are questions of key managment, not of the block cipher used.
Seems that the chairman is not exactly an expert in crypto...sig intentionally left blank
So basically the person trying to steal my info would have to be hiding in my closet to even see the signal, nevermind cracked.
Sounds more like the makings of a scary movie instead of a techno hacker thriller...
Until there is reliable encryption that takes prohibitively long periods to break (remember, WEP is broken, and the break is a relatively quick one), this technology is simply unsecure, particularly for corporate use.
You can two parties can use Diffie-Hellman key exchange to agree on a key even when all traffic is being watched.
Also, there is plenty of "reliable encryption that takes prohbitibitively long periods to break", such as triple DES (Data Encryption Standard), and any of the the Advanced Encryption Standard finalists, at least in the sense that a lot of very qualified people have tried hard to break them for a long time in a very open process and so far failed. (Rijndael won the AES endorsement, but, not to my knowledge, because of a vulnerability discovered in any of the other finalists.) Granted, these algorithms are not mathematically proven to require a substantial number of cycles to break or even to be as difficult as some other famous problem (like Michael Rabin's public key algorithm), but, if that is your standard of security, then you also should not be sending even your encrypted traffic over any internet backbone links that are not known to you to be physically secure.
Wrong. First note that a successful break implies finding a way to do what the system was designed for with significantly less effort than the original security analysis claimed to be necessary. So if somebody "breaks" AES128 with effort 2^128, this is not a break. It was knowen all the time that this was possible.
With time some schemes may become insecure without having been broken. Others will not. For example it is unknowen whether one-time pads can be broken in this Universe. Current physical theory says they cannot.
Second, some schemes might be feasible to break, but nobody competent enough is interessted in doing it.
Third, an "academic break" is not necessarily a "practical break". For example an academic break may find a polynomial way of reversing an one-way function, but with a minimal exponent on the polynomial of, say, 1000. For most/all practical purpose the one-way function is still secure.
My opinion is that most/all of the recent wave of breaks is due to incometence of the designers. A lot of the industrial crypto is like that. People that believe they understood the matter and can design a complex cryptological system by themselves in a small group. Most of them fall on their face, but the supply of people that don't get it seems to be indefinite. Just have a look at all the claims of being "unbreakable" in,
e.g. sci.crypt. Some of these are broken in 5 minutes, i.e. the time needed to read the description. Or remember Oracle's claim about their "unbreakable" security.
Crypto is hard! You cannot test it to determine its quality, like you can with code. You have to understand it, and that is infinitely more complicated than just doing some tests.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted and ignored otherwise.
Seems these people goofed in both tasks! First they did not do two-way authentication. So everybody can claim to be the non-authenticated party. Then they used a form of authentication that allows a succesful imposter to now pose as the authenticated party. And third they did not prevent session hijacking, i.e. do not keep up the authentication!
Very, very incompetent. Obviously these people did not have a good crypto lecture or did not understand what they where supposed to learn there.
And they apperaently did not even read the specification of the infrastructure they are using. My favorite quote:
"If you look at the 802.1x, they tell you the 1x protocol is insecure when used in a shared medium environment unless a security association is established. Since 802.11 doesn't do that, so by IEEE's own words it is insecure," Arbaugh said.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted and ignored otherwise.
Can anyone really say that they DIDN'T see this comming?
Well, they could have hierd some real experts...
But I admit I am not surprised that they continue to think they can do this on their own.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted and ignored otherwise.
You can two parties can use Diffie-Hellman key exchange [swcp.com] to agree on a key even when all traffic is being watched.
As long as an attacker can only watch, this is true. An active attacker can mount a man in the middle attack (one of the attacks in the article was exactly this type) against a naive implementation. However, used correctly, DH can provide secure key agreement.
Also, there is plenty of "reliable encryption that takes prohbitibitively long periods to break", such as...
All of this is unnecessary. Why would we want to use a prohibitively slow block cipher like 3DES, or even a moderately slow block cipher like any of the AES finalists, when the stream cipher already used in WEP is perfectly adequate? RC4 is a well-respected cipher and can accomodate ridiculously large key sizes. WEP's problems aren't related to the algorithm, but to the misuse of the algorithm (it's a well-known fact that with RC4 you *must* discard the first few bytes of the keystream to permit the state table to be adequately mixed).
The article commented that they're considering AES for the next generation of wireless security, which makes it clear to me that they still don't get it. The problem *isn't* that RC4 is insecure, in which case using AES would be a nice fix, the problem is that *any* cipher applied in a foolish way by people who don't understand cryptographic protocol design will be weak, no matter how good that underlying cipher is.
I only hope that they're smart enough to publish the new protocol and solicit reviews and comments from people who do know what they're doing. Of course that only helps if they listen to the responses. As Arbaugh and Mishra point out "If anybody breaks [the encryption], they not only break the confidentiality but they also break the access control and the authentication so one break breaks everything. That is not good design. Each security mechanism should stand on its own." What they need is a fundamental redesign, not a new cipher, and they may not want to hear that.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Actually assuming that a wireless network is similar to an old style bus topology ethernet is a good approach. There everybody can read everything.
Unfortunately some people don't understand this and do stupid things like having a switched network for security and then connecting some users via wireless.
With Unix the solution (even for coperate use) is simple: Only allow ssh, sftp, and scp and ban (and scan ports to be sure it is not used) telnet, rsh, ftp,... for internal use. You don't even need to do a possibly difficult IPSec setup. Insecure services can be tunneled through ssh.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted and ignored otherwise.
Wow.. dude... I think your WRONG for being such a arse about your opinions. Essentially you say one person is wrong, and then write a paragraph explainnig basically what they said in a sentance. Yes, your salient poitns are correct, but they only server to fillin what the parent post already said.
Further, Cicso is not exactly know for security, and just look how easy it is to break the password on only cicsco router, or switch. Just change the rom to 0x2102, or was that 0x2101? Oh well, when you change the rom, it boots up without any security. And the passwords are not even strong. I know of many crack programs to break their password encryption scheam.
The fact is that, like the parent post points out, that when you have the entire wolrd working on this type of puzzle, it is only a matter of time, despite the good or week system involved.
Crypto is hard! You cannot test it to determine its quality, like you can with code. You have to understand it, and that is infinitely more complicated than just doing some tests. I duno... crypto is actually really easy once you get past the assumtion that it should be hard. Only people who don't really know anything about crypto tyend say its hard. That is normally because of the mystic that surrounds crypto.... sorta like the mystic that surrounds everything you don't understand. So the point now is why is this troll think he has anything to say about security?
It isn't a lie if you belive it.
I'm responsible for security for a 20 acre wireless net. The biggest problem I have is that I inherited the net and it's multivendor.
Cisco LEAP is great on 1/3 of it - and with WEP and 4 hour keys I feel it's as secure as I'd like it - running a VPN seems overkill and not user friendly. The Avaya (Lucent/Orinoco) bits are a pain because the client devices don't support any advanced security (they're cash registers) and on the Symbol bit the clients are handheld bar code scanners - which don't even support WEP.
The solution, firewalls - each wireless net is a VLAN which only has limited connectivity to the rest of the net. Some cracker can spend the time to get onto the LAN if they want to but they're not going to find anything interesting. The couple of servers that are available are hardened as if they were on the DMZ - I suspect this is the answer for alot of firms until multi-vendor wireless security is sorted out, which I think will be in a year when the clients/APs are replaced with 802.11a or 802.11g devices (we'll wait for 802.11g 'cos the range on 802.11a is unworkable)
If you bothered to read and understand the paper by Fluhrer, Mantin and Shamir that is linked to in the article you mention, you'd see that I know precisely what I'm talking about.
As the paper states:
And this paper was far from the first to note this weakness, although the authors did demonstrate a more effective method than had previously been known (which is what made it valuable research). The authors also presented a new and interesting weakness that can arise from one common approach to performing the key scheduling (XORins the IV with a fixed key, rather than hashing IV and key). Both points have an effect on WEP security. It's the two weaknesses when exploited together that lead to the "linear" time break of WEP.
However, as I said in the post you replied to: "it's a well-known fact that with RC4 you *must* discard the first few bytes of the keystream to permit the state table to be adequately mixed". Had the WEP protocol designers simply chosen to discard the first, say, 256 bytes of the RC4 keystream, the protocol would still be secure. The known-IV weakness might yet reveal another attack that could work even without the first few bytes of the keystream, which is why it is now recommended that a secure hash be used for mixing IV and key, but that attack has not been found as of yet.
My real point was not that RC4 was good enough (although it is). My real point was that clueless (yes, clueless, *everyone* knows you don't use RC4 that way!) designers misused it and created an insecure protocol. Now they're thinking that using AES will fix the problem. It won't. The problem was clueless designers, not a weak cipher. Giving the same clueless designers a new cipher will only give us yet another broken protocol.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Often, but not necessarily. What is the purpose of your IV?
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
So the point now is why is this troll think he has anything to say about security?
Maybe because I have seen to much bad crypto already? And maybe because I do teaching and research in security, an area that is in part close to crypto?
My point is not that crypto cannot be done properly, but that far to many people think it is easy and, by not respecting the complexities, screw up.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted and ignored otherwise.
That is so true... and the real problem is in developer miss-education about programming. The root is that the universities don't teach under-grad application security at an early level. They have a hard enough time to teach folks the right way to program in syntax, let alone security. It think Bruce Schneier said about his book causing people to create bad crypto systems in that they read it, think they know crypto like gods (they really don't) and go off and write bad API's.. So in that way I can agree.
On the greater subject of complexity theory, I'd say that in this day and age we will see a growth of those so called lighning strikes where that one lucky person find the hole in the systems API. Especially as computer power increases across the board.
It isn't a lie if you belive it.
From the article:
This problem exists whether you use WEP or not
Really, let's actually try to read the article from now on.
That is correct about not allowing people anywhere near the Cicso gear: routers, or switches. I'd also say the TACAS is the way to go. About the boot registers, the hint is in the name. Even thought that is not very discrete way to get in. The solution is to lock the door of your wire closet, and fill it with noxtious non-breathable gas. Alas, the secret-5 hashing system. All I have to say in regards to secret-5 is the answer exist in polynomial-time, so it is automatically a contender for the average joe type cracker with a laptop. Even then there is logging, and triggers mechanisms to catch intruders. The answer is to track down people who attempt to login over the internet, and chop their fingers off.
It isn't a lie if you belive it.