Email Delivery

Receive new posts as email.

Email address

Syndicate this site

RSS | Atom


About This Site
Contact Us
Privacy Policy


November 2010
Sun Mon Tues Wed Thurs Fri Sat
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        

Stories by Category

Basics :: Basics
Casting :: Casting Listen In Podcasts Videocasts
Culture :: Culture Hacking
Deals :: Deals
Future :: Future
Hardware :: Hardware Adapters Appliances Chips Consumer Electronics Gaming Home Entertainment Music Photography Video Gadgets Mesh Monitoring and Testing PDAs Phones Smartphones
Industry :: Industry Conferences Financial Free Health Legal Research Vendor analysis
International :: International
Media :: Media Locally cached Streaming
Metro-Scale Networks :: Metro-Scale Networks Community Networking Municipal
Network Types :: Network Types Broadband Wireless Cellular 2.5G and 3G 4G Power Line Satellite
News :: News Mainstream Media
Politics :: Politics Regulation Sock Puppets
Schedules :: Schedules
Security :: Security 802.1X
Site Specific :: Site Specific Administrative Detail April Fool's Blogging Book review Cluelessness Guest Commentary History Humor Self-Promotion Unique Wee-Fi Who's Hot Today?
Software :: Software Open Source
Spectrum :: Spectrum 60 GHz
Standards :: Standards 802.11a 802.11ac 802.11ad 802.11e 802.11g 802.11n 802.20 Bluetooth MIMO UWB WiGig WiMAX ZigBee
Transportation and Lodging :: Transportation and Lodging Air Travel Aquatic Commuting Hotels Rails
Unclassified :: Unclassified
Vertical Markets :: Vertical Markets Academia Enterprise WLAN Switches Home Hot Spot Aggregators Hot Spot Advertising Road Warrior Roaming Libraries Location Medical Public Safety Residential Rural SOHO Small-Medium Sized Business Universities Utilities wISP
Voice :: Voice


November 2010 | October 2010 | September 2010 | August 2010 | July 2010 | June 2010 | May 2010 | April 2010 | March 2010 | February 2010 | January 2010 | December 2009 | November 2009 | October 2009 | September 2009 | August 2009 | July 2009 | June 2009 | May 2009 | April 2009 | March 2009 | February 2009 | January 2009 | December 2008 | November 2008 | October 2008 | September 2008 | August 2008 | July 2008 | June 2008 | May 2008 | April 2008 | March 2008 | February 2008 | January 2008 | December 2007 | November 2007 | October 2007 | September 2007 | August 2007 | July 2007 | June 2007 | May 2007 | April 2007 | March 2007 | February 2007 | January 2007 | December 2006 | November 2006 | October 2006 | September 2006 | August 2006 | July 2006 | June 2006 | May 2006 | April 2006 | March 2006 | February 2006 | January 2006 | December 2005 | November 2005 | October 2005 | September 2005 | August 2005 | July 2005 | June 2005 | May 2005 | April 2005 | March 2005 | February 2005 | January 2005 | December 2004 | November 2004 | October 2004 | September 2004 | August 2004 | July 2004 | June 2004 | May 2004 | April 2004 | March 2004 | February 2004 | January 2004 | December 2003 | November 2003 | October 2003 | September 2003 | August 2003 | July 2003 | June 2003 | May 2003 | April 2003 | March 2003 | February 2003 | January 2003 | December 2002 | November 2002 | October 2002 | September 2002 | August 2002 | July 2002 | June 2002 | May 2002 | April 2002 | March 2002 | February 2002 | January 2002 | December 2001 | November 2001 | October 2001 | September 2001 | August 2001 | July 2001 | June 2001 | May 2001 | April 2001 |

Recent Entries

In-Flight Wi-Fi and In-Flight Bombs
Can WPA Protect against Firesheep on Same Network?
Southwest Sets In-Flight Wi-Fi at $5
Eye-Fi Adds a View for Web Access
Firesheep Makes Sidejacking Easy
Wi-Fi Direct Certification Starts
Decaf on the Starbucks Digital Network
Google Did Snag Passwords
WiMax and LTE Not Technically 4G by ITU Standards
AT&T Wi-Fi Connections Keep High Growth with Free Service

Site Philosophy

This site operates as an independent editorial operation. Advertising, sponsorships, and other non-editorial materials represent the opinions and messages of their respective origins, and not of the site operator. Part of the FM Tech advertising network.


Entire site and all contents except otherwise noted © Copyright 2001-2010 by Glenn Fleishman. Some images ©2006 Jupiterimages Corporation. All rights reserved. Please contact us for reprint rights. Linking is, of course, free and encouraged.

Powered by
Movable Type

« Google Restarts Street View without Wi-Fi Scanning | Main | AT&T Continues Massive Increases in Wi-Fi Sessions »

July 22, 2010

Researcher Gives Clues about WPA2 Flaw

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.


I don't get it, Glenn. This looks like nothing new. Everyone has always known that the PTK is unique to each station MAC address and the GTK isn't. So one station can see another station's broadcasts. So what? Isn't a broadcast supposed to be seen by everyone anyway?

I really hope whatever they present isn't based on this so-called flaw.

This looks almost as bad as that Beck/Tews TKIP attack. If it is, let's at least hope that nobody buys it the way people fell for Beck/Tews.

This appears to be a method by which one client can fool another by employing a classic network attack that otherwise wouldn't work or would trigger network intrusion detection. However, it's strictly limited to authenticated users.

It sounds like this attack involves broadcasting data using the GTK, spoofing the MAC address of the AP, and then asking the other network stations to either change or reveal their PTK. Then the attacker will know the PTK of other stations and be able to decrypt traffic not intended to be seen by the attacker.

It doesn't even need to spoof the AP's BSSID. All a malicious attacker has to do is encrypt packets with the GTK. The AP ignores them, and other stations accept them. You can conduct any number of attacks in this manner, relying on ARP poisoning or malware-based weaknesses or what have you. The PTK isn't compromised. Stations that are compromised can continue to use their PTKs to send data to the AP which is relayed to the malicious station.

Why even spoof the GTK? Why not just send packets to other stations? I mean, if you're an authorized user can't you do that already?

You're not spoofing the GTK; you're just using it. Stations shouldn't be allowed to send broadcast messages using the GTK, but there's no mechanism to deal with that, so that's one problem.

You could send unicast packets to other stations, but you can't send broadcast packets that way to poison ARP and so forth. And the AP receives unicast packets, so these attacks would be much more likely to be noticed.

The point of highlighting this exploit seems to be to show that there's a hole in which the same kind of activities that could occur through a wired connection or through unicast messages (in different ways) can be more or less entirely invisible through this method to current ways of tracking and protection network communications.

It requires an insider (or pilfered credentials) and only works in proximity to a single AP and its associated stations. But it's a big hole in environments that are trying to have no potential hole.

ARP poisoning and other techniques could wind up happening either undetectably or untraceably, and traffic that was intended for the AP would be sent directly to a malicious station that could then make use of it. If you're relying on network protection for keeping data from one user from another, then you've suddenly got a big hole.

Yeah .. I am kind of suspicious about this myself. I work for a competitor of AirTight...and we see this kind of shenanigans from them all the time.

Maybe it is a legitimate issue...but its one that has been known about for years. AirTight always pulls this type of thing just to get noticed. They are still listed as Startup, so they have to do whatever they can to get Venture funding.

Not to mention, their attempt to trick people using a tool they claim they wrote to detect Wi-Phishing...which just ended up being a stripped down modified version of AirBase from AirCrack-NG. When testing the untouched version of AirBase side-by-side with their Wi-Phishing, I was able to see what they were up to. They simply were trying to trick potential customers into choosing them over AirDefense by triggering an alarm on their system using their Wi-Phishing tool that was coded specifically to not trigger any alarms on AirDefense. Considering AirCrack-NG is GPL, and they didn't release the full source code, further adds to my suspicion.

Anyway...I wouldn't trust anything coming from AirTight, as they don't have much of a track record of success when it comes to finding/verifying/demonstrating vulnerabilities.


I am a network administrator of a mid-size enterprise. In my opinion the problem in WPA2 which is uncovered by AirTight is very much legitimate. I was under the impression that WPA2 is pretty secure, but since it has been found vulnerable to insider attack, it has actually raised my concern. The fact that my WiFi network is WPA2 secured and also being used by contractors who could potentially exploit the vulnerability to compromise legitimate users, makes me really worried about the whole issue.

Thanks a lot for providing such a technical insight into the problem reported. I would really appreciate if you could also add some information on countermeasures.

Poor Jeff s. As he says, "I work for a competitor of AirTight" which pretty much says it all. You might want to look at all four of Gartner's Marketscopes on the subject of WIPS to understand the power of AirTight. No need to go into all the "shenanigans" AD has pulled. It is part of the public record.Seems like a long rant by a competitor.

Leave a comment