Fix for hole 196?

› August 16, 2010 - Wireless

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!

Do not attempt this... Unless you've got Meru!

› August 10, 2010 - Wireless

WLAN 500^TM

A dream for you... A nightmare for microcell WLANs

 

Density, scalability, predictability, airtime fairness: challenges enterprises face today

 

Meru's virtualized Wireless LANs make dreams come true!

 Did you ever wonder how far you can push WLAN technology? Did you ever dream of putting 500 employees/students/journalists/visitors all together in one small room and still offer them high-speed access? Do you want to combine high-speed data, streaming video and high-quality voice calls over one network?

Did everyone tell you this was a dream?

Meet the WLAN 500^TM

• 500 multimedia clients
• 500 square feet (45m²)
• 100Mbps of background data
• 45 multicast video streams
• 20 simultaneous voice calls
• zero dropped connections!

In a small space of 45m², 500 WiFi clients were put together. These clients consist out of 11a, 11g and 11n clients where the 11n clients are both single band 2.4GHz clients as well as dual band clients. These clients all connect to the only 7 AP (AP320 and AP320i) in the room configured as a multi-layer network (4x40MHz in 5GHz and 3x20MHz in 2.4GHz).

Meru's unique features like Virtual Port, Band Steering, Load Balancing and Multicast Group Management were enabled. 75% of the clients used WPA2-PSK and 25% used a clear profile.

The load on the network is more than any 'standard' network would have to deal with:

• All wireless clients loaded web pages every 45 seconds for a continuous load per client.
• 45 simultaneous multicast video streams
• 20 phones placing client-to-client G.711 calls
• 100Mbps Chariot data load

There are no dropped connections, all browsing works perfect and react fast and snappy, the 100Mbps passes flawlessly and all phone calls reach Toll quality! (MOS > 4.0)

To investigate the 'what if' scenario, all AP were rebooted at the same time to have all clients associate and start there 'work'. After 3 minutes, all clients reastablished the connection and were back at full speed operational!

It's not magic,

It's Meru!

Watch the demonstration:

http://www.merunetworks.com/technology/resources/videos/index.php

 

3G Router table of comparsion

› July 15, 2010 - Mobile solutions

To assist you in the selection of the most suitable 3G router, Multicap now provides you with a handy table of comparison.

Multicap adds 2 new 3G routers!

› July 06, 2010 - Mobile solutions

Multicap adds two new UMTS/3G HSxPA routers to its portfolio.

One is the Funkwerk EC bintec RS120wu for SOHO use.

The other is the industrial grade Digi TransPort WR44 for ultra robust connections!