November 08, 2008

WPA/TKIP ChopChop Attack

Probably at this point you have heard that "WPA has been cracked" all over the Internet and the Blogosphere. As the specific details will be fully disclosed on PacSec 2008 next week, and in an upcoming whitepaper on the aircrack-ng website (check it during the weekend or early next week), I considered relevant to provide technical details (summarizing facts) about what's going on and clarify some of the FUD out there.

UPDATE: The "Practical attacks against WEP and WPA" whitepaper has been released (08/11/2008 - 21:00 CET). The paper mentions the attack could be run on non-QoS wireless networks, although no extra details are provided.

First of all, you have a technical overview on this post (thanks Erik for the reference), and thanks to Della Lowe and Rick Farina (from AirTight Networks) for the early warning notification, spreading the word to create awareness on the community, and the detailed technical conversation we had about the topic, respectively.

Why is this relevant? Because it is the first cryptographic attack against WPA(2), and TKIP specifically. Previously we only knew about dictionary attacks on WPA or WPA2 pre-shared keys (Personal mode), or RADIUS impersonation attacks in Enterprise mode.

The attack:
  • This security research has been discovered by Erik Tews (the T on the PTW WEP attack) and Martin Beck, members of the aircrack-ng team.
  • The new attack only affects the TKIP encryption algorithm used by WPA (and WPA2, optionally).
  • The attack allows an attacker to decrypt individual 802.11 wireless frames, similarly to the old WEP chopchop attack, as it discloses the keystream (or PRGA), that is, the cryptographic material used to encrypt a single wireless frame.
  • The attack also allows to inject new frames using the info of the disclosed keystream and other tricks (see below).
  • The keystream is disclosed by attacking the integrity algorithm (MIC) used in TKIP, called Michael.
  • TKIP implements specific built-in countermeasures around Michael to avoid frame manipulation, and blocks replay attacks using sequence number enforcement.
  • The attack takes advantage of the message notification about MIC failures in order to identify valid injected frames, in the same way the WEP chopchop attack used the ACK frames to confirm valid frames.
  • Frames can only be injected when the wireless multimedia extensions (802.11e or WMM) are used, as these allow to break the sequence enforcement mechanism. The injected (and forged) frame is sent over a different QoS queue. This effectively limits the amount of injected frames that can be sent (around 7).
  • Some access points, or standards like 802.11n, require WMM. It cannot be disabled. The 802.11n standard does not accept TKIP, but some 11n vendors allow you to enable it.
  • The attack combines the new chopchop techniques, plus the QoS queue change, to decrypt and inject new frames. This is were the meat of the research and whitepaper is!
  • The attack only allows to decrypt and inject frames that go from the AP to the client, as the client generates the MIC failures (required to confirm the validity of an injected frame).
  • The current research allows to decrypt the frame at a rate of about one bit per minute on average, that is the reason why the current attack is effective against small packets, such as ARP, DNS, or TCP SYN packets. However, spending a bigger amount of time it would be possible to decrypt larger packets.
  • Every time a new valid frame is injected (confirmed by the generation of a MIC failure message), a new bit value is discovered (like in chopchop), but with TKIP, the attack must stand-by for 60 seconds in order not to trigger the Michael countermeasures, what will renew the keys (and invalidate the attack).
  • The reason why it is being said that it takes 12-15 minutes (or 900 seconds) is because the goal of the sample test is to decrypt two bytes (16 bits) of an IP address (considering the other two bytes are known, subnet portion on a class B) inside an ARP packet.
  • By looking at the source code of the PoC tool, it checks the IP private address ranges: 192.168, 10.x (10.0), 172.16-31 (172.16).
  • For those interested on the in-depth technical details (see the source code), there is a new tool that implements the attack, called tkiptun-ng, and it is available on the aircrack-ng SVN repository (current copy, rev.1208).

This new research opens the door to new WPA(2)/TKIP attacks and future enhancements, so it is time to start applying and planning the appropriate security countermeasures to remove or mitigate this and similar future threats.

The countermeasures (for wireless vendors, businesses, and end users):
  • [users and businesses] Switch to AES and WPA2, as more TKIP attacks are going to come! AES is the best solution (if your equipment supports it, mandatory since 2006 from a WiFi Alliance perspective) as it is more efficient and secure than TKIP.
  • [vendors] There are a few ideas around to fix the vulnerability from a TKIP perspective:
    • Rotate keys every two minutes, but this will have a significant performance impact, specially on the devices that do not support AES (with limited hardware capabilities). [1]
    • Don't send the early warning message notifying about the first MIC failure, what will break the current 802.11i standard.
    • Activate the MIC countermeasures with a single MIC failure, what will break the standard again, and activate the built-in DoS capabilities within TKIP in non-evil scenarios where a single packet has an invalid MIC. Very risky!
  • [businesses] If your hardware do not support AES and cannot be easily replaced, complement the security mechanism provided by TKIP encryption with other capabilities, such as detection. This attack generates a significant amount of MIC failure messages that must be detected by your wireless IDS (WIDS).
[1] This reminds me about the old (and almost useless) Dynamic WEP (DWEP) implementations.

Remember, TKIP was a temporary solution to mitigate WEP security issues. It is time to switch to AES, so start planning the migration now!

NOTE: If there is an incorrect statement above, as all the details are not known yet, please let me know in order to clarify or fix it.



Blogger Bill said...

As I read it, your article suggest the problem is primarily with TKIP. Is WPA with AES still safe?


5:25 AM  
Blogger Raul Siles said...

Hello Bill,
YES, at this point AES is safe, as the new attack exploits a vulnerability in TKIP, specifically in its message integrity check (MIC) algorithm, called Michael, and the countermeasures TKIP implements to protect it.

AES does not uses Michael as its MIC, but an AES crypto checksum instead (AES can be used for encryption AND hashing), and therefore, does not implement the countermeasures either.

11:30 AM  
Anonymous Anonymous said...

already on the article can be read.

8:45 PM  
Blogger Zheng said...

After a (short) keystream has been recovered, is it possible to use the Arbaugh inductive attack (inverse chopchop) to expand the keystream? It'd be an extremely slow expansion though, 1 byte per >60 seconds.

3:59 AM  
Blogger Raul Siles said...

Zheng, potentially, expanding the attack as you suggest (as we saw in WEP long time ago) might be an option.

It has not been demonstrated yet, but definitely, more enhancements and improvements to this attacks are coming on the next weeks and months. In fact, the authors are already working on new extensions.

9:57 AM  
Anonymous Ivars said...

You forget one important and efective countermeasure against WPA(2)+TKIP attack...VPNs. For example, OpenVPN 2.1 "hides" all vulnerable arp and dns packet in udp1194 traffic and and attack stops...attacker discover short rc4 keystream, but he nothing to do with this keystream, arp,dns or icmp injection doesn't work due VPN encryption in higher osi layer.

8:09 AM  
Blogger Raul Siles said...

Ivars, I agree with you that VPNs help to mitigate this type of threats that attack the WiFi encryption mechanisms.

However, you still must consider some risks of using VPNs over WiFi, such as for example the period till the VPN is established. While the VPN is not active (and unfortunately there are at least a few seconds since your wireless card is active and your VPN tunnel is on), you are exposed to, let's say, ARP spoofing attacks.

12:31 PM  
Anonymous Jim said...

What about using the cipher: AES CCMP + TKIP on WPA. Should I remove the TKIP and just keep AES CCMP.

11:02 PM  
Blogger Raul Siles said...

When vendors refer to AES CCMP + TKIP on WPA it typically means the setup supports both protocols, AES and TKIP, and therefore you can be vulnerable when TKIP is used.

I recommend you to leave AES only, or much better, use WPA2/AES instead.

12:04 AM  
Anonymous Ramkumar said...

Awesome post !!!

11:47 AM  

Post a Comment

<< Home