WPA/WPA2 encryption: A possible workaround

It seems using WPA or WPA2 is not as secure as we would like to believe. It's not the end of the world, but important enough to learn what's going on.

It seems using WPA or WPA2 is not as secure as we would like to believe. It's not the end of the world, but important enough to learn what's going on.


It's that time of year. Black Hat and Defcon are upon us and security gurus are anxious to tell the world about their research. Not sure why, but WPA/WPA2 Wi-Fi encryption is getting a lot of attention this year. For example, TechRepublic's Chad Perrin wrote a piece about Moxie Marlinspike's new WPA Cracker.


A possible WPA2 vulnerability is being aired at this year's Defcon and Black Hat conventions. AirTight's Md Sohail Ahmad is giving a presentation called WPA Too! The demonstration is about the newly-found Hole196 exploit. Strange name, I know. It's based on a note found on page 196 of the IEEE 802.11 Revised Standard published in 2007. The note at the bottom of the page provided Mr. Ahmad the clues he needed. It reads:

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

What does that mean?

Obviously, the people at AirTight are keeping tight-lipped about the exploit until after the presentations. Still, a few experts have come forward offering opinions as to what it all means. The main clue is the sentence:

"GTKs do not have this property."

The GTK or Group Temporal Key according to my CWSP study guide is used to encrypt all broadcast and multicast transmissions between the access point and multiple client stations. Glenn Fleishman of Wi-Fi Net News feels the Hole196 exploit will be used by malicious insiders leveraging the fact that errors are not detected when using GTKs:

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

Need to be inside

Everything I have read stresses that this exploit requires the attacker to be an authenticated user on the Wi-Fi network. That means WPA/WPA2 networks are still secure from attackers that do not have access credentials.

So it's an inside job. That should be less worrisome, right? Maybe not, according to the 2010 CyberSecurity Watch Survey, insiders accounted for 26 percent of all cybercrime. To make matters worse, a majority of the survey respondents agreed that insider incidents cost more to fix than external attacks.

What is possible

Okay, it's a problem. But what can a determined insider actually do? As Mr. Fleishman pointed out, the attacker could leverage some vulnerability and download malware onto unsuspecting computers. What's more likely though, is the stealing of sensitive data and PII.

Why is that? Up until now, individual users associated with a WPA2 Enterprise Wi-Fi network could not access Wi-Fi traffic belonging to other users. That's an important distinction. When using WPA2 Personal (preshared key), any authorized member of the network can sniff all in-range traffic. Mr. Fleishman points out why WPA2 Enterprise (802.1X with TKIP/AES-CCMP) is different:

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

It seems that's not necessarily true any longer. AirTight mentions:

"Unlike the TJX breach where data was stolen over unsecured Wi-Fi, this finding is concerning because organizations are relying on WPA2 for its strong encryption and authentication. Since there is no fallback in the 802.11 standard to address this hole, AirTight felt it was important to raise awareness around it."

Moreover, AirTight mentions that the exploit is not overly complex and uses available software tools:

"The Hole196 vulnerability can be practically exploited using existing open source software as the basis. And the footprint of such insider attacks is limited to the air, making them among the stealthiest of insider attacks known requiring no key cracking and no brute force."

Is there a solution?

Not knowing the exact details of the exploit make it difficult to develop solutions for Hole196. It appears the standard needs to be changed and firmware adjusted so a client station will not accept unverified GTKs from other client stations.

For now, if there is any concern, the best solution is to use a VPN tunnel within the encrypted-802.11 session. If an attacker is monitoring, all they would see is gibberish.

Road warriors beware

I see where Hole196 would be disconcerting to enterprise IT-security types. Disgruntled employees or anyone with network access could cause all sorts of problems. Some of which could result in financial hardship as described in a post by TechRepublic's Mark Underwood.

Still, I'm more concerned about what Hole196 might mean to road warriors or anyone using public WPA2-secured Wi-Fi networks. It's taken a long time to spread the word about the consequence of using open Wi-Fi networks. Now we have to start worrying about accessing WPA/WPA2 networks that we assumed were safe.

Here's an example. Recently, I stayed at a hotel offering secure Wi-Fi; which is unusual, but appreciated. One evening, while in the process of creating a web-site password, Chrome opened a message (Unencrypted Password Warning), alerting me that information was going to be sent unencrypted.

I stopped right there. Without the warning, I would have unknowingly sent the password in the clear. That's a problem. An unencrypted password traveling across the Internet is bad enough. Now with Hole196, my password could have been captured on what I assumed to be a secure portion of the route.

Final thoughts

I realize details about the Hole196 exploit are sketchy at this time and using VPN technology as a solution may seem a bit over the top. But, "better safe than sorry" is one saying that still makes sense.

AirTight has mentioned there will be a public Webcast about Hole196 on August 4 at 1100 PDT. If you are interested here is the link to register. I also plan to update this post as more information becomes available.