Researchers Claim to Crack 802.1x WiFi 109
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."
Inevitable (Score:1, Redundant)
Re:Inevitable (Score:2)
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.
Re:Inevitable (Score:2)
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?
Re:Inevitable (Score:2)
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.
Re:Inevitable (Score:2)
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.
Re:Inevitable (Score:1)
Re:Inevitable (Score:2)
OMFG!!! (Score:1)
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
The Unofficial 802.11 Security Web Page (Score:5, Informative)
The Unofficial 802.11 Security Web Page [drizzle.com]
Re:The Art of Cunniligus (Score:1)
"Lick the alphabet"
A
B
C
... it works
802.1x NOT 802.11x (Score:1, Insightful)
Re:Ha come on! (Score:2)
This problem exists whether you use WEP or not
Really, let's actually try to read the article from now on.
Oh come on!!! (Score:1, Redundant)
Re:Oh come on!!! (Score:2)
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.
no biggie (Score:1)
but I still love the wireless (Score:5, Interesting)
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?
WECA 1, DMCA 0 (Score:2)
Re:but I still love the wireless (Score:2)
Wireless protocols are not peer reviewed to the extent AES was, so why not run your communication through an AES tunnel? It only makes sense to do so. And since OpenSSH supports AES (128bit, 192bit, and 256bit) it makes good sense to take advantage of the encryption.
More readable "print-friendly" version (Score:2)
Heard this all before (Score:1)
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
Re:Heard this all before (Score:1)
802.1x when used in conjunction with rapid re-keying is a moderate to good security solution. Coupling all of this with an ACL(Access Control List) provides a good to very good solution.
Running something like SSH over all of this make an excellent solution, AES be damned!
So which is it? 802.1x or 802.11x? (Score:1, Insightful)
The Researchers' Wireless Research Page (Score:5, Informative)
Let's get the "Inherrent Problems" out in the open (Score:5, Informative)
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.
Re:Let's get the "Inherrent Problems" out in the o (Score:2, Interesting)
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 [swcp.com] 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 [nist.gov], 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 [nist.gov] 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.
Re:Let's get the "Inherrent Problems" out in the o (Score:5, Informative)
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.
Re:Let's get the "Inherrent Problems" out in the o (Score:1)
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.
Re:Let's get the "Inherrent Problems" out in the o (Score:2)
If you bothered to read and understand the paper by Fluhrer, Mantin and Shamir [umd.edu] 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.
Re:Let's get the "Inherrent Problems" out in the o (Score:1)
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
Re:Let's get the "Inherrent Problems" out in the o (Score:2)
Re:Let's get the "Inherrent Problems" out in the o (Score:1)
Re:Let's get the "Inherrent Problems" out in the o (Score:1)
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.
Re:Let's get the "Inherrent Problems" out in the o (Score:2)
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.
Re:Let's get the "Inherrent Problems" out in the o (Score:1)
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.
Just curious... (Score:4, Interesting)
Re:Just curious... (Score:1)
Re:Just curious... (Score:1)
Re:Just curious... (Score:2, Informative)
Linux (I cannot speak for other Unices) changes your MAC address by setting the card into promiscuous mode, so that it listens to every MAC address. Then in software, it filters out MAC addresses that don't match the MAC address you have specified. It also attaches the specified MAC to outgoing packets, obviously.
At least this is how it was done in the 2.0 series kernels. I can't imagine it has changed much.
Re:Just curious... (Score:2)
It depends on the NIC and its driver. Some NIC's have always allowed the MAC to be changed on the card. On others it couldn't be done and required a kernel hack.
Re:Just curious... (Score:5, Informative)
Is this protected by DMC (Score:3, Interesting)
Re:Is this protected by DMC (Score:1)
Secure wireless (Score:2, Interesting)
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
Re:Secure wireless (Score:4, Informative)
The man in the middle attack can be avoided by using mutual authentication which is a part of the EAP-TLS standard usually used to implement 802.1x. The version of the standard being urged by MS and being shipped with Windows XP can be configured to not have this vulnerability. The problem here is that this must be configured on the client and you might not always have control over the clients.
Re:It would seem to me... (Score:1)
Re:Secure wireless (Score:1)
Avoid any new technology for security--not only does it not have a lot of analysis and peer review on paper, but vendors usually don't get the implementation right on the first try in silicon and code. Chances are if the spec has "theoretical weaknesses," the vendor's product will have "exploitable vulnerabilities."
I generally design such systems by re-using existing practices and technology wherever possible. So my wireless LAN is a bunch of AP's connected to an ethernet switch (or, if you have less than about 8 AP's in one site with a few 100mbit wired ports on each, you can usually just connect them all to each other). The wireless LAN is then connected to the hostile side of the existing corporate firewall--either the firewall connected to the Internet, or a nearly identical copy of it. The wireless LAN and anything connected to it is assumed to be as hostile as the public Internet.
For extra security, add an IDS box to monitor the network. The IDS box should do both passive listening (watching for non-VPN traffic) and active scanning (scan for open ports on all active IP's), and should be able to disconnect misconfigured hosts. Most AP's have some kind of web or SNMP interface these days that the IDS box can use, and most should support allowing or denying traffic based on MAC address of the wireless card.
The role of the IDS box here is to detect and shut down script kiddies and legitimate users with fatally misconfigured machines (e.g. the user or some program has tampered with the security policy or disabled the client's firewall). You probably want one of these even if you're doing 802.1x stuff, or even on Internet connections, since any machine connected to the protected LAN--from anywhere--that isn't sufficiently locked down creates a vulnerability for the entire LAN. The IDS doesn't give much protection against competent attackers, but it does let you know about the incompetent ones nicely.
Of course, the IDS box opens up a whole world of DoS attacks...and you'll need someone to monitor it...and if your VPN and firewalls are working, you don't need (or already have) IDS. So I consider it optional, and leave it up to my client to decide to use one or not.
On the client machines I use exactly the same VPN and firewall security software that I use for machines who attach to the LAN from the public Internet. It doesn't matter what VPN you use here. All the wireless I or my clients have deployed so far use different VPN products in their implementations. Since the same VPN is used for wireless and the existing external Internet access, the client doesn't have to retrain anyone or reconfigure or reinstall anything.
IMHO the public Internet is a much more dangerous place than a wireless network--with wireless, your attackers have to be within a certain physical distance, while on the Internet you can be attacked by anyone in the world.
802.1x != 802.11x (Score:5, Informative)
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).
Re:802.1x != 802.11x (Score:1)
Although IEEE nomeclatures can be tough to keep track of, I'm sick of every marketing moron I meet spouting how they need 802.11x when there is no such thing.
What does this have to do with Cisco? (Score:1, Interesting)
AES too slow and not yet available? (Score:2, Interesting)
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...Re:AES too slow and not yet available? (Score:2, Interesting)
The OEMs, likewise, don't want to pay and support driver development for host-based processing. They want to feed data into an onboard MAC that offloads it to the on-board encryption which sends it off to the PHY and radio.
You're absolutely right on all the other fronts, of course: AES is a piece of the puzzle and there's not a specific reason to not use host processing; it's a gestalt.
As for the rest, the industry hasn't yet taken that deep breath and said, we have to rethink the problem end-to-end.
Who cares (Score:3, Funny)
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...
Re:Who cares (Score:2)
Relax, a professional attacker would just use a better antenna and possibly HF-Amplifier. In fact you may feel even more secure as the attacker could be several hundred metres away, by investing in special equipment. And if it is real professionals they will not interrupt your operation at all, as that could make you suspicous.
Don't worry, if it is not the kids next door that try to listen, you will not be disturbed at all (expect for the SWAT Team breaking down your door when they have read the data you send over the network....;-)===)
Classical goofs (Score:5, Insightful)
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.
Old news (Score:1, Informative)
You can run Protected EAP on top of EAP/802.1x and protect the connection from the problems, see:
PEAP draft [ietf.org]
Of course, you'd need the WEP fix to solve the privacy and integrity problems of the connection as well.
Cisco already HAS TKIP (Score:1)
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.
Re:Cisco already HAS TKIP (Score:1)
No disrespect to Cisco on their backbone equipment, but buying your way into the Wireless segment, and then pushing proprietary crap is not what the networking community really needs.
Re:Cisco already HAS TKIP (Score:1)
for a year now right?
Or are you too busy FUD'ing to do any real research?
What about MIC? (Score:1)
I'm not convinced this is a real crack.
Oh come on....security 101 (Score:1, Interesting)
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.
Just use IPv6 (Score:1, Offtopic)
Client availability is the problem (Score:3, Interesting)
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)