The last week there has been a lot of discussion over the release of the Firesheep addon for Firefox. Firesheep made the news because it allows anyone to impersonate someone on the same network on the vast majority of websites on the net. This is known as session hijacking or “sidejacking”. The problem occurs because most websites only encrypt the login process which prevents people from sniffing your username and password, but they then redirect to a non-ssl site which allows people to steal your session cookie – the unique identifier that tells a site who you are after you have logged in. If someone has hijacked your session they don’t have your username and password, but will still be logged in as you.
There has been a bit of controversy over Firesheep because some people are convinced that the person who wrote the extension should be held accountable or at the least did something wrong. Nay. Those people are simply misguided. Releasing a tool like Firesheep is the essence of responsible disclosure. The generally agreed process for dealing with exploits is to contact the developer privately to work on a fix, and reveal the exploit with the fix so both the company and researcher get credit. If the developer refuses to fix the flaw, then a proof of concept exploit is released to push the developer into doing the right thing. Firesheep is simply another proof of concept exploit for a problem that has been around for many many years. It isn’t like people were not made aware at least once before.
Facebook seems to have been getting the most press, although most sites are vulnerable. Most web email services, Amazon, other social networking sites, forums….pretty much anything you can think of. The strange thing is that most people don’t seem to care. This is generally because people don’t understand the risk or think that they won’t be a target. This is why the release of something like Firesheep is a good thing, a fantastic attempt at actually illustrating the threat. No doubt its use will become more widespread and as more people start to get taken advantage of, there will be a greater push for security that will benefit everyone.
I found it interesting that somebody went to the trouble of writing FireShepherd. FireShepherd is a tool that exploits a bug in FireSheep to prevent it from working. It doesn’t accomplish anything, and will likely be rendered obsolete in the next version. If something like FireShepherd was to be useful it should pollute the waves with fake sessions, although even this would not work terribly well.
I wanted to clear up some misconceptions that have sprung up in the wake of Firesheeps release, as a lot of bad advice seems to be being given out. First of all, logging out does not automatically make you safe. Many websites do not necessarily invalidate the session upon logout, which means even if you have logged out whoever is hijacking your session can continue to do so.
You are not automatically protected by using an encrypted wireless network. WEP does not encrypt client traffic for authorized clients and besides can be cracked in seconds. WPA/2 PSK means it uses a Pre-Shared Key. This means anyone with that key can decrypt traffic for the other clients. Firesheep may not work, but it would not be difficult to adapt it to do this. Even on a wired network you may not be safe due to ARP poising or MAC address overflow attacks.
Some people have recommended using a VPN or SSH tunneling which are one of the best solutions. They are not immune however it is a whole lot less likely that someone is sniffing anything from your ISP’s connection upwards than it is that there will be some douchebag at Starbucks looking for someone to take advantage of. Either of these solutions are the best at present as they allow you to encrypt all traffic to a point where only employees or authorized personnel would have access to take advantage of your unencrypted sessions.
What most people have been suggesting is to use an extension that forces sites to use SSL all the times. The two most suggested addons are HTTPS Everywhere by the EFF and Force-TLS. NoScript also has this capability. There is a similar addon for Chrome called KB SSL Enforcer however it is quite insecure at present. Due to the subpar Chrome extensions framework every site request will be http first, so session cookies will still be leaked and can be abused.
Each of these addons make use of HSTS which rely on the server to have support. If the server does have support then the entire session can be encrypted. Unfortunately not many sites support this at present, and forcing an SSL session by rewriting http requests is not ideal. Some websites will break if you try this, such as chat no longer working in FaceBook. Some sites may not load at all as they will depend on http content for various reasons, such as hardcoded links or content from another domain. Even if a website supports wholly SSL sessions there may still be information leaks, such as AJAX requests or a fallback to HTTP happened to Google a few years ago.
The only decent solution is for websites to implement sitewide SSL . Secure cookies, and SSL for everything from the login and after. No fallback to just HTTP, at all. Of course, this approach has gotten some criticisms. People claim that SSL is too expensive, however this simply isn’t true. Google showed earlier this year that having SSL as the default option for Gmail increased server load only %1. If Google can manage this, Facebook and Amazon sure as hell can. People are saying the performance will be diminished because you can’t cache with ssl however this is false, you just have to set Cache-control: public. Then there are people who complain about needing a dedicated IP, which is also false. Basically, in this day and age, there is very little reason not to have an entire encrypted session for anything remotely valuable. It is appalling that so many companies and sites have ignored this problem for so long and I think it is great that Firesheep has brought attention to the problem, again.
Of course, I don’t expect anything to change although in another few years there will probably be a similar tool released and the discussion will start up again, at which point there truly won’t be any excuse for default non-encrypted sessions to be so prevalent.
Update – November 11th 2010
A few days after I wrote the above, a tool called BlackSheep was released which aims to help people detect someone using Firesheep on a network. The tool does as I said above, sending fake sessions and reporting when one is accessed. I haven’t looked at it in detail but I would think it could easily be mitigated either by learning to identify the type of sessions BlackSheep sends out or finding some other way to detect or disable it. This just gets into a never ending cat and mouse game all the while ignore the real problem.
I was made aware of an addon for Firefox, SSLPasswdWarning. This addon will alert you if your password or sensitive information will be transmitted over an insecure connection, so is useful in helping to determine if there is a risk or not.