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.

Security Book Review: "Google Hacking for Penetration Testers - VOLUME 2"

"Google Hacking for Penetration Testers - VOLUME 2"
Authors: Johnny Long et. al.
Editorial: Syngress
Publication date: November, 2007
ISBN-10: 1597491764
ISBN-13: 978-1597491761



Summary: New updates and material for the second edition of the Google Hacking masterpiece. Volume 2 is today's reference.

Score: 4/5

Review:
This review mainly focuses on evaluating how valuable is to get a copy of "Google Hacking for Penetration Testers - VOLUME 2" if you already own a copy of the first edition, and the scores rates exactly that. If you don't have neither of them, I strongly encourage you to acquire Volume 2 (see details below), no matter what area of the information security field you work in (and specially if you are a penetration tester), as the contents affect to you in multiple ways. On my day-to-day security consulting practice, I'm still very surprised about how many IT people don't know about these techniques. The book is a masterpiece for information disclosure and mining from public sources, such as (but not only) Google. If I had to evaluate the book on itself, not comparing between editions, it would definitely get a score of 5/5.

The first edition was released in 2005 and opened the world of the Google Hacking techniques to the general public, together with the GHDB. The second edition title is (at least) confusing, as Volume 2 seems to denote it is a complementary book to the first edition. It is not, so I do not recommend you to get the first edition today. Volume 2, or the second edition as it should have been called, has been thoroughly updated (including most of the screenshots) to cover the latest changes and Google applications. I did a major update to the SANS "Power Search with Google" course on the first half of 2006, when some of the new Google functionality (not in the first edition) was already available. The second edition reflects those updates I identified and put back together then, even the tiny ones, such as the maximum search terms, that changed from 10 to 32. Additionally, all the statistical references, covering number of results returned by Google, and main contents have been reviewed and updated to reflect the current state of the art.

Some chapters have been kept from the previous edition (chapters 1 to 3, and chapters 6 to 9, and chapter 12), although they have suffered updates. Others have been moved (such as the old chapter 10, now chapter 4) or redesigned (like the new chapter 5). Besides, there are brand new chapters, like 10 and 11.

I specially like the updates on chapter 5, with the new tools and scripts to query Google and, specially, to parse and process the results, including several Perl and User-Agent tricks. The book, obviously, covers the Google API changes and provides solutions to overcome them, such as Aura. Chapters 6 and 8 include relevant updates to the Google code search engine and new capabilities to locate malware and binaries, plus new techniques to track down login portals and network embedded devices and reports, respectively.

The new chapter 10 is a great reference covering the new Google services from a hacking and "malicious" perspective. It is a required update given the pace Google releases new functionality and information sources, such as the AJAX capabilities and API, the source code search engine, calendar, blogger, and alert services.

The new chapter 11, "Google Hacking Showcase", includes the real-world Google Hacking samples and cases Johnny Long has been presenting in several hacking conferences during the last years. A found having a printed copy of it within the book very valuable, as it is an eye-opener, and it is a fun read. Definitely, if you have not seen Johnny's presentations and talks, I encourage you to access the archives from BlackHat and DefCon and enjoy them.

Finally, chapter 12 (the old chapter 11), covers new techniques and tools from a defensive perspective. The new additions increase the defender arsenal in order to mitigate the old and new threats covered throughout the book.

The influence of multiple authors in this edition is evident, something good for the new contents and material, but not so good for the chapter layout, as some do not follow the original format with a final summary, solutions, links and FAQ. Chapter 10 is a good example of both.

The complementary appendixes from the first edition, not directly relevant to the book topic from my perspective, have been removed. Overall, I feel some of the waffle has been left out, a smart decision (but not always easy) in order to keep the book size reasonable, and make room for the new contents.

I would like to see some of the pages that simply provide long listings from the GHDB moved to an appendix and simply referenced from the associated chapter. It might be useful to have these lists full of query samples on the book, but not just in the middle of a chapter. Another improvement would be to have a book webpage consolidating all the code samples, such as the Blogger submission script, as I'm not sure they are all available on a single website.

To sum up, if you don't have a copy of this book, go and buy Volume 2! (not to mention Johnny's involvement with charities). If you are a professional penetration tester, the new material in this second edition is highly recommended, so update your shelves and start applying the new contents on your daily practice. If you are an infosec pro, not directly involved in Google Hacking tasks, and you already own a copy of the first edition, I think you do not need Volume 2, as you already understand the threat, risks, and what is all this about.

At some point I was almost involved in co-authoring this 2nd edition, but finally it didn't happened. A pity, as definitely, this is one of today's reference books that should be on any infosec shelves.

UPDATE: Amazon review and Bookpool review (1st).