Industry Insider, Wireless, Zero Trust and NAC

Smoke and Mirrors? The Upcoming Defcon WPA2 Crack

July 23, 2010
4 min read
7 comments
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.

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.

Resources

# # #

FacebookXEmailLinkedIn

jj

Author, speaker, and recognized authority on network and wireless security architectures, Jennifer (JJ) Minella helps organizations solve technical problems and align teams.

View all posts

7 comments

  • Greg,
    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

    -jj

  • Matthew,
    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.

    -jj

  • 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)
    Greg
    “Security is like water. You can cup it in your hands and declare you have control – until you sneeze.” G. S. Guilmette

  • 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.

Let’s Connect!