Photo: Prasad Kholkute
Firesheep should freak you out, at least for a moment. It’s a Firefox extension that lets any normal human being–I’m not talking about you, BoingBoing readers–install the add-on and then steal the active sessions of people using unencrypted browsing sessions with popular online services on the same Wi-Fi network. This involves no Wi-Fi foolery, because the necessary network traffic is openly available.
Walk into any busy coffeeshop, fire up the ‘sheep, and a list of potential identities to assume at any of two dozen popular sites appears. Double-click, and you snarf their identifying token, and log in to the site in question as that person.
Firesheep is a business-model tour de force, not a zero-day technical one. It’s a proof of concept that repackages and expands on earlier security research to expose a failure in the risk profile adopted by Web sites on behalf of their unsuspecting users. There’s no money to be made by a Web site in fixing this problem for its customers or readers. Thus, only a security-conscious CIO might be able to push through the budget item necessary to bump the back-end systems up to the level needed.
Firesheep is a public relations exploit, too; it’s so easy to use and to demonstrate that it shot round the world. Previous demonstrations spread the word in the tech community, and a little beyond. Firesheep is telegenic.
The add-on is the latest effort to lay bare a well-known problem in how major (and minor) Web sites identify users after login. Even if you log in using a secure SSL/TLS connection, a reliable method of end-to-end encryption, many sites still hand you back to plain old HTTP. In the process, sites brand you with a token that stands in for the login process you completed. This is a separate issue from involuntary ad tracking or the undeletable evercookie. (BoingBoing is a practitioner of tokens for both commenting and the Submitterator, which arguably means that someone could post nonsense under your name from a coffeeshop, but don’t do that already?)
Because the open Web is stateless, a sequence of pages viewed by the same browser might as well be pages viewed by entirely different browsers. A login token placed in a cookie glues a binding on the edge of those pages, creating a session. The token doesn’t let a third party sniff your user name or password, but it does let a browser lay claim to your identity for a set period of time. (HTTP does have a stateful account-based authentication system, but it has weak cryptographic elements, and browsers have unchangeable interface elements for handling failed logins, lost passwords, or add-ons, like a CAPTCHA.)
The developer of Firesheep, Eric Butler, traces the understanding back to 2004, but 2007 is when knowledge went over the top. Robert Graham of Errata Security coined the term in 2007 in a Black Hat presentation. He created a proof-of-concept not much different in intent or function than Firesheep, but without the click-to-install simplicity, the long list of sites to snarf, and browser integration.
Of the large firms with this flaw, I’d argue that Google took this most seriously. In the intervening three years, Google has been layering SSL/TLS on ever more of its services. Gmail even added an option to kill other sessions. (Scroll to the bottom of the Gmail screen, and click Details at the end of the ‘last account activity’ line to view the option.)
Many other sites have let the problem remain, though, beefing up security through the sop of offering secure logins, as noted above. It’s quite rare to find any major site allowing an unencrypted login, which is a big improvement over a few years ago. Firesheep comes with 26 prefabricated sidejacking tools for sites like Facebook, Amazon, and bit.ly. Amazon and other sites that have a mix of plain HTTP and SSL/TLS-protected pages require re-authentication and SSL/TLS when you move into making a purchase, canceling an order, or other account-based activities. But you can place a 1-Click order without logging in again.
Less-visited sites in the millions have this sheepish problem, and some use identical software (and thus token names in the browser) making a mass-exploit via a Firesheep update the work of minutes. But it’s far less likely a random coffeeshop ne’er-do-well would sidejack such a session, or get anything out of it.
The remaining question is, of course, what can you do to prevent your credentials from making you go baaaaaaaaaa? Lots.
* Firefox users should install HTTPS Everywhere, a joint effort of The Tor Project and the Electronic Frontier Foundation. This forces SSL/TLS connections for sites that offer, but don’t require, continuous secured browsing, including content sites like the New York Times and Wikipedia. You can use the Tools > Add-Ons option to disable specific sites if you have trouble.
* Engage in no unsecured Web logins when working on an untrusted network, public or otherwise. This is my primary approach after HTTPS Everywhere. It’s easier than it sounds. If I can’t use SSL/TLS through a session, I don’t do it unless I use a VPN (see below).
* Secure all the services you use. Most email hosts offers SSL/TLS protected POP, IMAP, and SMTP sessions. FTP is absolutely in the clear; use SFTP (an SSH-based variant) or FTPS (FTP with SSL/TLS encryption). Check the box for SSL/TLS anywhere it’s available. Twitter’s API for third-party clients defaults to unprotected transactions; Echofon, at least, has a ‘use SSL’ box I check.
* Use a VPN. A virtual private network connection creates an encrypted tunnel for all your data between your computer or mobile and a server somewhere else on the Internet. That’s typically more than enough to protect you from sniffing on the local link. I’ve used WiTopia for years, which is a fee-based service offering PPTP and SSL VPN connections. AnchorFree offers Hotspot Shield at no cost.
* Instead of a VPN, set up an SSL/TLS Web proxy through which all your browsing is rerouted. That also protects the local link, and can be easier if you have a server elsewhere that you can set this up, or use a paid service.
Eric Butler has complementary advice in a post on his site about the day after releasing Firesheep that he wrote with co-presenter Ian Gallgher. Read that for more on what does not work, too.
Firesheep is named after the famous Wall of Sheep at Defcon, which displays selected details of unencrypted logins and other sessions over the event’s Wi-Fi network from people who, by attending Defcon, should know better than to ever send anything unencrypted over a public Wi-Fi network. If Firesheep succeeds, the whole world becomes a Wall of Shame, with the shame reflecting on the sites that haven’t updated their costs and systems to reflect the current reality of basic security when their users surf in public.
Glenn Fleishman contributes continuously to the Economist’s Babbage blog, and is a senior editor at the Mac journal TidBITS.
“
