WPA not cracked yet
I'll admit, when I heard that WPA, (specifically implementations using TKIP), was cracked, my first reaction was "It's about time." This does not stem from some deep held desire to obtain free internet access from my neighbors, but instead from the fact that TKIP use RC4. It's extremely hard to implement RC4 correctly. So much so, that in general I don't trust any encryption algorithm that uses a stream cipher vs. a block cipher, (for the crypto purists, yes block ciphers essentially become stream ciphers when put in CFB mode, but that's also when problems tend to occur).
I guess what I'm trying to say is I'm inclined to take a dire view of WPA's security. That being said, when headlines like "Wi-Fi Code Cracked in Minute" appears on the front page of Yahoo, (bad grammar and all), I really feel the need to post something. Regardless though, please understand, if you are still using WPA in TKIP mode you should at least start thinking about upgrading to WPA2, or WPA using AES. Even if this particular attack doesn't prove weaponizable, chances are another attack later on down the line will.
So disclaimers aside, and with all the doom and gloom I already posted, what's my problem with the Yahoo article? Well, it's the simple fact that the current attack doesn't break WPA in a practical sense yet. Now I admit, I'm not an expert when it comes to wireless encryption protocols. I consider myself more of a hobbyist, but I did stay at a Holiday Inn last night. I mean I did actually read the academic paper describing the attack details. Also my initial job after graduating from college, (the first time), was attacking wireless networks so this is a topic near and dear to my heart. Oh, and while I'm talking myself up, some of my Master's research involved attacking Ad-hoc networks which tend to use wireless protocols. I guess what I'm trying to say is that while this post may sound like I know what I'm talking about, chances are there are major flaws in my understanding of the attack and it's implications so please feel free to correct me.
The attack described is a refinement of the ChopChop attack applied to WPA that was originally discovered by Martin Beck and Erik Tews. There's a couple of things to note about this attack that limit its usefulness in real world situations.
It doesn't disclose/recover/discover, or whatever word you want to use, the encryption key. What this means is an attacker can't use this attack to figure out your password, hop on your network and start reading your e-mail or download random pictures of scantily clad individuals.
While this attack does allow the attacker to decrypt encrypted packets, even with the refinements proposed, it is not an entirely offline attack. It still needs to use an authorized user, (access point, and/or client), as an oracle. This means an attacker can't just collect the encrypted data, and then go home and spend the next year decrypting it on some botnet/computer in their mom's basement. Essentially they have a limited time window to decrypt the packets, and the limiting factor is not how fast their computer is, but the amount of data that is leaked via error messages sent by the defender. The reason that the original attack took so long was that if an attacker sends more than one packet with a bad Message Integrity Check within 60 seconds, the AP would drop the connection. Thus it would take a minimum of 11 minutes to make 12 submissions to the AP. Those 12 error messages would be enough for the attacker to decode 2 byes of data. Similarly, packet injection takes around 5 minutes to execute, with three of those minutes taken up by submitting four different packets to obtain specific error messages.
Continuing on point #2, in general most implementations of WPA are smart enough to realize that if someone is still trying to submit the same packet after 11 minutes, something is wrong. Or more to the point, WPA uses has a counter, (called the TKIP Sequence Counter or TSC) so when the actual client sends more data, the AP will no longer try to decrypt older packets. Beck and Tews get around this by attacking certain WPA implementations that allow multiple channels for QoS where the WPA implementation isn't smart enough to increment the TSC counter on all of them. One of the main improvements proposed by Ohigashi and Morii is to perform a true MITM attack where the client only talks to the attacker, not to the access point. Thus when the attacker wants to decrypt two bytes from a packet, they simply DoS the client for around 15 minutes. Needless to say, while this may be useful to decode an Arp packet at 3:00am in the morning, employing this attack when a user is online, and you know, sending interesting data, might be noticed. This is further complicated by point #4.
The attacker has to know EVERY byte in the packet they are attacking with the exception of the byte or two of information they are trying to discover. Essentially the attacker conducts a known plaintext attack by constructing every possible packet that could be created by those two unknown bytes of information and then uses the error messages from the Access Point to identify which one is the correct packet. What this means is an attacker can't use this attack to decode the first two bytes of someone's telnet login password since they don't know what the rest of the password is. That's also why you see these papers talk about decoding and injecting Arp packets. Essentially what they are assuming is that they know the first three octets of defender's IP address, (such as 192.168.0.x), and so they are only trying to decode the last octet, (the 'x'), for both the access point and the client. Conveniently that is only two bytes of information. Since it's an Arp packet, the mac address information is already known, (it's not encrypted by WPA), and the attacker can figure out what the rest of the packet will look like. Now from my reading of both the original paper and this new one, there is nothing stopping the attacker from attempting to guess what more than two bytes are. Well, except for the fact that the attack would then require several hours to several years to decrypt 4-5 bytes from a single message. I would expect that after the first week of the DoS attack someone would at least try to reboot the router, not to mention the automatic idle timeouts ;)
Finally, the "1 minute" time everyone is talking about only applies to injecting forged arp packets into the network, (it still takes around 11-15 minutes to decode a packet with the new attack). They achieved a speedup from the 4-5 minutes it took Beck/Tews attack to inject an arp packet by designing a way to forge the packet without having to contact the access point to verify if the packet is valid. Basically, instead of making sure their packet will be accepted, they just say "F*** it! Lets send it anyway. There's a 37 percent chance it will get accepted!). Then there's the fact that I have a hard time coming up with a non-DoS attack that involves injecting an Arp packet when the attacker doesn't have an authorized computer on the network, (otherwise why are they bothering to try and attack WPA in the first place). The only thing I can think of is framing someone else for Arp spoofing. Oh and the DoS attack isn't that useful since in order to pull it off, you have to already be able to perform a DoS attack, (though in all fairness you could perform a DoS attack against some other computer on the same Layer-2 network besides the client you are currently attacking).
Now I want to stress, this is good research that Ohigashi and Morrii are doing, and it almost certainly will lead to more potent attacks. Likewise, their paper is honest about what they are doing and the limitations of their attack. It's just that people see the words "WPA packet injection" and "Less than 1 minute," and automatically assume that WPA is as weak as WEP. Or as the Yahoo article puts it,
"The second generation of Wi-Fi security systems has now been broken as badly as its notoriously insecure predecessor"
It's just not true. As I said at the beginning of the post, if you are using WPA you should change to WPA2, but your neighbor's kid isn't going to be using your wireless anytime soon.
Comments