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)
With time, everything gets broken. The world's hackers (and even our crackers) are just too good. There are too many smart minds out there trying to solve the million puzzles like this that someone WILL find a way.
...has alot more info on the security issues concerning this protocol.
The Unofficial 802.11 Security Web Page
The articles states this clearly. There is a differnce in meaning, I believe.
Well, wasn't it obvious that without the Dynamic WEP key you could hijack the connection? But with the WEP things are a lot different than they describe as the man-in-the-middle doesn't know a thing about the session key and the protocol to negotiate those are mutual authentication based.
Except that those DOS attack are still present.
Can anyone really say that they DIDN'T see this comming?
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
IMHO, it's on its way out anyway.
spacefem.com
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 $$$
Is it just me, or have the many weaknesses in 802.1x security already been beaten to death?
It is clearly a broken and insecure technology. Workarounds are possible, but don't fix the underlying problem.
There. Now you don't need to read this and you can go look at userfriendly.
D
ELITISM: It's always lonely at the top. Uninvited company is rarely welcome.
Sure, I know the article only says "802.1x" but slashdot says 802.11x so they MUST have broken 802.11x instead!!!!
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.
Cisco uses LEAP for its secure wireless. Cisco supports WEP only for non-cisco product support. LEAP provides unique authentication to prevent session hijacking and man-in-the-middle. You also get to pay at least three times as much for Cisco. If you really don't care about security that much then you can go buy Linksys or some other commodity brand. This article was pretty crappy anyway. Some guy said he found some weaknesses in wireless security. Some other guy said he was not surprised. If you are using wireless in a hotspot, you should be using a VPN client to encrypt your data, just like if you were connecting from your hotel room. One time passwords and digital certs prevent highjacking of corporate data. Obviously this ass clown never thought of that. Here is an article on LEAP http://www.nwfusion.com/reviews/2001/1217revside3. html
If that's dirty GNU Hippiness, I like Dirty GNU Hippiness. It's a very sane position.
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.
Cisco needs to DMCA the professor and his student. Only that way the balance can be held.
I have seen a report of suspected 802.1x security-weaknessess before. I guess they are as strong as the open source business-model. To bad, it just sucks to be forced to use VPN software and other higher-level security when the protocol itself should be good enough.
It's a painful but (IMO) irrefutable fact: Much of the computer technology we're seeing introduced currently hasn't been thoroughly thought out and/or tested. In particular, anything new having to do with networking (or MS software) is likely to carry security risks that won't be immediately obvious. If you're willing to take that chance, then by all means, jump on the bandwagon and be an early adopter, but don't be surprised when you wind up paying a higher than expected price for being a trail blazer.
More important... WHat isn't breakable now, may be tomorrow. So while you may be "secure" in the knowledge that what you transmit today is indeed not being read, tomorrow there may be a crack and all that data is cach'd n compromis'd...
fslg503-985-8686503-985-8686503-985-8686503-985-8
Provocative question: how is this different from "wired" IP across several routers? That's why you need strong endpoint-to-endpoint encryption, e.g. SSL/TLS.
One additional problem seems to be that a simple way of session hijacking would enable a nasty Denial of Service Attack, but the other points are inherent problems in IP4 without IPsec (i.e. probably 99% of internet traffic) as well.
sig intentionally left blank
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.
It doesn't have to be strong..within a few weeks of releasing their research they'll probably be arrested and executed, by order of the DMCA.
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.
This is old news. IEEE 802.1x is EAP, which has been used for dialup connections with PPP for years. The problems are well known.
You can run Protected EAP on top of EAP/802.1x and protect the connection from the problems, see:
PEAP draft
Of course, you'd need the WEP fix to solve the privacy and integrity problems of the connection as well.
http://www.cisco.com/univercd/cc/td/doc/product
Plus - with Cisco products, if you want LEAP authentication, you now HAVE to use WEP. Before, WEP was optional.
The real problem is the fundamental way in which Wi-Fi works, according to Arbaugh. Although rapid rekeying of WEP keys, for example, which will be implemented in the next security standard called TKIP [Temporal Key Integrity Protocol], makes it more difficult to crack, Arbaugh said the entire design is just not good security.
"You are relying on a confidentiality mechanism, and in general that is considered bad design," he said.
The next generation of security is TKIP and is backward-compatible with current Wi-FI products and upgradeable with software. TKIP is a rapid re-keying protocol that changes the encryption key about every 10,000 packets, according to Dennis Eaton, WECA chairman.
First they burn books, then they burn people.
They didn't say if their attack gets around MIC, which is a part of what 802.11 group i is wokring on.
I'm not convinced this is a real crack.
-- dieman - Scott Dier
True, you should consider every packet of -encrypted- data as intercepted,
however: this isn't a problem, this has been a standard scenario for cryptology ever
since radio transmissions were first broadcast a hundred years ago..
The problems are inherent to the encryption algorithm, not the mode of communication.
SSH sure seems strong enough, we should be able to expect the same level of security in wireless networks.
Why on earth use a symetric cipher (rc4), and publish the private key?. Why not simply an asymetric system (rsa/dh/dsa)?
Isn't this all rather over the top? all the hard work has beem done already, why don't we learn?
All the popular operating systems now have built in public key, proved/tested technologies.
This all seems like madness, re-inventing the wheel.
VPN's to everywhere, hub and spoke, meshed, sureley its not that hard! We run 1000+ users, on a mixed wireless/hardwire network. All users are authnticated using SecureID onetime passwords (yes I've read the L0pht stuff, utter fantasy), so we have Authentication and Accountability! ONE POINT.
Then guarantee (as best as possible) confidentiality! easy use public key encryption, built into IPSEC. TWO POINTS.
And the lucky winner of 3 points, and I'm not a french judge! is, well availbility, retrict who
can access the network/data/entity.
What what!, no hacks yet!, I don't trust anyone, users are the worst, second external attackers, and then me and my staff.
SCORE:3 Insightfull.
However, Netscape was smart enough to learn from this disaster and hire some qualified expert cryptographers. (I think Taher el Gamal was involved in the design of SSL-v2.)
Let's hope that some competent people will redesign this thing from the bottom up.
sig intentionally left blank
... www.sixgirls.org
That the security of your wired LAN depends on all the multihomed PCs attached to the Wireless network not having any remote root type exploits.
Read the following article for a quick summary, and follow the link to the actual research paper to read about how it works. It is quite interesting.8 1501.shtml
http://www.powerbookcentral.com/columns/knowles/0
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.
Just curios here,
I have a lot of years experience doing C/C++ and am digging into some simple encryption.
An IV (Initalization Vector) should always be a fresh number for each encryptor/decryptor correct?
Jeremy
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.
Switched networks are generally no more secure than hubbed ones. Implementing mac layer security in the switch will help though.
How messed up is it that the THIRD post, and the first actual post from an intelligent life form is moderated as "redundant"?
I try to moderate while not completly wasted and I expect the same curtosy. This person deserves the same.
Moderation is dead! Long live the moderator!
Also Known As - Jack
What do the Enterprise and toilet paper have in common?
They both circle Uranus searching for clingons.
Sam K said:
"Lick the alphabet"
A
B
C
... it works