[C. Nicholas Burnett, the manager for ESET LLC's tier three technical support, contributed the following guest blog article on the FireSheep plugin for Firefox.  Thank you very much, Carl!  Aryeh Goretsky]

The past several days have seen the security community abuzz about a program presented in San Diego at ToorCon 12 this last weekend called FireSheep. Written by Eric Butler, a web developer from Seattle, it has, or at least is about to have, turned everyone's idea of web security on its ear.

First, a little background:  All of the Web 2.0 services we have come to love and use on a regular basis use a little piece of technology called the session cookie,  to keep track of a user's login state.  The cookie itself is just a tiny text file that is stored on the user's computer for a website to reference later, allowing the website to confirm it is still communicating with the same client.  The most common use for cookies is to allow a user to remain logged-in to a website after submitting credentials.

Consider Facebook: Simply navigating around on Facebook requires your browser to continuously load and re-load hundreds (or even thousands) of resources from facebook.com as you scroll through web pages, play games, view pictures and click on links.  When you first login to Facebook, a session cookie is created to uniquely identify your connection, and this cookie is re-transmitted with all subsequent requests made from the web browser until it is closed or the cookie expires.  This piece of technology is absolutely vital to modern web usage—otherwise, we'd all have to log-in to Facebook hundreds of times per page view just to get every image and status update to display on the main page.

The first bit of trouble arises when a wireless connection becomes involved.  If the communication is not encrypted, then your session cookie information is shouted from the mountaintops to anyone who might be listening to the same wireless connection.  In 2004, a web application security developer named Chris Shiflett wrote a paper about what he called "Session Hijacking" and the problems it could pose.  Also known as "Session Impersonation" and "Sidejacking," the concept is quite simple—another party pulls your session cookie out of the air, and then uses it to convince the web server that it is you without ever having to actually go through the authentication process of logging in.

In the early days of this discovery, an attacker needed a fairly comprehensive knowledge of HTTP, packet capturing, and other techniques to accomplish a sidejack.  Over the years, however, tools and scripts have been released that automate (or, at least  partially automate) this process.  All of these tools stayed fairly underground and were largely under the purview of researchers and malicious entities.

And now we come back to FireSheep.

What Mr. Butler has done is write a plugin for FireFox that allows anybody to capture anyone else's session cookies on an unencrypted wireless network.  It creates a simple graphical sidebar in FireFox that displays a list of captured cookies.  Clicking on each one automatically loads the site for that the cookie and assumes that user's identity.  It's simple, blazing fast, and absolutely terrifying to watch, even in a test environment.

A partial list of sites vulnerable to FireSheep:

  • Amazon
  • Facebook
  • Google (including mail, docs, and all other services)
  • Twitter
  • Yahoo (like Google, includes mail and other services)
  • Flickr

FireSheep has done the equivalent of giving every human being a gun in order to force debate about the very existence of those weapons.  It has inverted the logic of "if guns are outlawed, only outlaws will have guns" and decided that if everyone had a gun, there would be no outlaws.

There is—and always has been—a cure for this scenario, encryption at every stage of the network connection.  Encrypted wireless networks.  SSL on every site with user accounts.  Keeping secure data isolated from unsecure data.  These are all design-level fixes, though, and when the difference between launching your new web startup now and launching it later is a few hundred dollars for an SSL certificate and an extra week of developer time, fast and cheap almost always wins.  Notice that in the above list, most of those sites use SSL encryption - but they use it after you initially log in.  Your credentials are encrypted, but once the cookie is set it generally is not.

I hope that Mr. Butler is correct and that FireSheep will transform connecting to an open wireless network from "risky" to "suicide" and that every developer of web services will insist on end-to-end encryption as part of the design specification from now on.  These are things that are needed to have happened a long time ago, and hopefully this is the nail in the coffin of unencrypted and unsecure services.

If he's wrong, though, then FireSheep could transform our beloved Information Highway into something out of Mad Max.

In the meantime, here’s how you can make sure you stay immune to these attacks:

  1. Never connect to an open, unencrypted wireless network for any reason.
  2. Strongly avoid WEP-protected wireless networks if possible as this encryption can be trivially bypassed.
  3. Ensure your account settings around the web are configured to use HTTPS/SSL if it is supported. For example, http://mail.google.com/support/bin/answer.py?hl=en&answer=74765 shows how to enable this for your Google account.
  4. Always “sign out” or “log out” of a service as soon as you are finished using it.  Oftentimes this will expire the session cookie, and subsequent attempts to use it will fail.
  5. Avoid settings like “keep me logged in” when logging in to services.

C. Nicholas Burnett, GREM
Premium Support Supervisor