Tonight was protocol study night at my local hacker space where 5-10 people get together every Wednesday to dissect various networking protocols to see how they tick. We use a combination of things like Wireshark, The TCP/IP Guide
So by now everyone has heard of FireSheep. The concepts are nothing new but the author put everything into a pretty little browser plugin that makes it super easy for ANYONE to steal your Facebook, Twitter, etc credentials. Within a day or two of FireSheep being released, BlackSheep quickly followed. The premise of BlackSheep is that it is supposed to protect you from users of FireSheep and not allow said users to steal your credentials. This would be nice if it actually worked. I’m here to tell you that it does NOT work. FireSheep looks like this:
So what both BlackSheep and FireShepard do is attempt to perform a Denial of Service attack of sorts against the user running FireSheep. They spam FireSheep with fake sessions and credentials that show your name but won’t actually log you in. They show up in your FireSheep window and attempt to flood your buffer with too much information. The problem with this is that your working credentials are still there and can still be used. The attacker merely has to sort out all the fake credentials, find the real ones and click on them. FireShepard has even more failure in this regard. The spoofed HTTP headers have several fields in them that are always identical. My favorite was this one:
request+=”GET /packetSniffingKillsKittens HTTP/1.1\r\n”;
Even if FireShepard did work better than it does(which is basically not at all), the person running FireSheep could then easily filter out all the spoofed credentials by filtering it on that phrase.
BlackSheep, on the other hand, attempts to detect if the fake credentials are being used and is supposed to alert you if this is the case. In our testing however, we did not see any indication of this feature working properly.
If FireSheep isn’t scary enough, we observed some other scary behavior of facebook’s cookies. Most notably, we hit logout(explicitly) on the Facebook session and closed the browser and cleared/restarted FireSheep. When we reopened the browser and went to Facebook, we were not yet signed in on the Facebook page but when we switch BACK over to Firesheep, we were already logged in!! In other words, we merely had to go to Facebook’s page for a cookie to be transmitted to them that allowed a full login.
Not all bad news…
We did find one good solution to this mess. It’s not a sexy new tool but instead something that I hope a lot of us are using already. The EFF’s HTTPS Everywhere Firefox browser plugin put a stop to FireSheep picking off any of the credentials. We tested this with a Gmail, Facebook and Twitter. Not one of them showed up on FireSheep after enabling HTTPS Everywhere. I have been using this plugin since it was released and have been extremely satisfied with it. My only complaints are that I have had problems with the HTTPS side of certain sites not loading correctly for me. Most notably Wikipedia and Twitter(for about 24 hours). Other than that, it’s been flawless. It’s one of those plugins you can basically set and forget.
Using a VPN and avoiding open public wifi connections are also great ideas.
Follow this link for more information on FireSheep, FireShepard and BlackSheep.
If you like the content on this site, please support it by using this link to order from Amazon. You know you were going to go there and buy stuff anyhow so why not help me pay the hosting bill.
I prefer Noscript since HTTPS Everywhere is basically forcing HTTPS with Noscript [1] without the latter’s protection against scripting and other attacks.
elf
[1] http://hackademix.net/2010/10/27/forcing-https-with-noscript/
The problem with no script is that it protects you by breaking nearly all of the enhanced content available on the web. Ultimately it ends up being too much trouble until you start white listing a lot of scripts. By the time you do that, you’ve sort of rendered it ineffective anyhow because conceivably a white listed script could become malicious/compromised at a later date.
I’ve tested it out by putting it on a few people’s computers which I fix. None of them were able to live with it and they ended up jumping back to (cringe)IE to actually get work done rather than screwing with security settings.
Taking into account what we learned about Facebook’s cookies during this exercise though, my best advice would be to ONLY surf Facebook in a separate browser that you use for NOTHING else. That way it’s not puking cookies out to every site you come across with a like button or otherwise. A bit of a hassle but also less likely for you to get tracked.
Whitelisting: actually most sites load scripts and objects from their own domains, from ad servers and from “social” sites (Facebook, MySpace, Flicker, Youtube, Digg, etc.) with only the former ones usually required for proper rendering and the others optional; if you want to load inpage videos or being able to Share/Like/Digg/Whatever that site, whitelist the parent site once or learn to enable on single object basis. I agree whitelisting, whatever temporary or permanent, doesn’t protect against malicious scripts loaded into popular and already whitelisted websites; nevertheless it’s effective against unlisted ones.
Learnt curve: did your friends ask for protection or did you just installed Noscript on their browsers? I bet it was the second case: best approach is user cooperation, which implies explaining why [s]he should use Noscript and how to set the whitelist. I managed to have my father and my mother use it with minimal hassle.
Separate browser: it’s true, but I bet Average Joe use only one browser and doesn’t even suspect anything about tracking. I’ll let you discover whatever managing multiple browsers or hardening one is a greater hassle 🙂
Edward