The latest hole in WiFi security is quite serious, but it's unlikely to cause widespread disruption in the corporate and government networks for which it would have the potential to cause the biggest headaches.

In fact, the exploit continues to demonstrate a lack of any effective method of cracking the WiFi Alliance WPA/WPA2 certified versions of IEEE encryption standards found in WiFi gear of the past seven years. Brute force and dictionary attacks against short passphrases used typically on home and small-business networks are still the only means of key recovery.

As AirTight Networks' Dr. Kaustubh Phanse, the firm's principal wireless architect, said, "We are not talking about any key cracking; we are not talking about any brute-force authentication." An AirTight researcher documented this problem, and presented his results at a demonstration at Black Hat Arsenal and Defcon 18 this week in Las Vegas.

The so-called "Hole196," dubbed by its documenter at AirTight Networks, is a description and demonstration of a known problem, shown in its full glory. The exploit arises directly out of the IEEE 802.11i spec later incorporated into 802.11-2007, the latest complete version of the standard. This contrasts with a driver- or implementation-specific weakness.

After a briefing with AirTight and discussing the flaw with several security researchers familiar with it, it's clear that the bark is worse than the bite. It sounds bad, and is bad, but has little chance of becoming a new vector.

Let's start with the scope before I explain the hole.

The scope of Hole196


To take advantage of the exploit, an attacker must be an authorized user on a WiFi network using WiFi Protected Access security (WPA or WPA2 versions), which rely on TKIP (WPA) or AES-CCMP (WPA2) encryption key types. The key is not cracked in this exploit.

On networks that use a preshared key, as in WPA/WPA2 Personal, the attack is largely meaningless. Because each user shares the same key, a malicious user already has the means necessary to sniff the network to extract other users' temporal keys, and thus intercept all the traffic. And such networks aren't typically protected in any other fashion from simpler internal attacks, anyway.

Rather, this exploit has the potential to pierce through WPA/WPA2 Enterprise, which relies on the port-based access control protocol 802.1X. In 802.1X, a router (whether WiFi or an Ethernet switch) allows a client to connect in an extremely limited fashion to pass credentials. The switch or router blocks access to the rest of the network until credentials are authorized.

Those who deploy 802.1X can opt to require a simple user name and password combination, which becomes susceptible to brute-force attacks unless the system is monitoring for those, or social engineering ("hey, this is Jim from Accounting; what's my password again?), or even laziness—having account information written down where someone can find it.

Some corporations obviate the risk of unauthorized users logging in over 802.1X by relying on client-side certificates, which are issued uniquely and installed on laptops and other devices, and can't be forged. Two-factor authentication—where the account and password are supplemented by a regularly changing code displayed on a fob that the user must manually enter, or by a card that's swiped on a USB or integral card reader that has the same effect without displaying the code—is used much less commonly to protect login data.

The risk comes primarily from legitimate network users engaged in espionage, theft, or denial of service. Many attacks against corporate and government secrets come from inside a company, where protections are often drastically less than those at the demarcation with the Internet. This attack may add to the bag of tricks for such insiders, although there's still plenty to mitigate their ability to execute.

With those provisos in mind about who can exploit the hole, let's take a look at its innards.

Peering down Hole196

In a secured WPA/WPA2 Enterprise network, each user, when authenticated, has unique master key material generated for them. The master key is combined with random numbers from the authentication negotiation to create specific keys used for protecting packets, handling packet integrity to prevent spoofing and injecting, and other tasks.

But each client is also handed a Group Temporal Key (GTK). The GTK is required for clients to receive broadcast and multicast messages from the access point (AP). The GTK is identical for all users on a given BSSID (basic service set ID), which uses a number in the same format as a MAC address. A BSSID is unique for each access point; it's also unique for each virtual SSID on an access point, for companies that use multiple network names combined with virtual LANs to segregate traffic.

The AP is the only entity on the network that is supposed to emit packets encrypted by the

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.

The note explains that the pairwise temporal key (PTK), unique for each client (STA or station) on the network, can be used to validate that the transmitting address (TA) isn't being spoofed.



Data origin authenticity is only applicable to unicast data frames. The protocols do not guarantee data origin authenticity for broadcast/multicast data frames, as this cannot be accomplished using symmetric keys and public key methods are too computationally expensive.

GTK-encrypted broadcast packets thus can't be trusted. A client on a given BSSID can create and send broadcast packets encrypted via the GTK that the AP ignores, because it only sends and does not receive broadcast messages. The packets can have the AP's address as the transmitter, and all other clients will receive such packets without being able to authenticate whether the AP transmits them or not.

That allows a malicious authorized user to attempt ARP (Address Resolution Protocol) poisoning, which can be used to fool other clients on the network to transmit their traffic to a specified machine as a gateway instead of to the AP. (ARP messages are used to associated network MAC addresses with IP addresses. An attacker transmits unrequested broadcast messages to try to force a client to rewrite an internal cached table of such associations.)
WiFi "Hole196": major exploit or much ado about little?

Because every user has the GTK, and because the GTK can be used in this fashion, there's no protection against this misuse. "A malicious node presenting to the network also has possession of the GTK," said Md. Sohail Ahmad, a senior security researcher at AirTight responsible for documenting this weakness.

Once clients are compromised, those clients will use their own PTKs to encrypt traffic to the AP with a destination of the ersatz gateway. The AP will happily handle that client-to-client transaction, without the malicious party receiving any private key material, just as if the two clients were engaged in routine data transfer. "By injecting one packet and encrypting it with GTK, the malicious insider is able to decrypt traffic from a legitimate user," said Ahmad.

The fake gateway can capture, scan, and forward any cleartext information that would have gone across the network, which could include e-mail, files being transferred, and other internal network activity. While these kinds of tasks might be encrypted for remote access (using a VPN or client/server SSL session protection), it's not yet routine to protect these services inside a firm, although it's becoming more common.

ARP poisoning also allows DNS cache poisoning, and can be used to defeat certain SSL protections that rely on accurate DNS information. Many man-in-the-middle attacks benefit from a combination of a malicious gateway and poisoned DNS.

By using an over-the-air approach for ARP poisoning or similar broadcast-based attacks, in which the access point ignores the broadcast packet and it's not forwarded to the wired network segment, AirTight maintains that the attack is relatively undetectable by current intrusion protection and defense systems (IPS/IDS).

A few difficulties for the attack

But will this attack have a real impact on the enterprises that use it? The security experts I spoke to said that while Hole196 represents a legitimate concern, it doesn't buy attackers greater access than they would already have today, and comes with a few difficulties as well.

I can do the same attack by sitting down next to you and plugging into another port on your [Ethernet] switch. I can cause a wired system to cause all its traffic to redirect through me. This is the same attack, but through wireless.
For starters, beyond the requirement of being an authorized user or gaining illegitimate access to an account, an attacker has to be near an AP, and the attack only works on an AP-by-AP basis. Broadcasts are limited to the clients connected to an AP, and, even further, to a specific virtual SSID on a network that's divided for security or other purposes into multiple WiFi networks. (An outsider with insider credentials could use a high-gain antenna from further away, but that's not guaranteed to work, and might only allow communication with an AP, but not clients, which have weaker receive sensitivity.)

If a network uses client isolation, in which the AP declines to relay unicast traffic between two clients, then the GTK spoofing exploit can only be used for one-way exploits, AirTight noted. End-point security installed on individual computers can also be configured to note when certain flags are raised, including identifying potential ARP poisoning attacks, a sudden change in gateway, or malicious one-way attacks.

Pinning down the attacker might be difficult, since the originator address is spoofed, but because the attacker must be in proximity, or have compromised another machine associated with the AP, a company can find and shut down the source, even if that starts with disabling the AP.

Fundamentally, however, Hole196 sits between two network monitoring scenarios. In the first and more typical, a network isn't so highly monitored that ARP poisoning and other attacks happening via wired machines or via a WiFi client that's not using a GTK-encrypted broadcast would be noticed. Many corporations focus their efforts on the edge, and put less-trusted parties (like contractors and visitors) on separate VLANs and virtual SSIDs.

As Matthew Gast, the chair of the WiFi Alliance's Security Technical Task Group, said, "I can do the same attack by sitting down next to you and plugging into another port on your [Ethernet] switch. I can cause a wired system to cause all its traffic to redirect through me. This is the same attack, but through wireless." Gast is the director of product management at Aerohive, an enterprise wireless hardware firm.

The second scenario is a network that is so locked down and monitored that no one can lift a finger without that finger's motion being detected. In such a case, the initial GTK-based attacks might go unnoticed, but when a behavior change is affected, such as the ARP mapping changing or clients suddenly shifting their traffic to a gateway (which might be spoofing multiple IP addresses), that will trigger alarms.

In either case, Hole196 provides only one component of undetectability. With a less-monitored network, easier methods are available. With a heavily monitored network, anything beyond the initial steps will be spotted. "For every scenario I hear, it's more effective to bribe somebody, or use network access in a different way," Gast told Ars.

For most IT departments, Hole196 won't change the way you work, although you might check your various settings, and look into monitoring ARP poisoning a little more seriously in a general way, because changing ARP has become a fundamental approach in a large class of activities.

But unlike the Tews/Beck TKIP exploit we wrote about in November 2008 (see "Battered, but not broken: understanding the WPA crack"), which allowed spoofed short packet injections undetectably into TKIP-protected networks in certain circumstances, Hole196 seems unlikely to provoke any major changes in operations, systems, or specifications.

Despite all disclaimers I've made about the seriousness of this exploit's vector, every vendor of enterprise WiFi hardware and intrusion protection software and hardware will revise their offerings, and fast, to add tools or alerts to monitor for GTK abuse. It can't easily be patched, but it can be monitored relatively easily, because any client sending broadcast packets is now suspect