AirTight Networks recently announced that WPA and WPA2 wireless LANs are vulnerable to a man-in-the middle attack they discovered – namely the WPA2 Hole 196 attack. (http://www.airtightnetworks.com/WPA2-Hole196)
Executive Summary
• Can only be launched by an AUTHENTICATED user within a WLAN SSID.
• Does NOT compromise AES encryption
• NO unicast keys (PTKs) are compromised
• No successful Man-in-the-middle possible if client isolation feature is enabled on AP
• On a protected AP, can only cause a denial of service at best for clients on same WLAN SSID.
• Segregated Wireless network with seperate SSIDS for untrusted users has limited exposure as attacker can not affect users connected to another SSID
Background
As described by AirTight, this attack is essentially an insider attack where both victim and attacker are legitimate authenticated clients on the network. Hence both are in possession of their unique unicast keys (PTKs) and a common group key for broadcast (GTK). Following are the steps of the attack:
1. The attacker creates a malicious gratuitous ARP frame with same IP address as that of the default gateway, but using its own MAC address. Then the attacker encrypts this ARP frame using the common group key (GTK) and sends it directly to the victim over the air. This would bypass any traffic restrictions configured on the AP for restricting communication between WLAN clients or ARP spoofing detection on the AP.
2. The victim receives the frame, decrypts it with the GTK and extracts the malicious ARP frame from the attacker. This implicitly updates victim’s ARP table such that the default gateway’s IP now points to the attackers MAC address. This causes the victim to send all traffic to the AP with the attacker as destination gateway. Traffic between the victim and the AP is encrypted with victim’s unicast key (PTK).
3. AP receives this traffic, decrypts the traffic, encrypts it using attackers PTK and forwards victim’s data to the attacker hence establishing a man-in-the-middle. Victim’s unencrypted traffic is hence exposed to the attacker. No unicast keys are compromised though.
Analysis
On analyzing the attack, it doesn’t appear any different from the classic Layer 2 Man-in-the-middle ARP poisoning attack. Stations on the same LAN can craft malicious ARP frames and poison each other’s ARP caches anyways (http://ettercap.sourceforge.net/forum/viewtopic.php?t=2392). In WLANs this is true as well irrespective of what encryption/authentication scheme is used. It does not matter whether the WLAN is using WPA or WPA2 for security, once the clients have successfully authenticated they are vulnerable to ARP poisoning from each other and this is nothing new. ARP protocol does not offer any security or authentication of ARP messages.
For preventing such ARP poisoning scenarios, Aruba devices allow client isolation where layer 2 and layer 3 inter WLAN client communication can be prohibited. This features prevent WLAN clients from attacking each other using ARP and any other insecure protocols.
If client isolation feature is enabled, this man-in-the-middle attack would not be possible as communication between victim and attacker via the AP would be prohibited and the attacker would not be able to communicate with the victim even after the victim’s ARP cache has been poisoned. At worst this would be a denial of service attack as after the ARP poisoning, the victim’s gateway ARP entry is pointing to the attacker’s MAC address, with which no communication is possible.
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 client isolation feature is not enabled on the AP, then the attacker (which is a legitimate WLAN client) could have injected this frame via the AP and poisoned all other clients on the WLAN anyways. If the purpose of this step is to bypass the client isolation prevention features on the AP then this would never be a successful Man-in-the-middle attack as these features would stop communication between victim and the target even after victim’s ARP has been poisoned. The target won’t be able to communicate with its gateway and hence this attack would be reduced to a denial of service attack between authenticated clients.
Mitigation
To mitigate this Man-in-the-middle attack, it is highly recommend to enable client isolation feature so that no inter client communication is allowed. These features can be enabled with the following commands:
(config) #firewall deny-inter-user-bridging (Denies Layer2 traffic between users. Available in all AOS versions)
(config) #firewall deny-inter-user-traffic (Denies Layer3 and Layer2 traffic between users. Available AOS 3.4.x onwards)
It is also recommended to enable IP spoofing prevention. This step is not required if all Layer3 and Layer2 traffic between users is prohibited using steps above. This will stop the attacker from originating sessions with spoofed source IP of a gateway or any other user.
(config) #aaa user add "Gateway-IP" mac "Gateway-MAC" role allowall name "some name to identify the gateway"
Repeat this step for all gateways.
(config) #firewall prohibit-ip-spoofing
Although ARP poisoning does not happen via the AP in this particular attack, it is also recommended to enable ARP spoofing prevention features for defense in depth.
(config) #firewall prohibit-arp-spoofing (Available AOS 3.4.x onwards)
Segregated Wireless network with seperate SSIDS for untrusted users has limited exposure as attacker can not affect users connected to another SSID.
Refer to ArubaOS User Guide for detailed information on these features.