Enterprise Lockdown


Aruba analysis of "Hole 196" WPA2 Attack

Read about it here: http://airheads.arubanetworks.com/article/aruba-analysis-hole-196-wpa2-attack
Jon Green, ACMX, CISSP
Security Guy
New Contributor

ARP poisoning using GTK and Client isolation

In his analysis, Robbie raises a question, to quote "It is not clear why the attack conducts ARP poisoning by encrypting the ARP frame with GTK and directly sending it to the victim bypassing the AP (Step 1)."

If ARP poisoning is done by directly sending spoofed ARP frames to the AP, then the AP would forward the spoofed ARP poisoning frames on the wireless as well as on the wire. 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 network switches can readily catch and block this attack on the wire today.

But, by using GTK-encrypted ARP poisoning attack, the attacker keeps the footprint of the attack 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.

Then comes the question of client isolation. Client isolation is obviously one of the first steps that you can take so that the AP does not forward traffic between any of its associated Wi-Fi clients.

However, users should be aware that Wi-Fi client isolation does not completely address the problem. An attacker can still send GTK encrypted packets (Step 1). If the attacker decides to poison the victims so that they redirect their traffic to a fake gateway (set up by the attacker) on the wire, then Wi-Fi client isolation alone will not stop this attack!

And other attacks are possible based on the GTK vulnerability where the attacker only requires Step 1 to attack other Wi-Fi clients. So even in that case the AP and Wi-Fi client isolation will not have any role to play in protecting authorized Wi-Fi clients.

Kaustubh Phanse, AirTight Networks

Re: Aruba analysis of "Hole 196" WPA2 Attack

You are correct in that this is a good way to evade a wired IDS. The only thing to keep in mind is that Robbie's analysis is directed primarily at Aruba customers - for these customers, we have existing features that detect and block this attack, both from a wireless IDS perspective (seeing BSSID spoofing) and from the firewall side seeing inter-client communication with MAC addresses that don't make sense. Also, were I an attacker on Aruba Wi-Fi gear, my physical location would be tracked. If one minute I have one MAC address, and the next minute I happen to be in the same physical location but I have the MAC address of the default gateway, that might look suspicious on a playback of the location tracking data. :)

Other vendors of Wi-Fi infrastructure may be more vulnerable than we are.
Jon Green, ACMX, CISSP
Security Guy
New Contributor

juniper odyssey client xsec

Is the xsec protocol immune to this because..... xsec does not use gtk, only ptk -- is that true or false.
Search Airheads
Showing results for 
Search instead for 
Did you mean: