Firesheep and Sidejacking Not Just a WiFi Problem
When I first heard about the Firesheep credential sidejacking attack and resulting outpouring of information and advice how to protect or fix open WiFi to avoid attacks on social networking users, my first thought was "How has this become a WiFi problem?" But that doesn't mean there isn't room for wireless innovation to help mitigate the problem, in lieu of Web application vendors doing the right thing and fully securing their data.
Firesheep is the Firefox extension for Mac and Windows that makes it painfully easy to sidejack a Web session, allowing an attacker to steal cookies from another user's unencrypted Web traffic and gain access to the victim's profile and account on various Websites and services that don't practice end-to-end, full session encryption.
Even if the Web application SSL (Secure Sockets Layer) encrypts the victim's authentication login process, if the application later switches back to unencrypted HTTP and uses a cookie to maintain the session, Firesheep can capture the necessary authentication information from that cookie.
Open WiFi networks are the easiest avenue for potential exploit, and there is room for differentiation from wireless vendors implementing technologies above and beyond the standard to help mitigate the attack surface. The standards-based preshared key or 802.1x protocols will thwart the majority of casual and opportunistic attacks, while WiFi-vendor-specific technologies like dynamic preshared-keying and wireless client isolation should also have a positive effect.
IBM X-Force Research team also recently discussed a new way to generate security on open WiFi networks, proposing to mimic Website security on wireless networks. An AP (access point) presents a digital certificate to wireless clients as they connect to the wireless network, and that certificate is used to set up a secure tunnel between the AP and the client.
I reached out to some enterprise WiFi vendors to get their perspective on the X-Force idea. I talked to Matthew Gast, director of product management at Aerohive Networks, and Jon Green, senior product manager for mobile security at Aruba Networks, to see how feasible they thought the idea may be.
Both saw PKI (Public Key Infrastructure) and interoperability as the key stumbling blocks.
Gast noted that using untrusted certificates would lead to error messages on end-users devices, and ultimately would put too much decision making in the user's hands. But using trusted certificates means that every common OS needs the same set of trusted root certificates, and every company running a hotspot has to get a corporate certificate. Then certificate revocation becomes an issue: when to do it and how to know when it's been revoked.
Green saw merit in the idea, but he stressed the importance of interoperability, citing the importance of getting the IEEE or the WiFi Alliance involved. "A vendor can't put it out there and have it be on only 10 percent of the world's hotspots," he said. "If the client devices must be ready to deal with (the security) as well, it has to be a standard."
Of course, Firesheep or other sidejacking tools can also steal credentials passed over any shared, unencrypted wired networks. And, as pointed out by Andrew Vonnagy, WiFi-only encryption can still be bypassed and attacked through ARP Cache Poison and Man-In-The-Middle attacks. According to Vonnagy, to be fully secure, the encryption must be end to end, and it is incumbent upon the Web application providers to deploy it and standardize use on it.
"Facebook's not using SSL when it sends its authentication credentials is a big problem," said Aruba's Green. "It's something they can fix if they choose to put in the infrastructure to do it, but it's going to be expensive. But unless the users are demanding it, saying they won't use the service unless this [full SSL] is there, I'm not sure how much difference it will make."