10 Ways to Protect Yourself from Firesheep Attacks
Our expert offers the top ten ways to surf websites vulnerable to Firesheep without getting fleeced. Learn how to best defend yourself from Firesheep and other sidejacking attacks.
Learn how to surf websites vulnerable to Firesheep without getting fleeced.
Years after BlackHat sidejacking demos, far too many websites remain vulnerable to this session cookie hijack attack. Frustrated by apathy and inaction, web developer Eric Butler and colleague Ian Gallagher decided to raise awareness with Firesheep a Firefox plug-in that makes sidejacking as easy as 1-2-3.
These and other sites vulnerable to session hijacking really need to be fixed to properly protect all exchanges with SSL/TLS. This is by far the most desirable antidote. Website operators simply cannot continue to ignore sidejacking, given the relative ease with which vulnerable sites can be exploited especially in open public networks.
In the meantime, what can ordinary users do to limit their own exposure to Firesheep and older, less-user-friendly sidejacking tools, such as Ferret, Hamster, or Cookie Monster? Here we consider ten steps that have been suggested to reduce your risk of being sidejacked and why many are impractical or incomplete.
Let's start with a few impractical non-solutions:
1. Don't use sites that stick to or revert to HTTP.
Sites that log you in over unencrypted HTTP (horrors!) or revert to HTTP after SSL login are prime targets. Anyone that can intercept that traffic can easily record and reuse the cookie, which identifies you on subsequent requests, thereby hijacking your authenticated session. Known-vulnerable sites include Amazon, Basecamp, bit.ly, CNET, Evernote, Facebook, Flickr, Foursquare, Google, PayPal, Twitter, Windows Live, Wordpress, and Yahoo. But avoiding this list is nowhere good enough. Many other sites are vulnerable and can be imported into Firesheep to grab those cookies too.
2. Avoid leaking cookies over HTTP.
Some websites try to do the right thing, but fall short. Specifically, servers must set a Secure flag to tell browsers to only send cookies over SSL. But sites that don't set this flag (such as Dropbox and Slicehost) let cookies "leak" over HTTP. For example, a URL entered without the https: prefix may cause your browser to send your cookie over HTTP before getting redirected to SSL. But users don't know what sites make this mistake and have little control over cookie transmission. To determine whether a site you use is vulnerable, import a script for that domain into Firesheep and test it on yourself.
3. Log off websites when done.
There are many sound reasons to log off secure websites when done such as when using a public PC. Logging off some websites could invalidate a session cookie grabbed by Firesheep. But there's no guarantee some cookies keep you logged in for days or weeks. And by the time you log off, your session may have already been sidejacked with consequent damage. This one's worth a try for good Web hygiene, but don't rely on it to stop Firesheep.
Some partial solutions don't stop sidejacking, but reduce your risk of being sidejacked. Firesheep works by scouring captured Web traffic for interesting cookies. Some access networks open hotspots and hospitality LANs - elevate risk by making it easier to capture unencrypted HTTP. So how can you reduce (but not eliminate!) that risk?
4. Avoid unencrypted Wi-Fi.
:ncrypting everything over Wi-Fi at work, at home, and in public is an excellent idea. Although not many hotspots offer WPA2-Enterprise, using it can greatly reduce the risk of being hacked. WPA2-Personal also encrypts Wi-Fi, but starts with a shared passphrase known to everyone. As such, it does little to stop eavesdropping at public hotspots except where vendor-specific solutions are used to issue unique per-user passphrases. [Editors note: For more on Wi-Fi encryption, read How to Use Enterprise Wi-Fi Encryption and 802.1X in Mac OS X.]
5. Use only trustworthy hotspots.
WPA2-Enterprise lets you check the 802.1X server's certificate, making it harder to impersonate a hotspot. But in an open hotspot, you have no way of knowing whether the access point (or login portal) is really trustworthy. Still, it's a good idea to verify SSL portal certificates; don't ignore browser warnings or you could find yourself sending traffic through an Evil Twin performing man-in-the-middle attacks including Firesheep. [Editors note: To learn how to surf more safely at hotspots, read How to: Protect Yourself at Public Wi-Fi Hotspots.]
6. Stick to secure LANs.
Don't fall for this one: Firesheep is not limited to Wi-Fi. Sidejacking may occur on Ethernet LANs and inside networks anywhere a hacker can intercept unencrypted traffic. When you plug into a public LAN from a hotel room or business center, your traffic could well be intercepted by other guests. Network operators wired and wireless should take steps to stop eavesdropping, ARP spoofing, and inter-client communication. Unfortunately, users rarely know whether such steps have been taken.
7. Fight fire with fire.
Some suggest launching counter-attacks against Firesheep. For example, FireShepherd sends packet bursts every half second to crash Firesheep, preventing prolonged sidejacking. At best, this will discourage a casual attacker while slowing the entire LAN. At worst, this could become a DoS attack, preventing productive network use. Trying this is probably ill-advised unless the network belongs to you.
If none of these are prudent, foolproof, or practical in every situation, what can you really do to protect yourself uniformly from Firesheep with greater confidence?
Firesheep in action. Photo courtesy of codebutler.com
8. Roll your own secure Internet connection.
Steps that depend on the network used to reach the Internet are by definition incomplete. As an application layer attack, sidejacking is best addressed by network-independent solutions. Short of that, you could use the same secure Internet connection everywhere you roam. Try tethering your computer to your 3G smartphone or turning your phone into a secure mobile hotspot (guarded by a strong, unique passphrase). This approach could stop other public network users from intercepting your traffic and sidejacking your sessions. However, it still relies on the relative security of your cellular provider's network. [Editor's note: One way to create your own mobile hotspot is to use a MiFi device, which this author reviewed last year for our sister site, Wi-Fi Planet. Read her review of the Novatel Wireless MiFi 2200 for CDMA 1x EV-DO Networks here.]
9. Insist upon full-time SSL.
Another possibility is to enforce correct full-time use of SSL for all sensitive websites using HTTPS-Everywhere or Force-TLS. Note that both are Firefox extensions; if you use another browser, look elsewhere. Furthermore, these extensions only enforce a defined site list; you may need to add sensitive sites that you use.
10. Protect everything with VPN.
If you can't be certain that sensitive websites use SSL correctly all the time, send your traffic through a properly-configured robustly-authenticated, encrypted VPN tunnel. These qualifiers are important for example, make sure your VPN doesn't leak HTTP if your tunnel goes down. But deployed correctly, a VPN tunnel can prevent sidejacking, no matter what network you use or websites you visit or how quickly their owners step up to the plate to fix underlying vulnerabilities. [Editors note: For a better understanding of VPNs, read Being Secure on Public Wi-Fi: VPN, Firewalls, File Sharing.]
Although Firesheep isn't a new attack, it appears to have accomplished Butler's goal of raising industry awareness. We can only hope that vulnerable site operators are finally spurred into action. And that Web users have gained a better understanding of what it takes to surf safely.
Lisa Phifer owns Core Competence, a consulting firm focused on business use of emerging network and security technologies. A 28-year industry veteran, Lisa enjoys helping companies large and small to assess, mitigate, and prevent Internet security threats through sound policies, effective technologies, best practices, and user education.