Sunday Sep 24
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.


# # #

  1. CommentsDigital Society » Blog Archive » New WPA2 vulnerability limited in threat   |  Monday, 26 July 2010 at 10:58 am

    […] of a WPA2 vulnerability from security vendor AirTight Networks.  Jennifer Jabbusch has some good analysis of the implications of this new […]

  2. Commentsjj   |  Monday, 26 July 2010 at 12:16 pm

    Sohail Ahmad shares more details about the WPA2 vulnerability:

    It looks like my guess was right. Now, my curiousity is in the receiving and use of PTKs received after the AP spoof using GTKs.


  3. Commentsjj   |  Thursday, 29 July 2010 at 9:42 am

    Nice FAQ from Network World, but it says pretty much what we’ve already covered here. My only reservation; he thinks client isolation would prevent this attack and I’m not sure that’s the case, since the traffic will appear to be from the AP. Once it’s rerouted the real AP won’t be between the attacker and victim machines, meaning it can’t enforce that filter.–wpa2-vulnerability-faq.html


  4. CommentsMatthew Gast   |  Thursday, 29 July 2010 at 7:45 pm

    Client isolation doesn’t prevent the attack, but it does prevent it from taking effect. After launching the ARP spoofing attack, the victim relays frames through the attacker via the AP. If the AP refuses to forward traffic from victim to attacker, there is no man in the middle.

    Granted, the victim can’t get network access and probably is going to call the help desk. However, preventing the man-in-the-middle attack is probably worth cutting off Internet access. The trouble call to the help desk will also likely identify the attacker’s MAC address — which on a wireless LAN with good security translates to a user name.

  5. CommentsGreg S. Guilmette   |  Thursday, 29 July 2010 at 10:27 pm

    Great write up JJ!
    It’s definately interesting to see the preceeding comment from Matthew Gast regarding the Client Isolation as this was an immediate question as I began reading about this attack yesterday. (For the record, I use AP isolation where ever possible by default)
    It seems that it wouldn’t be impossible to launch a man-in-the-middle attack against SSL client/server or SSL-VPN tunnels after the AP attack is completed. To me, this is of more significance, (if it’s actually possible), since critical data could be aquired while clients are assuming they are secured on a managed and authenticated AP network.
    JJ, you do have a excellent point regarding the level of difficulty to perform this attack vs. the low hanging fruit a person already capable of accessing business data – they are insiders at this point, as you noted. On the flipside, if there are elevated security measures in the core of the company, aquiring the login credentials to impersonate an executive or administrator that’s connecting to a WiFi AP just became a little easier and ,possibly , has now become the lower hanging fruit.
    I’ve seen solutions that would use more secure IPSEC Clients to a backend VPN Gateway, but this will add to an entrprise I.S./I.T. budget and complexity as it’s not going to be a good solution for a guest network. (Security vs. Usabilty)
    “Security is like water. You can cup it in your hands and declare you have control – until you sneeze.” G. S. Guilmette

  6. Commentsjj   |  Thursday, 29 July 2010 at 10:45 pm

    Thanks for sharing! I still feel some strange lingering feeling that there may be a way around it, but I can’t think of a technical explanation or scenario that would make it possible. If you can’t think of anything, then I feel safe to say the client isolation would prevent that part of the attack and render the rest useless.


  7. Commentsjj   |  Thursday, 29 July 2010 at 10:46 pm

    Wise words my friend!
    “Security is like water. You can cup it in your hands and declare you have control – until you sneeze.” G. S. Guilmette


Leave a Reply