The Real Story On WPA's Flaw 67
Glenn Fleishman writes "The reports earlier today on WPA's TKIP key type being cracked were incorrect. I spoke at length with Erik Tews, the joint author of the paper that discloses a checksum weakness in TKIP that allows individual short packets to be decrypted without revealing the TKIP key. I wrote this up for Ars Technica with quite a bit of background on WEP and WPA. Tews's paper, co-written with Martin Beck, whom he credits as discovering and implementing a working crack (in aircrack-ng as a module), describes a way to use a backwards-compatible part of TKIP to exploit a weakness that remains from WEP. ARP packets and similarly short packets can be decoded. Longer packets are likely still safe, and TKIP hasn't been cracked. Don't believe the hype, but the exploit is still notable."
vocabulary (Score:3, Funny)
Re: (Score:1)
Re: (Score:2, Funny)
Re: (Score:3, Informative)
Not offtopic! (Score:2)
assigned
computer
Alright, they're of middling length and not "really long", but still! Cut the guy some slack, at least he /tried/ to keep on-topic by using middling-length words.
The boy who cried wolf... (Score:3, Insightful)
Re: (Score:2)
> Well, really, these stories should be checked out more throughly before publication!!!!
Or:
"Well, these stories should probably be checked moro thoroughly before publication. But I'm no expert on the matter of story publication so they might have been checked as thoroughly as necessary, under the circumstances.
Furthermore, this is just my humble opinion. I'm no expert on checking news either, so this entire paragraph may be unprecise.
Also, I may or may not be a government agent paid to spread misinforma
Re:The boy who cried wolf... (Score:4, Funny)
Re:The boy who cried wolf... (Score:5, Insightful)
This is exactly why the trend of waiting to release news at security conventions is a bad idea. By announcing that there's an exploit but withholding the details, real harm can be done. I understand that security researcher is not a glamorous position (being one myself), and I understand the desire to keep certain details of an exploit under wraps until a vendor fixes them. Ultimately, if you want to wait until the vendor fixes the problem, you do not publish. It's that simple.
Otherwise you end up with, "omg the sky is falling!11!!!11!1! TKIP sux lol may just use open wifi".
Re: (Score:3, Insightful)
This is exactly why the trend of waiting to release news at security conventions is a bad idea. By announcing that there's an exploit but withholding the details, real harm can be done. I understand that security researcher is not a glamorous position (being one myself), and I understand the desire to keep certain details of an exploit under wraps until a vendor fixes them. Ultimately, if you want to wait until the vendor fixes the problem, you do not publish. It's that simple.
Otherwise you end up with, "omg the sky is falling!11!!!11!1! TKIP sux lol may just use open wifi".
As a user of the technology, and as a technologist who is geared to support the firms I work for, I want the news of a potential exploit that may affect me or my organizations to be presented as soon as possible, so I can take measures before the vendor releases a fix.
Get the news out on a real exploit out immediately, but make sure it's real.
Re:The boy who cried wolf... (Score:5, Insightful)
In many cases, knowing about an exploitable vulnerability doesn't mean you can do anything about it. That is the very heart of the full disclosure/responsible disclosure debate.
Re:The boy who cried wolf... (Score:4, Insightful)
I want the news of a potential exploit that may affect me or my organizations to be presented as soon as possible, so I can take measures before the vendor releases a fix. In many cases, knowing about an exploitable vulnerability doesn't mean you can do anything about it. That is the very heart of the full disclosure/responsible disclosure debate.
There's always something you can do about it -- even if it's a matter of policy vs. technology. Or sometimes there's creative solutions that can be put in place. For instance, if WPA encryption were found to have an actual exploit, you could add an additional encryption layer via VPN or even simply an SSH tunnel. I actually do the latter over the really insecure WEP connections.
Re:The boy who cried wolf... (Score:5, Insightful)
An unknown attack vector is far worse than a known one. If you know where an attack is going to be coming from you have a far better chance of either A) preventing or B) reacting to an attack.
Knowing is a LOT better than having no idea your system is vulnerable and it getting compromised. Particularly if your job is knowing all you can about security and securing your company's system...
Re: (Score:3, Interesting)
full disclosure/responsible disclosure
Can we please not use loaded language to describe the two positions?
If limited disclosure is, according to a reasoned interpretation of factual evidence, the only responsible thing to do, why is there still a debate? Are people that blinded by dogma?
Isn't it irresponsible to keep people in the dark and let them continue using insecure technology? Especially when there for most people is a very simple, acceptable solution: plug in the wire if you want security, or don't if you don't.
I can see the value of
Re: (Score:1)
Pull the power cord out of the wall.
Re: (Score:2)
I said that I understood the argument for keeping vulnerabilities under wraps until they are fixed by the vendor. I didn't say that I agreed with it.
You are right, there are many ways you can mitigate vulnerabilities that aren't fixed yet - you can take vulnerable machines offline, you can disable the vulnerable service, you can switch to another piece of software without that vulnerability, or you can do nothing. Only the user of the software knows which course of action is right for them because they're
Re: (Score:2)
Well, even the Internet Storm Center (ISC [sans.org]) wrote about it [sans.org].
Usually one could assume that the ISC would not write about it if it was not true as one of their handlers is Joshua Wright [willhackforsushi.com], my favourite wireless enthusiast. Not only do I dare saying that he is one of the world greatest wifi researchers but he also has close ties to many other wifi experts. I would be surprised if he does not know Martin Beck (the author of aircrack-ng) in person.
BTW, Josh, if you happen to read this, I would love to here a comment
Re: (Score:2)
Sorry, I just saw that Martin Beck is not the author of aircrack-ng as such but is an aircrack-ng team member).
OK, that settles it (Score:5, Insightful)
OK, that settles it. Ars Technica for the win!
They've been doing a great job on technical analysis for a long time now ...
Re: (Score:2)
Re: (Score:1)
ARSTECH only spits back what others already have (Score:2, Insightful)
They have people 'reporting' for them that have no degrees in the computer sciences, nor even certifications in the art & sciences of computing, let alone years to decades of hands on experience in computers in the trenches actually doing the job. Jeremy Reimer being a prime example thereof in fact. This makes them good? I know not. Anyone can re-report what has already been posted up from other sources after all. That does not take brains, nor is it indicative of quality original work either.
Big breaks start from small holes (Score:5, Interesting)
This is more interesting than I suspect most people will think it is. With any security system, researchers build on weaknesses found piece by piece. It might not seem a big deal that short packets can be decoded nor that a few additional packets can be injected into a wifi network data stream, but these small cracks almost always lead to methods of getting more information from the security system.
I've been watching WPA security studies for a while, and this seems the most significant flaw yet found. It will be very interesting to see if and how this exploit is grown into something more generally usable.
Re: (Score:1)
I only know enough about networks to be dangerous but, experts correct me if I'm wrong, this has the potential to allow DNS query responses to be spoofed sending the victim to either a hostile website or through a hostile proxy? Also, I guess, by injecting fake ARP packets you could deny someone access to their own wireless network?
Re:Big breaks start from small holes (Score:5, Interesting)
With any security system, researchers build on weaknesses found piece by piece.
If we're talking about crypto, that's not always true.
RSA is claimed to be secure, when used in the right way, against some number of scenarios (wikipoogle for IND-CCA2). For instance, if you give me two plaintexts and I encrypt one, you can't tell which one I encrypted (when RSA is used with OAEP). In particular, you can't learn any single bit of the plaintext behind the encryption. Add some more scenarios; then we have a "piece-by-piece" claim about the security of RSA (possibly even proofs that breaks can give us a factoring).
On the other hand, when we construct protocols that combine several pieces, we often do it in the Universal Composability model. That is, we describe in a black-box fashion how an ideal functionality should behave. Then we show that if we have implementations of each black box, our way of combining them yields something that acts like black-box design we were trying to implement. Thus: we have shown our construction secure, without looking at each attack one by one.
An example: "Secure Transfer"; boiled down, a user inputs a message. Later, the network delivers the message to the other user. The adversary, who can monitor the network, learns the length of the message.
Another example: Authenticated Transfer. The same, except the adversary learns the message.
You can build ST from AT: have the receiver first send a public key, then have the sender send the message encrypted with the public key. If we assume our cryptosystem to be secure, one can show that this implements ST.
I've omitted the details you need to show it in a formal sense, but it rings true, right? That's what cryptosystems do: obscure the message.
Don't panic, but... (Score:5, Insightful)
Attacks only get better, not worse. The right thing to do, IMO, is treat this as a warning. We need to stop trying to concoct schemes that are specific to wifi and just treat wireless media as untrusted. Harden the clients. Don't let them act like they're on a trusted local network until they're on your VPN. Besides getting more thoroughly vetted crypto, this leaves your road warriors in a much better position when they sign on in coffee houses, airports and hotels.
Re: (Score:3, Insightful)
Finally, some common sense I can agree with.
Re:Don't panic, but... (Score:4, Funny)
Re: (Score:2)
Why is an encrypted VPN fundamentally more secure than an encrypted wireless network? If they can crack one, can't they crack the other?
Re: (Score:2)
I don't know that I'd say the difference is exactly fundamental. Sure, if you're talking about weaknesses a cipher, a general attack on might apply to any protocol that uses that particular algorithm. It's not just a cipher algorithm, though; getting secure key exchange right is a hard problem. You want the protocol you've selected for doing so to have been vetted by as many people for as long a time as possible. VPNs have been around for a great deal longer than these new wireless schemes, and more people
Re: (Score:2)
Or use OpenSSH to a LAN host with the -D option ( -D 8080 ) and point your proxy to localhost:8080 for SOCKS.
Re: (Score:1)
We need to stop trying to concoct schemes that are specific to wifi and just treat all media as untrusted.
There, fixed that for you. What makes you think wired networking is secure?
Re: (Score:2)
We need to stop trying to concoct schemes that are specific to wifi and just treat all media as untrusted.
There, fixed that for you. What makes you think wired networking is secure?
Men with guns, usually ;-). But I agree with your point, and don't generally consider the condition of being wired sufficient access control.
A crack (Score:5, Insightful)
Yes, it's only a crack, not a collapse. But a crack into which can be inserted the crowbar of, in this case, ARP or DNS spoofing. Enough to force quite a large hole into a wireless network which relies on TKIP. AES is safe, yes, but if your router allows TKIP, this could be quite a large hole... enough to poke a user on the other side to start sending their private traffic across the Internet, other wireless networks, etc. to a third-party IP.
And it won't be long before that crack becomes a hole big enough to slap the user through. It's not "the sky is falling" but it's a wake up call to people who thought TKIP/WPA was "safe enough" to instead make sure they are using AES with strong keys. Personally, even the school wireless routers that I manage have WPA2, AES with PSK's in the range of 512bytes each. Doing that from the first has bought me a lot of time in which to be secure. However, if I had started slightly earlier with WEP equipment, moved onto WPA as a compatability measure, etc. I might now be in the position where I would need to move again.
It's right to make a fuss of this. It's wrong to suggest the WPA (or, by unsaid extension) WPA2 are "broken". Even if they were, we have no viable alternative just yet, anyway, so you're stuffed. :-)
Re:A crack (Score:5, Insightful)
Er, they have found a weakness in TKIP in WPA1 which is not present when using WPA2/AES. It covers all this in the Ars Technica article.
Re: (Score:3, Informative)
In the 802.11 spec, WPA (a marketing term) is called a TSN. CCMP (WPA2) is called an RSN.
T stands for Transitional.
R stands for Robust.
TKIP was known to be at risk of cryptographic attack at the time of its creation and was created for use on older hardware. Hence the name. We were supposed to transition to newer hardware which could implement an RSN.
If we had followed the spec, we would have transitioned to AES/CCMP/WPA2 and future attacks on TKIP would be moot.
Re: (Score:2)
Turn off QOS, that breaks this attack. For a long term fix use AES (WPA2), using WPA when WPA2 is an option is foolish as TKIP was designed to be a temporary solution for hardware that didnt support AES.
Changing the rekey interval to 3 mins should also cripple this attack.
What uses QOS anyway?
Re: (Score:3, Informative)
that will teach me to get board of TFA (hey too much maths and its the weekend),
stopping qos isn't enough, as the attacker can simply replace you in the network for the duration of the attack
Even if the network does not support the IEEE 802.11e QoS features, the attack still
seems to be possible. Here, the attacker needs to prevent the client from receiving the
data packet he chooses for the chopchop attack, and must disconnect the client from
the access point for the time of the attack, so that the TSC counter is not increased
by the packet or following packets. After the attacker has successfully executed the
chopchop attack, he can send a single data packet to the client. However, we did not
implement this attack mode.
the countermeasure the attackers suggest is rekeying every 2 minutes
5.1 Countermeasures
To prevent this attack, we suggest using a very short rekeying time, for example 120
seconds or less. In 120 seconds, the attacker can only decrypt parts of the ICV value
at the end of a packet. Alternatively disabling the sending of MIC failure report
frame frames on the clients would also prevent the attack. The best solution would
be disabling TKIP and using a CCMP only network.
Re: (Score:1)
And it won't be long before that crack becomes a hole big enough to slap the user through.
Heh.
Personally, even the school wireless routers that I manage have WPA2, AES with PSK's in the range of 512bytes each.
Seriously? You use a 512 character password? :)
Assuming you meant that you use the full 64 hex characters (512 bits), did you realize that the PSK is hashed down to 256 bits anyway?
Re: (Score:2)
I use the max 63 character passphrase length. My key actually has in it something such as "NO-UNAUTHORIZED-USE-PRIVATE-SYSTEM".
Re:A crack (Score:4, Informative)
Someone didn't RTFA.
WPA isn't broken. TKIP (and *ONLY* TKIP) has a flaw which means it is susceptible for small packets, assuming that people are able to send unlimited amounts of data at the router and have it respond to that data - this might even be fixable in firmware by implementing the same time limits as WPA2 uses for such things.
TKIP is an *option* in the standard, the alternative being the still-secure AES. So one (little-used) protocol out of two (or more) possible protocols in an ageing standard that has been superceded in all practically available hardware by WPA2, has a flaw in that an attacker who can send unlimited data and recieved unlimited responses to that data may, after lots of analysis be able to craft a *small* packet (which is admittedly no worse or better than being able to generate any packet). It's a crack, yes, but you can:
Use AES instead of TKIP
Wait for the manufacturers to put out an updated firmware
Use WPA2 (which is probably the default already)
It isn't the end of the world, but the horsemen of the Apocalypse might well be getting their horses some nice new shoes ready...
Re: (Score:2)
So one (little-used) protocol out of two (or more) possible protocols
That would be great but
1) older hardware will only support tkip
2) windows xp has problems with WPA2 so tkip is more widely used.
Re: (Score:2)
>I think it's fair to claim the WPA is currently broken.
Yes its broken when used in concert with normal network protocols. You can use the TKIP attack to launch an ARP poisoning attack.
>The only correct response is to come to the realization that there is currently no secure wireless security protocol (at least not one that is standardized and in wide use).
What's wrong with CCMP? Or PKMv2?
We should be safe from any WPA vulnerability! (Score:4, Funny)
Still using WEP here. ;)
Isn't Wireless Security Overrated? (Score:1)
I mean were talking physical proximity VS. the entire Internet!
Not a flaw in i, but in e, and not much of one.... (Score:5, Interesting)
Well, the ARS writeup is much better that what dribbled out yesterday, and I actually understand what is going on here. I was one of the authors of IEEE 802.11i. The protection mechanism we built in to counter these type of attacks (TKIP Countermeasures triggered by two or more MIC failures within 60 seconds) is STILL present and functioning as designed. These guys figured out that the MIC counter is incremented separately for each QoS queue, so instead of one guess at the key per minute, you get LOTS more. The "flaw" then is in the interaction of 802.11i (the security enhancements) and 802.11e (QoS), not in 802.11i itself.
Remember that the key that is cracked is a per-frame temporal key, not the pairwise master key, and the scope of what you can do with this is severly limited. I am personally not at all convinced that that this attack or ones which build on it will improve. This attack is an active one, and it is detectable either by the AP under attack or by a wireless IDS. I can also predict that a simple change in the way MIC failures are tracked and rekeying the network when this attack is detected would defeat it, just as the original Michael MIC was designed to do.
Finally, remember that TKIP was intended to be a retrofit to band-aid the problem until the full AES based standard was finished. We published what became known as WPA more than 6 years ago, and didn't mandate the replacement of hardware to implement it.
Not to bad, in my humble opinion....
Re: (Score:2)
Apart from VOIP, what really uses QOS anyway?