WPA2 Hole196 Webinar Q&A

facebooktwittergoogle_pluslinkedinmailfacebooktwittergoogle_pluslinkedinmail

Due to the overwhelming attendance and response we got to the recent WPA2 Hole196 webinar, we did not have time to answer all the questions asked during the webinar. In this post, we are keeping our promise and answering those webinar questions.

By the way, the webinar slides and recording from this webinar as well as answers to the frequently asked questions on Hole196 and a white paper are available here.

So here we go!

Q. Can an attacker perform all attacks associated with mitm?

A. Yes. In fact, an attacker can go beyond MITM attacks and launch other attacks such as DoS, port scanning, malware injection, buffer overflow, etc.

Q. Will this attack work with all WLAN clients?

A. Yes! With all standard Wi-Fi clients.

Q. In order for the attack to work, the attacker must be associated to the same access point as the victim, correct?

A. In order to know the group key (GTK) used by potential victims (authorized clients in a WPA2 network), an attacker needs to be associated with the same WPA2-secured AP. But once the group key is known, an attacker can launch attack from anywhere in the proximity of the victim clients.  Association with the same AP is not needed, unless the group key is being refreshed periodically by the AP.


Q. Why do we have to encrypt the ARP Poisoning packet with GTK ? Couldn’t we simply send the ARP poisoning direct to the Victim via the AP ?

A. ARP Spoofing (and man-in-the-middle) is a classic attack in both wired and Wi-Fi networks. However, in this old way of launching the attack, the AP forwards the spoofed ARP messages on the wireless as well as the wired network. The messages that go on the wire are in the clear (unencrypted). Wired network security has evolved over the years to the point that wired IDS/IPS and even some network switches can readily catch and block this attack on the wire today.

The subtle point (that many people seem to miss) about exploiting the GTK in WPA2 for launching an ARP Spoofing attack is that the footprint of the attack is only in the air and the payload is encrypted. So no wire-side security solution is ever going to catch this attack over WPA2, nor will existing APs will see anything abnormal.

Q. As far as I know, if you’re an insider, you know the PSK, so by sniffing the WPA2-Handshakes, you’re able to calculate PTK of every clients… isn’t it more easy than ARP Poisoning?

A. That is true for Wi-Fi networks using PSK authentication. But the Hole196 vulnerability is intrinsic in the WPA/WPA2 protocol and hence exploit is possible regardless of type of authentication and encryption. In other words, Hole196 based ARP Poisoning and other exploits will work even in WPA2 networks using 802.1x based authentication and AES encryption.

Q. Do we know what type of AP is vulnerable to this exploit?

A. The Hole196 vulnerability is fundamental to the WPA/WPA2 protocol. All standard Wi-Fi APs, including stand-alone APs or those controlled by WLAN controllers are vulnerable.

Q. What are these other attacks that require only Step1 [broadcasting GTK-encrypted frames]?

A. Different type of attack payload can be encapsulated inside a GTK-encrypted broadcast/multicast frame and sent to other authorized Wi-Fi clients in the WPA2 network. Examples of other attack payloads are targeted IP layer attacks such as port scanning, TCP connection reset, DoS, cause buffer overflow, etc.

Q. In your way to bypass PSPF by using a wired interface … wouldn’t/shouldn’t the wired IPS kick in that you mentioned in the beginning not being able to detect hole196?

A. No. A wired IDS/IPS will only kick in when it detects spoofed ARP frames. In the “Hole196” exploit,  spoofed ARP frames are sent only in the air and to bypass PSPF/client-isolation, data traffic of victim clients is redirected to attacker’s wired interface or machine. This data traffic is no different than normal data traffic flowing on the wired LAN.

Q. Will having a program watching the AP Mac address to alert you when it changes be a solution?

A. No. The attacker is spoofing the MAC address of an AP so program will not be able to distinguish attack from normal traffic from the AP, if the program is simply watching the MAC address of an AP. Detection requires more sophistication than that.

Q. Is there any possibility to secure client’s arp cache…?  Secure client to stop accepting arp packets or manually add MAC Codes into client?

A. Yes. By creating static ARP cache entry,  one can achieve resilience against ARP spoofing attack. Some open source client softwares are also available that can help in watching changes in the ARP cache on a client.

Q. May I ask you again on how client isolation or PSPF works?

A.  Client isolation is a proprietary feature implemented by some WLAN vendors. Communication between two wireless clients can be prohibited by enabling this feature on an AP or controller. However, client isolation can be bypassed and it alone cannot protect against Hole196 based exploits. A more detailed answer is available in our Hole196 FAQ.

Q. How to use unicast key or unique GTK as a solution? Is this the default method on controllers ?

A. Broadcast/Multicast MAC address can be converted to unicast MAC and then unicast key can be used to send encrypted data packets. Or a unique GTK can be assigned to each associated client.  But this is not commonly available on WLAN controllers or APs and will need to be implemented using a software upgrade.

Q. Would Ruckus Dynamic PSK help?

A. No. The Hole196 vulnerability is intrinsic in the WPA/WPA2 protocol and independent of the authentication used. In other words, regardless of the authentication (PSK, Dynamic PSK, 802.1x) used, a WPA/WPA2 WLAN can be attacked by exploiting Hole196 vulnerability.

Q. Wouldn’t asymmetric encryption allow to still have the ability for the AP to broadcast without allowing the clients to do so?

A. Yes, use of asymmetric keys is a possible solution.

For those of you who missed the first webinar, you still have a chance to learn everything you want to know about the WPA2 Hole196 vulnerability in an encore live webinar presentation on Tuesday, August 24 at 8:00 AM US Pacific Time. Click here to register for the webinar.

Kaustubh Phanse

Kaustubh Phanse

Kaustubh Phanse joined AirTight as the Principal Wireless Architect in 2007 before growing into the role of Chief Evangelist. He brings over 10 years of R&D experience in the fields of computer networks, wireless communication and mobile computing.

Trackbacks

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>