Slashdot Mirror
Firesheep Countermeasure Tool BlackSheep
Orome1 writes "Slashdot already covered Firesheep, the Firefox extension that makes it easier to steal logins and take over social media and email accounts after users log in from a WiFi hotspot or even their own unprotected network. Zscaler researchers have created, and are now offering to every consumer, a free Firefox plugin called BlackSheep, which serves as a counter-measure. BlackSheep combats Firesheep by monitoring traffic and then alerting users if Firesheep is being used on the network. BlackSheep does this by dropping 'fake' session ID information on the wire and then monitors traffic to see if it has been hijacked."
Secure login doesn't matter. You need secure everything, or people can just steal your session cookie. That is almost as bad as having your login stolen.
Most email and social network site do use a secure login, but it's not logging in that's the issue. After you've logged in securely, your session information keeps getting sent back and forth over regular http, instead of https, and there is enough information in there for firesheep to impersonate you.
Exactly, this is what EFF's Firefox Addon does
The issue with Firesheep is session hijacking, not theft of login and password information.
For how long can a session be hijacked anyway? If you close your browser, is the seesion instantly invalidated? Or only after like 5 minutes? I mean, in that case, Blacksheep could scream all it wants, and you'll still be a potential victim even if it warned you and you closed your browser (or tab).
As long as the hijacker keeps using your session the session will stay alive, even if you close your browser. But if you actually log out of the website then the hijacker gets kicked off too. So if Blacksheep tells you that someone's on your account then log out of Facebook immediately. Or, better yet, check that your email address hasn't been changed while the other guy's been on your account, then log out.
Mmm neat, but force-tls is not helpful for wikipedia (and other similar sites), that need mapping from en.wikipedia.org/wiki/Google to secure.wikimedia.org/wikipedia/en/wiki/Google
Mmm I have not pasted the link properly... EFF's plugin can map automatically from http://en.wikipedia.org/wiki/Google to https://secure.wikimedia.org/wikipedia/en/wiki/Google It is not possible with force-tls
Tools for detecting malicious actors certainly have their place(even if you are cryptographically protected from them, it's always nice to know what sort of neighborhood you are currently in); but the idea of playing cat-and-mouse when you could be playing cat and enciphered-such-that-it-will-be-inedible-long-after-the-sun-has-devoured-the-inner-planets-mouse is seriously head -> desk...
Spot-on, Force-tls actually prevents DNS spoffing attacks and nothing more. Say you try to visit http://www.bankofamerica.com/ from starbucks, someone might spoof the dns and redirect you to their own page rather than https://www.bankofamerica.com/ . Force-tls prevents this by not requesting for the http page and directly requesting for the secure page (it knows for what pages it has to request using https, by remembering the last time you visited the site (to be more specific, whether the site had sent a X-Force-TLS when you had visited them before)).
As far as I know, Twitter doesn't behave this way. If you log out on machine_x, only machine_x is logged out. Not the attacker.
GMail's "Destroy all other sessions" would be closer to the behaviour you're talking about.
However two different "machines" (even two different browser sessions on the same machine) should get different session IDs. As such, this would be expected, since each session is independent. The session ID is, generally, just a cookie with a specific value, your browser hands this back with every request, thus associating each request to the session.
So if you logout, and that invalidates the session, then this is to be expected, since each browser/machine has its own session cookie, each one is independent.
This is not the situation for a hijacked session. The original session and the hijacker will both have the same ID. So when you log out, if that invalidates the session properly, then the hijacker is logged out too, even if other sessions are still active.
Of course, this is "in general how it works". Most sites probably follow this model and will work this way. There is nothing to say all sites will. A site could easily correlate sessions and either allow only one session at a time for a user, or any number of things that would make it behave differently.... but usually you will have different sessions in each browser.
-Steve
"I opened my eyes, and everything went dark again"