Firesheep a non-security threat to Aerohive Wi-Fi
As I said in my last post, Firesheep is a slick GUI that makes it point-and-click easy to run an HTTP hijacking attack. It’s not really a Wi-Fi vulnerability, so the real solution to this problem is to tell your Web service vendors to use SSL or TLS to secure the session end-to-end. (In the last few days, I’ve noticed that my bank, my airline, and the Kavi document management system we use at the Wi-Fi Alliance all do so) You wouldn’t do online banking if the session wasn’t fully encrypted, and that should be the standard for anything you really care about. In that gap between the Firesheep release last week and the rosy future of all your Web sessions being encrypted by the application provider, it’s possible to reduce the window of vulnerability by activating security features on your Wi-Fi network.
The first release of Firesheep has one key limitation: it works only on unencrypted networks. Running either the deprecated WEP “security” protocol or WPA is enough to defeat Firesheep. (If you care about security, you should definitely use WPA2. I’ve worked on a security roadmap for the Wi-Fi Alliance that is aimed at increasing usage of WPA2 because it’s important to get the Wi-Fi user community on the strongest security possible. A good chunk of this work is phasing out WEP.)
Now, I expect that Firesheep can be relatively easily extended to deal with manual WEP, where a single key is installed for the entire network. With manual WEP and a single key, any station with the key can decrypt everything on the network. An extension to handle WPA preshared keys is viable, too. A 2003 paper described design limitations of the WPA preshared key hierarchy, noting that “the whole keying hierarchy falls into the hands of anyone possessing the PSK, as all the other information is knowable [from the PSK handshake.]” If an attacker captures the entire WPA PSK handshake, the individual encryption keys for a device can easily be recovered provided the attacker knows the PSK.
One answer is to run WPA Enterprise (sometimes known by one of the key underlying specifications, 802.1X). Link-layer keys in WPA Enterprise are unique to a station and generated from an SSL handshake, and are impossible to recover by passive analysis. WPA Enterprise requires client-side configuration and distribution of digital certificates. It can work within a single company when managed by an IT department, or through a consortium like Eduroam where credentials are federated and shared between multiple institutions.
At Aerohive, we offer a middle ground between these two approaches. Administrators can use the Private Preshared Key (PPSK) feature (check out the PPSK tutorial and see for yourself) to assign a unique PSK to every station on the network without the administrative overhead of configuring 802.1X. An attacker using Firesheep or any other passive analysis tool will be unable to recover link layer encryption keys without using a brute-force attack to search for the PPSK.
Guest networks can use PPSK instead of captive web portals for authentication, and there is no reason why a PPSK has to be limited to a corporate guest network. If the entire login sequence that generates a PPSK is encrypted with SSL, a captive web portal can even be used to provide secure access for members of the public who just walk up.