Firesheep Illuminates Security Problem

Open or Public Wi-Fi has been a delight to hackers for years but with the advent of Social Media and the growth of certain applications, especially but not limited to Twitter and FaceBook, with lax authentication and other security protocols the problem has grown exponentially.

With the release of the FireSheep FireFox add-on the hack went 'public'. If you utilise open or public Wi-Fi networks, i.e. while travelling, you may well be at risk of having various accounts hi-jacked, data mined in phishing expeditions (like shooting phish in a barrel), and otherwise compromised.

One point that most media reports have missed and none have emphasised (that I know of) is that while Wi-Fi hotspots make the hack easier - this is strictly a website security problem. The same hack can be done by tapping wired networks. While users can request and to some extent force SSL in the end it comes down to how the website server is configured.

A second point most media reports neglect is that this is not a new problem, it has been known since forever, and there have been tools similar, if not as convenient, to FireSheep for nearly as long: perhaps the best known being command line tcpdump and the gui Ethereal/WireShark.

It's extremely common for websites to protect your password by encrypting the initial login, but surprisingly uncommon for websites to encrypt everything else. This leaves the cookie (and the user) vulnerable. HTTP session hijacking (sometimes called "sidejacking") is when an attacker gets a hold of a user's cookie, allowing them to do anything the user can do on a particular website. On an open wireless network, cookies are basically shouted through the air, making these attacks extremely easy.

This is a widely known problem that has been talked about to death, yet very popular websites continue to fail at protecting their users. The only effective fix for this problem is full end-to-end encryption, known on the web as HTTPS or SSL.

...

Websites have a responsibility to protect the people who depend on their services. They've been ignoring this responsibility for too long, and it's time for everyone to demand a more secure web. My hope is that Firesheep will help the users win.

The introduction of this tool reinforces the importance of websites configuring themselves to require secure connections.

Not too long ago we announced HTTP Strict-Transport-Security that can be used to ó among other things ó ensure your Facebook or Twitter cookies canít be sniffed by someone using a tool like Firesheep. In fact, itís built into Firefox 4. To protect their users from the this attack, a site simply needs to set the Strict-Transport-Security HTTP header when they serve you a secure log-in page, and make the rest of their site available over HTTPS. Firefox will take care of the rest: automatically fetching that site over a secure connection and blocking any third parties from seeing the unencrypted traffic.

We recommend that website authors make use of this header in order to protect their users.

...

But this technology is new to Firefox 4. To get HTTP Strict-Transport-Security support in Firefox 3.6, you will need to install an add-on that implements it such as ForceTLS.

...

Both HSTS and the manual opt-in are also available as part of NoScript. However, manually opting-in to HSTS on a site which does not yet make itself fully available securely may break the site; not all sites are ready for secure access.

Sid Stamm in comments:

You can enable Strict-Transport-Security on sites that donít advertise the HTTP header using the optional STS-UI add-on [for FireFox]. Be careful though, since not all sites are properly configured to serve all their content over HTTPS; enabling HSTS on a site not expecting it can cause bits of the site to break.

Daniel Veditz in comments:

The attack can be performed by anyone in a position to observe your network traffic (wireless or not). In practical terms you are most at risk when using an unsecured wifi network, and less at risk to the extent your end-point is secured (WEP is easily cracked, WPA2 is good).

So - if you require log-in authentication for any reason: is your site configured to serve ALL content via HTTPS?

If not: does your site break when a user forces HTTPS?

If a hacker hijacks a visitor's cookie, session id, or similar tracking entity can it be mis-used to detriment of site or visitor?