AirTight Networks' researcher Md Sohail Ahmad will present a WPA2 weakness primarily a problem on 802.1X networks at DEFCON18 next week: The press release from AirTight doesn't give away too many details, but I can read the tea leaves to figure out where the problem lies. There's just enough of a hint.

The problem appears restricted to WPA Enterprise (802.1X with TKIP/AES-CCMP) in practical terms, because a malicious user must have legitimate credentials to gain access to the network to exploit the flaw. With WPA/WPA2 Personal (preshared key), everyone on the network ostensibly can sniff for other users' data.

But with the 802.1X mechanism used in WPA/WPA2 Enterprise, each user after authentication receives unique keying material that renders his or her data opaque. Or does it?

AirTight said in its press release that the problem Ahmad identified is found in the name it gave the exploit "Hole 196": that refers to the last line of page 196 of the revised IEEE 802.11-2007 specification.

I digitally flipped through my copy of the spec, and found a note at the bottom of the page in question, in a section on Robust Security Network Association (RSNA) used for the 4-way handshake for authentication dealing with the group temporal key (used to protect broadcast and multicast data). It reads:

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

Reading that with the notion in mind that there's an exploit around it points strongly to a way in which a malicious client could exploit this and create spoofed broadcast or multicast packets appearing to come from the TA (transmitting address) of the access point that other clients would receive. Those spoofed packets would have the advantage of coming across the same trusted network, and could contain malicious payloads and attacks.

This could be a serious exploit for corporations, government, and academic institutions that use 802.1X, and rely on the intra-network security of having one user unable to sniff the traffic of any other user. No key cracking appears involved at all; it's entirely about the position of the offending client within the network.

It seems like the fix for this would require an AP somehow sign a GTK packet so that a station (client and adapter) wouldn't accept GTKs on a network from another station. That seems like more infrastructure and a major change, although it could be incorporated into an EAP method that relies on AP/server-side certificates.

I'm sure Cisco, Juniper, and others will be all over this, because it affects their core client base. The risk isn't from outside attack, so it's not an immediate concern that script kiddies will drive up to corporate networks to attack them. Rather, it's part of ongoing mitigation of risks from employees inside a company misusing or stealing data or causing grief.

In the short run, using a VPN tunnel within an 802.1X session might allow malicious disruption but not data interception. Unless, perhaps, DNS poisoning and SSL/TLS certificate authority spoofing were involved.