Two weeks ago, or 24th October 2010, there is a new plug-in for Firefox being released during the ToorCon 12 (a hacker conference) and immediately the plug-in captured tons of media attention. What is this plug-in made for, you might ask? Firesheep, a plug-in for Mozilla Firefox that is developed to demonstrate the security issue in most of the famous web services, such as Facebook, Twitter etc., and this security issue (known as HTTP Session Hijacking) wasn’t a new one – it is already made known and discussed since year 2004, and still most of the web services are ignoring this issue. Most of the web services aware that they can do a fully secured website for their users by using HTTPS/SSL, but a big portion of them choose either not to implement it, or implement it at the surface layer only (like Facebook and Twitter), where you only have the full encryption and protection during the login, but not the session after that. This doesn’t do good for their user since the HTTP sessions are still easily being hacked, and certainly their new privacy settings doesn’t help in the situation at all.

So how Firesheep work actually?

Firesheep is developed as a plug-in for Firefox which can capture all the cookies which include login details, and if it successfully capture anything in an open network, you can just login to that particular website with the victim’s account. Below explained how it works (quote from the developer’s blog)

When logging into a website you usually start by submitting your username and password. The server then checks to see if an account matching this information exists and if so, replies back to you with a "cookie" which is used by your browser for all subsequent requests.

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.

In short, if you are using your social networks for example, in any public open WiFi network (even in a closed, secured network or router), the PC/laptop installed with this plug-in will capture the login session and the owner can just login to their account without hassle. Below is the screenshot of the Firefox installed with the Firesheep plug-in. Notice the left sidebar of the browser, those are the accounts captured by Firesheep in the same network, and double click on them easily lead you to the login-ed webpage with that particular account. Isn’t this TERRIBLE?

I will not cover step-by-step on how to run Firesheep, but it is just a plug-in for Firefox so it is relatively simple to install it and use it. Of course you will need the Mozilla Firefox browser, the latest version (3.6.12), not the beta version since it is not supported currently, and you will need to install Winpcap prior to the hacking. You can have more information at the Firesheep site. For Windows 7 user (especially 64 bit, as I have tried myself), you will need another software called Cain & Abel, and if you aren’t sure how it works, here is a tutorial in YouTube which show you a step-by-step to use Cain & Abel with Firesheep. I can confirmed it is 100% work as I have tried myself and successfully captured the login session on the other PC connected to the same router.

How to counter this plug-in?

You must be saying ”Darn. I can’t use Facebook, Twitter etc, now if there’s a Firesheep-enabled computer around!” Fear not, while this plug-in can have your login session exposed, there is always some way to counter/prevent it from happen.

• Stop using those web services. But I don’t think you want to do this, so continue to read on for alternative solution.
• HTTPS-Everywhere – This is a Firefox extension created by the Electronic Frontier Foundation which makes Firefox use only HTTPS connections for certain websites. Like Firesheep, it only works on a defined list of websites, so it won’t protect you if you use any websites that it doesn’t support. It does not appear to be immediately simple for users to add sites without some development experience. HTTPS-Everywhere is well respected for doing what it claims to do safely.
• Force-TLS – As mentioned earlier, some websites support SSL but don’t implement it properly, leaving you at risk. This Firefox extension is similar to HTTPS-Everywhere but allows you to specify your own list of domain names to force encryption on.
• VPN – In some situations a VPN (or something similar such as an SSH tunnel) can be great. All traffic sent through a VPN is likely secure from your computer to the VPN server. But be aware that this is not a silver bullet and there are potential problems.
• Firesheep’s enemy – Blacksheep – Here’s how Blacksheep work: Firesheep’s packet sniffing can’t be detected, but what can be detected is Firesheep’s requests to websites like Facebook using your cookies. BlackSheep detects this type of activity by making requests to random sites known to FireSheep every five minutes (you can adjust the timing) with fake values. So if anyone else on the network starts using those same fake values to make requests, then BlackSheep knows someone on the network is using Firesheep, and you get a warning in your current browser tab (something like the screenshot below). So if you prefer this way, go ahead to Blacksheep website and install this Firefox plug-in as how you install Firesheep, since it is developed based on the Firesheep codes – think it as a counter-hack. Be aware that Firesheep and Blacksheep cannot be installed simultaneously though.

Why we can’t have a secured web services?

Websites that don’t have properly designed security architectures and implementations can make it very difficult for users to protect themselves. There’s a few levels of failure here that are worth noting.

Complete absence of SSL/HTTPS — This is rare nowadays for popular sites, but it’s not unheard of by any means. Until recently, Foursquare fell into this category. Naturally, if you use such sites you’re exposing everything needed to identify your session with the site, potentially even your password. This is particularly bad when you consider many people use the same password for many different accounts. It’s terrifying to think that something as mundane as a Foursquare password could get you in to that person’s email, or even financial websites.

Charging for SSL – GitHub and Evernote are some examples where you must pay to have full-session SSL. We have not confirmed if this is implemented properly once you pony up the cash but can confirm that on GitHub a free account that is associated with a paying organization leaves that entire company at risk. A basic expectation of privacy should not be a premium feature.

Forced SSL/HTTPS for posting of Login/Password credentials only – Most big sites are in this bucket. Facebook, Twitter, Github, etc. Years back, people realized that sending usernames and passwords in plaintext was a bad idea, and so everyone started encrypting the transmission of those particular assets, and boasting how secure they were because they use SSL with 128-bit encryption or whatever it may be, and pictures of locks everywhere. These sites may serve other content over HTTPS if you explicitly request it, but they’ll rarely be opportunistic about serving content over HTTPS. These sites fail to protect you because after you’ve authenticated, you’re issued a cookie that identifies you throughout your browsing session, but if you think about it that’s just as good as your username/password for 99% of the time.

Full HTTPS for everything — Some sites support full encryption everywhere, but don’t implement it properly by failing to set the “Secure” flag on authentication cookies, negating most of the benefits and leaving users at risk. What that means is that any time you type the URL (e.g. “manage.slicehost.com”) into your web browser (without explicitly typing https:// beforehand, which people rarely do) you will inadvertently leak your cookies with that first request, prior to being redirected to the HTTPS page. Slicehost and Dropbox are good examples of this mistake.

^{Quoted from Codebutler.}

Further reading about it

If you are interested to know more about Firesheep and what’s the reaction about his plug-in, log on to http://codebutler.com/.

Source: Codebutler, ZScaler, Mashable