Saturday Jan 20
Smoke and Mirrors? The Upcoming Defcon WPA2 Crack
Updated on Tuesday, 31 January 2012 01:12

Okay folks. A lot of people have asked me about this over the past two days, so here’s my response on the WPA2 vulnerability that’s to be announced at BlackHat and Defcon next week.

As you may have heard at Black Hat and Defcon next week, AirTight Networks (a wireless security vendor) is doing a demo of a new WPA2 vulnerability that affects even 802.1X-authenticated networks. Of course, that piqued my curiosity as well so I did some digging and speculating. As a side note, I want to say I like AirTight and their products, so my response here addresses the vulnerability and is no reflection on the company itself.

Several press releases note the attack uses information of a vulnerability found on page 196 of the IEEE 802.11 wireless standard. Before I got there, I did a little guessing on various attacks that may be possible on 1X-authenticated networks.

Possible attacks:
– Compromise authentication server (AS) which participates in key distribution
– Compromise pairwise (individual station) keys
– Reuse of GTK (only for broadcast/multicast)
– Spoof AP or authentication server (AS) for MITM attack
– Implement an 802.1X EAP method which is insecure (ie EAP-MD5) and compromises the keys
– Attack on TKIP (versus CCMP)

Some of these possibilities seem unlikely, at best. For example, compromising the pairwise keys is virtually impossible. I would assume it’s not a TKIP attack since that’s old news. Looking at the list, if we jump to page 196 of the standard doc, we see the heading 8.5 Keys and Key Distribution . By the way, you can download the entire doc at the link below.

The documented vulnerability

Page 196, Section 8.5 Keys and Key Distribution
Under that section is this paragraph:

NOTE—Pairwise key support with TKIP or CCMP allows a receiving STA to detect MAC address spoofing and data forgery. The RSNA architecture binds the transmit and receive addresses to the pairwise key. If an attacker creates an MPDU with the spoofed TA, then the decapsulation procedure at the receiver will generate an error. GTKs do not have this property.


Background: Individual keys versus group keys

Before I explain the paragraph above let me give you a brief overview. With 802.1X there are private keys that are distributed and rotated per-user, per-session. Those are called pairwise keys and they’re used for unicast traffic, so traffic directly destined for that wireless client. There are also group keys (GTK) that are used for broadcast and multicast traffic. Those keys are shared for a group of wireless clients per SSID and used just like wired multicast to reach everyone at once.

The vulnerability in English

Now let me decode that paragraph for you. What it says is that pairwise (individual) keys used in 802.1X with both TKIP and AES encryption have a check in place to determine if the source (TA) is being spoofed or not. So, if an attacker pretends to be an AP and sends traffic, the wireless client will know. However, broadcast and mulitcast traffic sent using group keys (GTK) do not have a spoofing check. That means an attacker could use the group key and send a broadcast to other clients, posing as an AP and those clients won’t know the difference.

Assumptions of the attack

  • Attacker must be an 802.1X-authenticated user on your wireless network
  • Attacker must be on the same ESSID as the target(s)
  • Attack vector is limited to damage directly resulting from broadcasts/mulitcasts
  • A MITM attack (spoofing the AP) could only happen if:
    o the attacker can force a dissociation for users with the GTK
    o the group keys (GTKs) don’t refresh/change at the new association
    o the target stations are set to NOT check for server certificate for AS
    o or the attacker can falsify trust (ie push certificate) using broadcast

If the last line is true, then we may have some secondary issues to deal with and the implications could be more serious. We need to do some checking to see what all can be pushed via broadcasts with the group keys in order to understand the breadth of the attack possibilities.

The implications of the vulnerability

In my opinion, this vulnerability is of limited importance (for now). Without reading the entire 1,000+ pages of the standard again, my understanding is the threat is limited by the assumptions above. My personal feeling is this: If our attacker is an authenticated user on your enterprise network, meaning they’re part of your directory services and an employee most likely, then they have access to far more resources. Attacking data at the source, or even on the wired side where the packets are in clear text would be MUCH easier than launching this attack.


# # #