“The footprint of WPA2 Hole196 based insider attacks is limited to the air, making them among the stealthiest of insider attacks known. As a result, no wireline security solution (wired IDS/IPS, firewall, or switch-based ARP Poisoning detection) can detect these attacks.”
solution:
“…according to current WPA2 protocol standard, a GTK needs to be assigned by the AP to each client during the association (four-way handshake) process. AP vendors can implement a patch to their AP software to assign a unique, randomly generated GTK to each client instead of sharing the same GTK among all clients. Using unique GTKs will neutralize the Hole196 vulnerability and still allow interoperability (backward compatibility) with all standard Wi-Fi client devices. And there will be minimal cost associated with this change in terms of reduced data throughput.
In absence of an ARP proxy, an AP could send broadcast traffic over the air as unicast to individual clients, though this will potentially result in degradation in the WLAN data throughput depending on the amount of broadcast traffic.
In the long term, this approach of deprecating the use of a shared GTK could be adopted in the IEEE 802.11 standard and only PTK could be used.”
I’m not entirely sure either. At a quick look it appears as if wpa_supplicant really is just a supplicant, and that hostapd at least for some chipsets is the authenticator running on the AP. But it does appear to all be in software.
Another thought: if this does get implemented it should probably be a configurable feature. Going to GTKs unique per client might make it pretty easy to slow the wireless network to a crawl. Imagine an AP with 40 clients associated. Before unique GTKs you send one broadcast to the AP, it turns around and sends it to everyone else. With unique GTKs it has to rekey the packet 40 times and send it 40 times to cover all associated clients. If you send enough broadcasts you could seriously impact throughput. On the other hand you could mitigate that with client isolation if that works for your network.
Can I use the client isolation (or PSPF) feature on my WLAN infrastructure to protect against WPA2 Hole196?
Client isolation is not part of the 802.11 standard, but a proprietary feature that is available on some APs and WLAN controllers. The implementation of the feature is likely to vary from vendor to vendor.
Turning ON the Client isolation (or PSPF) feature on an AP or WLAN controller can prevent two Wi-Fi clients associated with an AP from communicating with each other via the AP. This means that while a malicious insider can continue to send spoofed GTK encrypted packets directly to other clients in the network, the data traffic from the victim clients will not be forwarded by the AP to the attacker’s Wi-Fi device.
However, an attacker can bypass the Wi-Fi client isolation feature, by setting up a fake gateway on the wired network, poison the ARP cache on authorized Wi-Fi devices using GTK and redirect all data traffic to the fake gateway instead of redirecting it directly to his Wi-Fi device. Plus, other attacks such as malware injection, port scanning, denial of service, etc. are still possible using only the first step (sending GTK-encrypted packets)
I suppose from reading this article unchecking “default forward” on the AP’s will help somewhat and i don’t understand how “an attacker can bypass the Wi-Fi client isolation feature, by setting up a fake gateway on the wired network”
Client isolation usually just prevents packets from coming in the radio and going back out the radio to another client, so coming in the radio via wireless you can only put packets on the wire bridged through the AP. Conversely packets from the wire can make it to wireless clients.
You could potentially set up a station on the wired network and send packets with a destination IP of another wireless client but the destination MAC address of the wired station to it - since it’s on the same subnet, it’s delivered on layer 2 by MAC address. That packet would make it to the malicious wired station just fine because it doesn’t fall under client isolation. The wired station can then take the packet and ARP for the proper recipient, replace the MAC address in the packet and send it back out. The AP would get the packet on the wire and bridge it out the wireless radio because that isn’t covered by client isolation. Effectively you’re proxying the packets through a station on the wire to circumvent the client isolation feature. Depending on how the router on the client’s subnet is configured you can even use just that router for that purpose, but most secure networks have the routers configured to prevent this (similar to how you should configure, say, a Cisco router to prevent a very similar ‘attack’ when using private VLANs - there’s plenty of whitepapers for that scenario available online).
That just covers APs. Controllers work similarly, but of course in that case client isolation refers to the controller not forwarding traffic between LWAPP clients, but being fine with forwarding LWAPP traffic to a malicious wired proxy station. Same principle, but the isolation happens somewhere else.