The latest crack in wireless Internet security, specifically, the Wi-Fi Protected Access (WPA) security standard, can threaten the safety of enterprise networks and business-sensitive information or data. This tip shows the best way to avoid being victimized from this cryptographic attack, and explains the differences between WEP, WPA and WPA2, and how WEP cracking caused 802.11 standards to evolve.
It's been seven years since 802.11's Wired Equivalent Privacy (WEP) was cracked. WEP's first replacement, Wi-Fi Protected Access (WPA), has been required of all new Wi-Fi certified products since late 2003. But last month, reports surfaced about a crack in WPA -- specifically, a new attack against the Message Integrity Check (MIC) used by the Temporal Key Integrity Protocol (TKIP). While this new attack is not a death knell for wireless local area networks (WLANs) using WPA, it is a note-worthy chip in their armor that you can avoid.
How we got here
To get a handle on this latest attack, you need to appreciate the differences between WEP, WPA, and WPA2, and how WEP cracking caused 802.11 standards to evolve.
WEP uses RC4 to scramble (encrypt) data exchanged between wireless access points (APs) and clients, applying a Cyclic Redundancy Check (CRC) checksum to spot ...
To continue reading for free, register below or login
To read more you must become a member of SearchNetworking.com
errors. Anyone can record WEP-encrypted packets, but they cannot interpret them without the WEP key to decrypt them. Unfortunately, attackers quickly learned how to analyze WEP-encrypted packets to guess (crack) that key. Because the same WEP key is used by every client to encrypt every packet sent to a given AP, a cracked key can decrypt all future packets, no matter who sent them. As a result, WEP cannot really stop 802.11 data eavesdropping.
TKIP was created as a quick fix for older APs and clients that were crippled by WEP. Instead of using the same key to encrypt every packet, TKIP uses RC4 with a different key for each packet. These per-packet keys neutralize WEP encryption crackers. In addition, TKIP uses a keyed Message Integrity Check (MIC) to detect packets that are replayed or forged. Anyone can send (that is, inject) a TKIP-encrypted packet that has been captured and modified, but those packets are dropped because the MIC and checksum do not match the data carried by the packet. APs using TKIP usually transmit an error report when the first bad MIC is received. If a second bad packet arrives within 60 seconds, the AP stops listening for another minute and then "rekeys" the WLAN, requiring all clients to start using a new "pairwise master key" to generate both the MIC key and those per-packet encryption keys.
This plugged the gaping holes left by WEP. All WPA-certified products can use TKIP and its MIC to resist 802.11 data eavesdropping, forgery, and replay attacks. But even back in 2003, the IEEE knew there were more efficient and robust ways to provide this security. This is why 802.11i also defines a Cipher Block Chaining Message Authentication Code Protocol (CCMP) which uses the Advanced Encryption Standard (AES) to replace TKIP and its MIC. All Wi-Fi certified products must now support Wi-Fi Protected Access Version 2 (WPA2), letting customers choose the right security for their WLAN. WPA2-certified APs that talk to older clients may permit either TKIP or AES-CCMP, while those with new clients only can insist on AES-CCMP.
Challenging WPA's integrity
Those interested in cryptographic attacks and the math behind them are strongly encouraged to read Practical attacks against WEP and WPA published by researchers Martin Beck and Erik Tews and presented in November at PacSec 2008. Here in this tip, we'll just skim the surface to explain what this latest attack can and cannot do as a preface to how you can avoid becoming a victim.
Over the years, WEP crackers have gotten smarter, using new methods with curious names like Korek, PTW, and Chopchop to recover WEP keys much faster. In their November paper, Tews and Beck described how to apply a rapid Chopchop-style attack to recover not a WEP key, nor a TKIP pairwise master key, but a MIC key. An attacker who learns your MIC key could inject modified versions of certain TKIP-encrypted packets sent to wireless clients. For example, the attacker might send your clients a fake ARP response, causing them to misdirect packets to the wrong LAN device.
How does this attack work? The first step is to capture a TKIP-encrypted packet that contains data which is almost completely known. ARP messages work well because they are easily recognized and carry predictable data, except for the very last byte of the source/destination IP address -- and of course the MIC and the checksum.
Next, this encrypted packet is replayed, attempting to guess the right MIC and checksum. If the checksum is wrong, the AP assumes a transmission error and silently discards the packet. If the checksum is right but the MIC is wrong, the AP transmits a MIC failure report frame. This process must be repeated until the right MIC is guessed, at which point the attacker knows both the data and the MIC and can easily compute the MIC key.
But to be a practical attack, we must be able to guess that key quickly, without triggering defenses that would change that key. To avoid a rekey, we can send just one bad MIC per minute. However, on APs that support Wi-Fi Multimedia (WMM) Quality of Service (QoS), different counters apply to each priority level, allowing up to 8 bad MICs per minute (one per priority) without a rekey. Guessing all 12 unknown bytes (the MIC and the checksum) can thus be accomplished in a little over 12 minutes -- far less than the default rekey interval used by most WPA-certified APs.
Tews and Beck not only defined this method; they implemented a proof-of-concept attack tool called tkiptun-ng. One can use tkiptun-ng to recover the MIC key for a largely-known packet, and then use other aircrack-ng tools to re-inject modified versions of that packet which bypass WPA's integrity protection mechanism. Note that the recovered MIC key can only be applied to packets from the AP to the targeted client, until the next rekey. Furthermore, a MIC key cannot be used to eavesdrop on other TKIP packets -- that data is still protected by per-packet encryption keys.
Overcoming WPA attacks
Let's start with the obvious: The best way to avoid being victimized by this attack is to stop using TKIP. The MIC exploited in this attack is not used by CCMP, so your safest bet is to start using WPA2, configured to permit AES-CCMP only. This whitepaper on Deploying WPA and WPA2 in the Enterprise explains how to avoid WPA2 mixed mode, which enables coexistence of TKIP and AES-CCMP clients on the same named network (SSID).
WPA2 has been required in Wi-Fi certified products for so many years that insisting upon it may well be a viable option for many WLANs. If you've been depending upon normal equipment refresh cycles to migrate older clients away from TKIP, this new integrity attack may be the motivation needed to cut those old ties and drop TKIP entirely.
However, if your WLAN includes older WPA-only devices that cannot be readily replaced with WPA2-capable devices, there are still steps you can take:
- If your AP (or WLAN controller) provides an option to disable the MIC failure report, reconfigure your APs to do so. This integrity attack requires the MIC failure report to differentiate between a bad checksum and a bad MIC; turning the report off defeats the attack without having any other real impact on your WLAN.
- If your AP (or WLAN controller) provides a configurable WPA rekey interval, cut that interval to cause the pairwise master key to be updated before an attacker can guess the entire MIC key. Tews and Beck recommend using 120 seconds; Cisco recommends 300 seconds to reduce the impact on RADIUS servers in WLANs that use 802.1X (WPA-Enterprise).
- If your AP (or WLAN controller) provides an option to disable WMM or silently drop packets sent to unused priority levels, this could possibly extend the time required to guess the MIC key. But it wouldn't be enough to prevent the attack, and might not be a good security/functionality tradeoff for your WLAN.
To further limit the extra overhead caused by more frequent rekeys, you may want to start segregating WPA clients from WPA2 clients. Moving WPA clients to their own SSID may help you plan their retirement and make it easier to see which devices could potentially be exploited by an integrity attack.
You might even monitor those SSIDs a bit more closely for a spike in checksum and MIC errors involving a single client. These errors are a fact of life in WLANs and not by themselves a cause for alarm. However, it may not be long before wireless intrusion prevention systems (IPSs) are capable of spotting a tkiptun-ng attack signature.
Finally, bear in mind that WPA and WPA2 are not the only ways to ensure message integrity. Higher-layer VPN protocols like IPsec and SSL apply their own keyed message authentication codes to detect forgery. While higher-layer VPNs can't be applied to LAN broadcast packets like ARP, they can be used to safeguard all TCP/IP packets against integrity attacks, without relying on WPA integrity checks.
