Well as it tends to be, when something is scrutinized for long enough and with enough depth flaws will be uncovered. This time the victim is WPA2 – the strongest protection for your Wi-fi network which is standardized.
WEP fell long ago and there’s a myriad of WEP Cracking tools available. In 2008 it was reported flaws had been found in WPA and it was partially cracked.
These factors of course shifted a lot of people to WPA2, which has now been found to have certain flaws.
Perhaps it was only a matter of time. But wireless security researchers say they have uncovered a vulnerability in the WPA2 security protocol, which is the strongest form of Wi-Fi encryption and authentication currently standardized and available.
Malicious insiders can exploit the vulnerability, named “Hole 196” by the researcher who discovered it at wireless security company AirTight Networks. The moniker refers to the page of the IEEE 802.11 Standard (Revision, 2007) on which the vulnerability is buried. Hole 196 lends itself to man-in-the-middle-style exploits, whereby an internal, authorized Wi-Fi user can decrypt, over the air, the private data of others, inject malicious traffic into the network and compromise other authorized devices using open source software, according to AirTight.
The researcher who discovered Hole 196, Md Sohail Ahmad, AirTight technology manager, intends to demonstrate it at two conferences taking place in Las Vegas next week: Black Hat Arsenal and DEF CON 18.
It’s a pretty interesting attack and leverages a man-in-the-middle style exploit to decrypt data from the wire and inject malicious packets onto the network.
The researched Md Sohail Ahmad is going to demo the exploit at 2 upcoming conferences (Black Hat and DEF CON 18) so I’ll be looking out for the slides and videos on that. We’ll have to wait and see if this is another ‘mostly theoretical‘ attack – or something that can actually be implemented in the wild.
The Advanced Encryption Standard (AES) derivative on which WPA2 is based has not been cracked and no brute force is required to exploit the vulnerability, Ahmad says. Rather, a stipulation in the standard that allows all clients to receive broadcast traffic from an access point (AP) using a common shared key creates the vulnerability when an authorized user uses the common key in reverse and sends spoofed packets encrypted using the shared group key.
Ahmad explains it this way:
WPA2 uses two types of keys: 1) Pairwise Transient Key (PTK), which is unique to each client, for protecting unicast traffic; and 2) Group Temporal Key (GTK) to protect broadcast data sent to multiple clients in a network. PTKs can detect address spoofing and data forgery. “GTKs do not have this property,” according to page 196 of the IEEE 802.11 standard.
These six words comprise the loophole, Ahmad says.
The upside is that the attack is limited to people who can genuinely authenticate to the network first, the downside that means large organizations using WPA2 in trouble – as generally most damage comes from the inside.
It’s also something to think about when connecting to ISP/public Wi-fi hotspots using WPA2 encryption.
I’m sure there will be more news about this soon.
Source: Network World (Thanks Austin)
Jeff S. says
I would do more research before regurgitating that which is old news, can’t be done the way they described, and comes from a company that is still listed as a Startup (after 6+ years of being in business).
There is no way that a client will respond to GTK broadcast/multicast with a PTK encrypted response. Not without sending data through the associated AP, which would essentially get dropped due to mis-matching destination address (the AP would do this, not GTK). A De-Authentication would need to be sent via GTK to try and get clients to re-associate to a SoftAP/AdHoc controlled by the insider threat (which would most likely trigger some sort of alarm related to DDoS). GTK is broadcast/multicast and therefore cannot be directed at a single client.
The enormous amount of work involved makes this a very un-attractive attack…first you have to be inside the network and authenticated (thus you are probably an employee). Then you have to do all of these broadcasts in such a way that you are not detected by IT Security. Then you would have to use social engineering to get a single client to associate to your controlled SoftAP in order to get true associated and encrypted data from the client. Then you have to provide routing to the Corporate network to reduce suspicion … not easy to do on a monitored network with proxies etc.
Here is more information … though still a lot of guessing going on, instead of testing and verifying. http://securityuncorked.com/2010/07/smoke-and-mirrors-the-upcoming-defcon-wpa2-crack
The IEEE group is not made up of idiots…considering this supposed vulnerability has been on the books since 2007. Do you really think someone more reputable would have noticed and said something?
—
Jeff
Darknet says
I agree, that’s why I believe it’s an attack based on theory rather than something that is practically applicable.
Either way it’s relevant again now as it’s going to be presented at 2 upcoming conferences.
Jeff S. says
Oh yeah … what you say here: “It’s a pretty interesting attack and leverages a man-in-the-middle style exploit to decrypt data from the wire and inject malicious packets onto the network.”
Wired traffic is not encrypted if you are already inside the network…which makes doing all this work to get information from a Wireless client ridiculous. Because an insider-threat would already have direct, unencrypted access to the direct source.
—
Jeff
j says
My take on it at this time is: don’t panic and wait for the full details to emerge, especially because the wordings coming out of different news sites appear to be confused and somewhat contradictory (as usual, because reporters don’t understand protocols :) ).
For example, http://www.networkworld.com/newsletters/wireless/2010/072610wireless1.html says:
(i) “Because a client has the GTK protocol for receiving broadcast traffic, the user of that client device could exploit GTK to create its own broadcast packet. From there, clients will respond to the sending MAC address with their own private key information.”
and
(ii) “The Advanced Encryption Standard (AES) derivative on which WPA2 is based has not been cracked and no brute force is required to exploit the vulnerability, Ahmad says. Rather, a stipulation in the standard that allows all clients to receive broadcast traffic from an access point (AP) using a common shared key creates the vulnerability when an authorized user uses the common key in reverse and sends spoofed packets encrypted using the shared group key.”
For (i), under the WPA & WPA2 protocol specifications, the PTK (which contains the KCK, KEK and TK2 1 & 2) is CREATED INDEPENDENTLY by the Client and by the Authenticator (the AP) for their own respective uses as a result of the WPA 4-way handshake in which EAPOL frames are exchanged. The PTK is *NOT* transferred across the air – the data frames going across the air are encrypted using the TKs and NOT the PTK. In addition, the GTK itself requires the KEK before it can be derived on the Authenticator and distributed to all clients using their respective KEKs. I therefore fail to see how the reporter can conclude a client will pass its PTK (KCK, KEK, TK1 & TK2) to anyone else in violation of the protocol operation.
For (ii), the key word is “authorized user”. Based on the information currently available, the vulnerability description does not appear to indicate susceptibility to an unauthenticated attack but rather attacks by users who are ALREADY authenticated to the wireless network. The attack appears to be aimed at getting other users to reveal certain information (the details of which are not yet revealed) embedded in the frames encrypted with the TKs by issuing spoofed AP-originating broadcast traffic (again, the details of which have not yet been revealed). Since the TKs (from the PTK) are all unicast only and only go to the AP, this deduction is logical because the reports indicate that the attacker is spoofing as the AP.
If i was an internal attacker who is already associated legitimately with the wireless network, i would not even bother wasting time trying to crack another client’s unicast encryption (which is afforded by the TK) between the client and the AP.
No, i would follow the attacker’s standard mindset in following the path of least resistance and go straight for an ARP-poisoning attack and bypass the L2-unicast-encryption defence because how many people implement static MAC-IP ARP entries for every host and every router ? :)
And if i wanted to see unencrypted higher layer traffic (e.g. HTTP), i’d just sniff in conjunction with the above. Since i am already authenticated/authorized, every frame going across the wireless network in the location where i (the attacker) am located at would be open for interception if i am sitting in the middle. The fact that a user is sending data encrypted to the AP is irrelevant if i as an already-authenticated-user can use other protocols and a standard L3 sniffer operating in promiscuous mode to achieve the same goals of seeing confidential traffic.
Example 2: http://blogs.pcmag.com/securitywatch/2010/07/spoofing_hack_against_wpa2_rev.php says “Complete details of the attack, designated “Hole 196″ by Ahmad, aren’t yet available, but it may be limited to the WPA2-EAP standard. It may not affect the WPA2-PSK used on smaller, unmanaged access points like home routers.”
As far as the PTK key creation and the implementation of GTK/PTK are concerned, if the exploit is targeting the GTK and affects WPA2-EAP, then it should also affect WPA2-PSK.
Example 3: http://www.neowin.net/news/researchers-discover-wpa2-vulnerability
“The vulnerability, termed “Hole 196″, which can be exploited by attackers already authenticated to the network, allows decryption of data sent by other users across the network.”
An attacker already authenticated to a WPA2-EAP or WPA2-PSK network would already be able to sniff traffic (and analyze it with wireshark) in conjunction with ARP-poisoning to implement a MITM (including SSL-level attacks using SSLstrip) – in essence, anyone already authenticated to your network does not even need to exploit Hole 196 to do decryption of your data because there is no need to do so since they are ALREADY INSIDE YOUR NETWORK and can do it by many other means!
Based on the sketchy info so far, about the only thing i can think of where exploiting this vulnerability would come in handy for the authenticated user is to do “blackhole” sniffing without ARP-poisoning attacks in an EAP-protected network.
This is because traffic going to the AP is encrypted by a TK known only to the sending client and the AP (i.e. in a WPA/WPA2-protected network, authenticated clients are afforded some semblance of protection roughly analogous to as if they were in a switched network in that the TKs afford them some protection against straight-up promiscuous sniffing and hence why active MITM is required if you are an authenticated attacker).
Other clients, if they run just a sniffer like wireshark without doing any active MITM action, even if they capture the frame going ToDS, would not be able to even decrypt the TK-protected traffic because the guy doing the sniffing would not know the TK value of the other guy’s master key seed value from which the PMK and the entire key hierarchy is derived is truly randomly generated.
Contrast this to a PSK-type network where an attacker wouldn’t even need to go so far as to do this kind of attack because the authenticated attacker could could easily use a tool like Wireshark to decrypt the captured traffic so long as he knew the SSID and the PSK passphrase.
So to reiterate: the bottom line is – wait for the details (especially on what traffic specifically is the attacker embedding inside the spoofed-GTK frames) and take it from there. :)
If i was an attacker coming in from the outside, i’d be telling you to be more concerned about how you implement your PEAP setup if you’re using WPA- or WPA2-enterprise and the strength of your PSK-passphrases for PSK setups.
If the attacker was already authenticated and inside your network, all bets are off and you have much bigger problems to worry about. :P
Until more info is forthcoming, this vulnerability is at the level of a “nice-to-know, not-absolutely-necessary-to-have” for me because there are so many other ways to get to your traffic.
Peace V !