Debunking A Vulnerability Myth (Not That One...)
The Wi-Fi world was set aflutter today by a wireless IDS/IPS vendor sending out a press release advertising a flaw in WPA2 security that will be detailed during a pair of security conferences at the end of the month. (They're also holding a Webinar early next month that will detail the same flaw.) Much of the commentary on this WPA2 vulnerability has been focused on discrediting its real-world impact, but I am going to abstain from my initial temptation to join those critics. Instead, I'll take this time to discredit a supposed flaw in TKIP that was touted a couple of years ago, but for some reason never analyzed thoroughly.
The TKIP flaw has been nicknamed Beck/Tews after the researchers that discovered it. Their whitepaper and an excellent analysis of the technical theory behind the flaw by Glenn Fleishman of the superb WiFiNetNews.com blog are both available online.
A quick summary of the flaw goes something like this:
TKIP relies on a sequence counter called the TSC (TKIP sequence counter) to prevent packet re-injection. If packets are received with a TSC value at or below the TSC value of the previous packet, then they are dropped. This sequence counter prevents ChopChop-style attacks from being successful at recovering TKIP keys in a similar way to how ChopChop recovers WEP keys. (WEP does not have a sequence counter.)
Beck and Tews noticed that when 802.11e QoS (also known as WMM, or Wi-Fi Multimedia) is used, packets can theoretically be re-injected because APs may allow up to 16 separate sequence counters, one for each Traffic ID. The idea is that if a savvy attacker kept changing Traffic IDs, he could circumvent the TSC by never re-injecting a packet using a Traffic ID that is at a lower sequence counter value than the previous packet. Beck and Tews detailed a "practical" (ironic use of that word, to be sure) analysis of this theoretical attack online, though they accidentally stated that there are 8 separate Traffic IDs rather than 16 (a fact that is irrelevant to whether the attack works).
The problem with Beck and Tews is that it appears that these gentlemen have never actually looked at a packet capture. If they would have, they'd know that APs never actually use 16 sequence counters. Or 8. Or even 4. In fact, APs never use more than one TSC. I know this because I have actually done practical WiFi sniffing.
Take a look at this Beacon frame* that I captured using (gasp) Wireshark with KisMAC and a DWL-G122 USB adapter while running Mac OS X 10.6.4:
Take a look right above the line I highlighted. That line shows the PTKSA (pariwise transient key) Replay Counters field of the RSN (robust security network) information element in a Beacon frame from an AP using WPA2 and QoS. Check out the value there: 0. And check out table 7-35 on page 128 of the IEEE 802.11-2007 standard:
When the PTKSA Replay Counters value is 0 -- which it always is in every Beacon from every AP I've ever seen -- there is only one TSC value. One TSC value means that there is only one sequence of numbers in packets. One sequence of numbers means that any packet re-injection will result in re-injected packets being dropped. Re-injected packets being dropped means that the Beck/Tews vulnerability in TKIP simply does not exist.
Look, I realize that I have not seen Beacons from every AP that has ever existed. And I realize that security researchers sometimes make mistakes. But can we at least have some scrutiny of something that could be this big? TKIP is used on countless WiFi networks. Is nobody out there sniffing WiFi packets to make sure that theoretical vulnerabilities are practical vulnerabilities?
There have been an awful lot of papers and articles written that have taken the flawed Beck/Tews research as gospel. That's what happens when someone uncovers a new attack that is theoretically sound. My hope is that when this WPA2 flaw is revealed later this month, people will consider whether the theoretical insightfulness is matched with practical applicability.
*I couldn't fit the QoS-based information element from the Beacon into my screenshot, but that AP is using QoS. It also is using AES encryption rather than TKIP, but the choice of encryption type has no bearing on the PTKSA Replay Counters value.
The TKIP flaw has been nicknamed Beck/Tews after the researchers that discovered it. Their whitepaper and an excellent analysis of the technical theory behind the flaw by Glenn Fleishman of the superb WiFiNetNews.com blog are both available online.
A quick summary of the flaw goes something like this:
TKIP relies on a sequence counter called the TSC (TKIP sequence counter) to prevent packet re-injection. If packets are received with a TSC value at or below the TSC value of the previous packet, then they are dropped. This sequence counter prevents ChopChop-style attacks from being successful at recovering TKIP keys in a similar way to how ChopChop recovers WEP keys. (WEP does not have a sequence counter.)
Beck and Tews noticed that when 802.11e QoS (also known as WMM, or Wi-Fi Multimedia) is used, packets can theoretically be re-injected because APs may allow up to 16 separate sequence counters, one for each Traffic ID. The idea is that if a savvy attacker kept changing Traffic IDs, he could circumvent the TSC by never re-injecting a packet using a Traffic ID that is at a lower sequence counter value than the previous packet. Beck and Tews detailed a "practical" (ironic use of that word, to be sure) analysis of this theoretical attack online, though they accidentally stated that there are 8 separate Traffic IDs rather than 16 (a fact that is irrelevant to whether the attack works).
The problem with Beck and Tews is that it appears that these gentlemen have never actually looked at a packet capture. If they would have, they'd know that APs never actually use 16 sequence counters. Or 8. Or even 4. In fact, APs never use more than one TSC. I know this because I have actually done practical WiFi sniffing.
Take a look at this Beacon frame* that I captured using (gasp) Wireshark with KisMAC and a DWL-G122 USB adapter while running Mac OS X 10.6.4:
Take a look right above the line I highlighted. That line shows the PTKSA (pariwise transient key) Replay Counters field of the RSN (robust security network) information element in a Beacon frame from an AP using WPA2 and QoS. Check out the value there: 0. And check out table 7-35 on page 128 of the IEEE 802.11-2007 standard:
When the PTKSA Replay Counters value is 0 -- which it always is in every Beacon from every AP I've ever seen -- there is only one TSC value. One TSC value means that there is only one sequence of numbers in packets. One sequence of numbers means that any packet re-injection will result in re-injected packets being dropped. Re-injected packets being dropped means that the Beck/Tews vulnerability in TKIP simply does not exist.
Look, I realize that I have not seen Beacons from every AP that has ever existed. And I realize that security researchers sometimes make mistakes. But can we at least have some scrutiny of something that could be this big? TKIP is used on countless WiFi networks. Is nobody out there sniffing WiFi packets to make sure that theoretical vulnerabilities are practical vulnerabilities?
There have been an awful lot of papers and articles written that have taken the flawed Beck/Tews research as gospel. That's what happens when someone uncovers a new attack that is theoretically sound. My hope is that when this WPA2 flaw is revealed later this month, people will consider whether the theoretical insightfulness is matched with practical applicability.
*I couldn't fit the QoS-based information element from the Beacon into my screenshot, but that AP is using QoS. It also is using AES encryption rather than TKIP, but the choice of encryption type has no bearing on the PTKSA Replay Counters value.
So, this begs the question, how do stations handle high priority frames that get sent to the MAC layer after a lower priority frame that is still queued for delivery? I always thought that's why each WMM access category had separate counters, so the high priority frame could be sent first and then send the lower priority frame with a lower sequence number later from a different queue. Any thoughts?
ReplyDeletePriority is orthogonal to sequence numbering because upper layers can typically assemble data correctly no matter what order it's sent in at the MAC. That's a reason that the Order bit now just means 802.11n.
ReplyDeleteHi Ben,
ReplyDeleteNice to see you talking about "Hole 196", a vulnerability in WPA 2. Don't want to spill the beans now but FYI, unlike WPA-TKIP vulnerability which was bit complex, this one is very simple to exploit.
If you are planning to attend the Blackhat or the Defcon this year, you would probably not want to miss the demo and clear your doubt.
-Sohail, AirTight Networks
Sadly, it seems that the WPA IE do not include the field you mentioned, and most people using TKIP are using WPA, not WPA2. And right now in Wireshark I am looking at an RSN IE that has this line:
ReplyDelete.... .... .... 11.. = RSN PTKSA Replay Counter capabilities: 16 replay counters per PTKSA/GTKSA/STAKeySA (0x0003)
And yes TKIP is listed as a cipher suite.
But thanks for this tip.
Look carefully at Your wireshark packet dump: Here is AES (CCM) cipher suites for multicast and unicast traffic encryption. Beck-Tews attack works against WPA TKIP encryption only.
ReplyDeleteSo the problem is that they missed practial tests to determine if it actually happens. That should ne determined by how vendors implement the standard. As you have stated "I realize that I have not seen Beacons from every AP that has ever existed".
ReplyDeleteNevertheless, being a theorical research topic as it is, it addresses a security vulnerability that should be fixed and therefore, it still has an important value.
My point can be clarified with an example: Imagine that a study shows that a standard for assembling cars shows that there's a theorical issue in the assembly process. Don't you think that even though you realize none of the car manufacturers actually make that mistake, you STILL need to change the standard because of the assembly issue?
Sohail: Stop spamming.
ReplyDeleteYuhong: TKIP is only vulnerable if WPA2 is used, not WPA. Since WPA has only one TKIP sequence counter it is not vulnerable.
Vertigo: The structure of the RSN IE is the same for AES and TKIP.
Wirelezz: I never said otherwise.
To clarify for everyone...
WPA2 TKIP is vulnerable, but only if QoS is used AND if the PTKSA Replay Counter is > 0.
WPA TKIP is not vulnerable.
One final update is that I finally found a case where the PTKSA Replay Counter can go above 0. In Cisco WLCs if you use multiple SSIDs, then the PTKSA Replay Counter > 0. That means if you are using a WPA2 TKIP network with QoS on a Cisco WLC, you should use only one SSID.
This comment has been removed by the author.
ReplyDelete