Cracking the WPA Security Standard

[Nytro]

Cracking the WPA Security Standard

By Andrew Garcia | Posted 2008-11-09

Analysis: As security researchers prepare to discuss how they were able to subvert the WPA wireless security standard, eWEEK Labs outlines what this means to wireless administrators.

At the PacSec conference in Tokyo the week of Nov. 10, researchers Erik Tews and Martin Beck will outline the attack they created to subvert WPA wireless security protections.

Although the attack is limited in scope at this time-as it only affects TKIP (Temporal Key Integrity Protocol)-protected networks and can only be used to inject traffic but not to steal data-there is sure to be significant confusion about the effects of the attack.

In this article, I have outlined five points about the attack and its consequences that are crucial for wireless administrators to understand-about how it works, what its limits are, and what can be done to protect wireless networks and the data they carry from attackers.

First of all, the attack by Tews and Beck only works against networks protected with TKIP. TKIP, originally called WEP2, was an interim standard adopted to allow wireless users to have an upgrade from the broken WEP (Wired Equivalent Privacy) protocol that lets them protect their wireless data without requiring an investment in new hardware. TKIP took the basics of WEP (and therefore uses the same RC4 stream cipher), enforced a longer encryption key, added per-packet keys, boosted the Initialization Vector used to generate keys from 24-bit to 48-bit in length, and added a new Integrity Check checksum (called Michael).

It is Michael that is at the root of the new attack. The attack, which leverages a modified chop-chop attack that allows the decryption of individual packets without cracking the Pairwise Master key (the shared secret between clients and the network used for encryption), goes after the Pairwise Transient Key protecting the session in order to interpret very small packets (like an ARP) of just a few bytes of unknown data.

The attacker must probe cautiously because Michael will shut down a device for 60 seconds and rekey if it sees two Michael errors within a minute. However, because there is little to guess in these small packets, the attacker only needs to spend a few minutes (12 to 15 minutes, from what I understand) probing Michael until it stops returning errors. At that point, the attacker can then go to work with the chop-chop attack to get past the integrity check built into the original WEP (that TKIP still uses).

AES-protected networks, on the other hand, are immune to this attack, as AES uses an entirely different keying method called CCMP (Counter Mode with Cipher Block Chaining Message Authentication Code Protocol).

Second, because the encryption key is not broken as part of this attack, and the subversion of the Michael Integrity Check the attack uses is really only practical when interpreting small packets (too much to guess and not enough time before a regularly scheduled rekeying event happens), an attacker cannot decrypt and steal data from over the air. However, the attack (along with some MAC spoofing) allows the attacker to pose as an access point in order to inject a small amount of traffic into the stream. This traffic injection could be used to poison the client's ARP or DNS caches, redirecting the machine to an unintended (and possibly nefarious) destination.

"In the worst possible case scenario, the attacker can inject-pretending to be the access point-up to seven packets to the client," said Rick Farina, senior wireless security researcher at AirTight Networks. "The client will accept these as validly encrypted. You could cause all kinds of denial-of-service conditions by ARP spoofing, or you could probably convince the client to talk to a server on the Internet."

However, wireless users and administrators should not be fooled into thinking WPA2 equals safety from this attack. The WPA2 Wi-Fi certification standard includes both AES- and TKIP-based security as options, so wireless administrators must make sure that a WPA2-protected network only supports AES encryption in order to be safe from this attack.

Third, from what I gather, the mode of authentication used for a WPA with a TKIP network does not make a difference. This attack should work against TKIP-protected networks running either preshared key or 802.1x/EAP authentication, since the attack is going after the Pairwise Transient Key, which is used in both cases.

However, enterprise wireless administrators may be able to tune their networks to rekey at a faster rate than normal to thwart the attack (I've heard the attack authors recommend rekeying every 2 minutes). But wireless administrators should evaluate carefully whether the performance impact from this change is significantly greater than the impact derived from moving to AES encryption instead.

Also, since this is not a brute force attack, wireless administrators should be aware that the length of a preshared key does not make a difference with this attack.

Fourth, you may already have defenses in place to protect you from this attack. Companies using Wireless Intrusion Detection and Prevention technology, like that provided by AirTight Networks or Motorola's AirDefense unit, should have some protection from this attack right away. These systems can definitely identify MAC spoofing that would be used as part of an attempt to inject traffic.

Location detection tools could also be useful: Since the attacker has to pose as an access point, the system should throw up immediate warnings if it looks like an access point suddenly moved.

Presumably, WIPS vendors are right now cooking up new detections as well to help find and correlate any Michael errors that must occur as part of the attack. Since Michael errors are rare (it's pretty hard to accidentally change data payload without changing the checksum hash), a regular stream of Michael errors happening every 61 seconds or so should be easy to detect and send out an alert.

As a temporary workaround solution, TKIP enjoyed a remarkably good run without coming under serious threat. However, with this first attack now published (and early-generation tools using the attack, like aircrack-ng, available in the wild), undoubtedly TKIP will come under significantly more scrutiny in the months to come.

Consequently (fifth), even though the encryption is not yet broken, wireless administrators should start re-evaluating the use of WPA and TKIP. Many companies are already faced with some wireless upgrades to come into compliance with PCI 1.2, which last month finally put a timeline in place for retiring WEP as a security measure on wireless networks carrying sensitive data. For those companies needing to finally retire old scanners, bar code readers or other wireless mobile devices used for transactions, make sure to look for AES support on your next equipment investments.

Fortunately, most enterprise-grade equipment bought in the last four years will have support for AES. However, some patches may be necessary to get common client devices up to speed. Windows Mobile devices running versions prior to WM 6.1 may not offer AES support, so mobile administrators should investigate whether an upgrade is available.

Also, those who use the Windows XP and the Zero-Config wireless tool (but have not yet installed Windows XP SP3) will also need to install a patch to add AES support.

eWEEK Labs Senior Technical Analyst Andrew Garcia can be reached at agarcia@eweek.com.

Sursa: Cracking the WPA Security Standard

Edited November 14, 2012 by Nytro