Fix for hole 196?
Home › News & Press › Wireless › Fix for hole 196?
Fix for hole 196?
Why everyone but Meru cares
What is Hole 196?
Security experts at AirTight Networks have discovered a hole in the WPA2 Wi-Fi security protocol. The security hole was named as Hole 196 after the number of the relevant page in the IEEE 802.11 (2007) standard document. At the bottom of page 196, the IEEE standard introduces the keys used by WPA2: the PTK (Pairwise Transient Key), which is unique for every Wi-Fi client and used for unicast traffic, and the GTK (Group Temporal Key) used for broadcasts. While data forgeries and spoofed mac addresses can be detected with the PTK, the GTK does not offer this functionality.
The AirTight experts say that this is the crux of the matter, because it allows a client to generate arbitrary broadcast packets which other clients respond to with information about their secret PTKs which can be decrypted by attackers. AirTight reportedly only needed to add 10 extra lines of code to the freely available open source Madwifi driver to make a PC with an off-the-shelf Wi-Fi client card spoof the MAC address of the Access Point and pretend to be the gateway for sending out traffic. Attackers could exploit this to cause damage on the network, for instance via denial-of-service (DoS) attacks. The experts say that the only factor mitigating the attack potential is that attackers need to be internal, authorised Wi-Fi users. They do not anticipate that a patch will become available because "Hole 196″ is written into the standard.
What does it mean?
A client on an Access Point uses two keys to send his data securely: one is used for unicast traffic (PTK) and one is used for multicast and broadcast messages (GTK). The unicast key is unique per client whereas the broadcast key is unique per AP (=BSSID) but equal for all clients on that AP.
Now, if one of your own clients that is associated and authenticated on the network uses this technique, he can pretend to be the AP he and his colleagues are associated to and send broadcast messages to these clients in order to get responses with info on these clients' PTK key.
One example of the exploit involves ARP poisoning. The attacker can send a broadcast ARP request where he links his own MAC address to the IP address of the gateway. All clients that receive this message will update their ARP table - mapping the attacker's MAC address with the gateway's IP address. All "poisoned" Wi-Fi clients will send all their traffic, encrypted with their respective private keys (PTKs), to the AP, but with the attacker's MAC address as the destination. The AP will decrypt the traffic and forward it to the attacker, now encrypting it using the attacker's PTK. Because all traffic reaching the attacker (from the AP) is encrypted with the attacker's PTK, the attacker can decrypt the traffic (including login credentials, emails and other sensitive data). The attacker can then choose to forward the traffic to the actual gateway of the network, so that the victim Wi-Fi clients do not see any abnormal behavior and continue their communication.
Be aware of the fact that this attack does not include the hacking or cracking of the encryption standard AES or the authentication mechanism!
In a normal wireless network, Access points act as an Ethernet hub and everyone associates with that AP is associated with the same BSSID and is now vulnerable to the "Hole 196" vulnerability.
How to fix it?
The question is - if the vulnerability is in the broadcast, how do you stop broadcasts on a wireless network from using the same shared key to all users when the APs act like hubs? The answer is to virtualize and make the AP act more like a switch.
Meru's Virtual Port virtualize the AP for every client and offers each client its own BSSID. Each client thus thinks it is on its own private and personal AP. As a result, the broadcast key for WPA2 is unique per client! This makes it impossible for the 'bad' client to spoof the AP's MAC and exploit the broadcast key vulnerability since no one shares the same key. Moreover, sine the client resides in its own 'space', broadcast messages are only send to itself and the Meru infrastructure. The attacker never gets direct access to other clients!