Releasing Firesheep: Right Intention, Wrong Action
October 25, 2010
Eric Butler released Firesheep, a Firefox extension that makes stealing others' Web sessions trivial. Firesheep steals the cookies associated with a user session and then uses the cookie to let you, the attacker, start a new HTTP session impersonating the victim. It's trivial. All you need is to be able to sniff the traffic over the air or off the wire. I spent all of 3 minutes downloading and installing Firesheep before I hijacked my wife's Facebook session. It also works on other common social media sites such as Twitter and Yelp. You can also add new sites that use session cookies.
Butler said he released Firesheep to shine a light on a prevalent problem. I agree that session stealing, aka sidejacking, should be addressed. But releasing a tool my grandmother could use is irresponsible.
I have long been an advocate for full disclosure. Software vendors have a responsibility to write and release secure code. Yet common, and fixable, problems persist, including buffer overflows or the failure to scrub input. Unfortunately, software vendors tend to put revenue above user security and won't actually fix problems in a timely manner unless there is a direct threat to their revenue. I won't get into the history, but there are plenty of examples from the last ten years. Full disclosure is the stick that makes recalcitrant vendors act responsibly.
Responsible disclosure is the carrot. The idea behind responsible disclosure is to give the vendor time to fix a problem before the problem is announced. No one expects software to be defect-free and squashing bugs takes time. Responsible disclosure is effective because everyone gets to be a good guy: Vendors get PR credit for fixing the problem. Researchers get props for their work. Most importantly, customers get a more secure product. But the game changes when one party or the other fails to act responsibly. (And no, I don't have a definition of "timely" or "responsible" and I don't want to go there--at least not in this post.)
Session cookies should be protected, particularly as social media sites get more popular. Web sites use session cookies because keeping users logged in is easier than re-entering credentials, but session cookies are bad for user security because sidejacking is relatively simple. All you needed was a protocol analyzer, access to the media. Knowledge of a particular web applications cookie usage (they are all different). The ability to copy the session cookie, or relevant bytes of a session cookie, into a new HTTP session. Ok, sidejacking wasn't trivial for your average bear, but it was possible.