Liar, Liar, Sheep on Fire

4797488117_d0b7fbf989_z.jpeg 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 you 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 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.


  1. It’s not only coffeeshop Wi-Fi you should be concerned about – don’t forget about securing your home router as well with a crytopgraphically-strong password.

    1. pato pal ur, a strong password isn’t going to help you if you are using WEP. In fact, you can probably crack WEP in less time than it takes to enter your cryptographically strong password.

      Use WPA with a strong password.

      1. Good point. If your router is old and does not support WPA then you need to buy a new one as all routers since 2006 are required to be WPA2-enabled.

  2. I have some policy blocking ad ons (ie requestpolicy and betterprivacy) and windows can’t get this add on to work. I guess I’m safe lol?

  3. I’ve wondered about this vaguely for a while- at my school, the wifi is unencrypted. You need to register your MAC to get on, but it’s not actually encrypted.

    In other words, Firesheep should work beautifully here. My wifi card doesn’t seem to like it, though, so I can’t say for sure.

  4. If you have access to a server that accepts SSH connection (and can get to the internet), you can always set up a SOCKS5 proxy using ssh. It’s pretty straight forward (I’m using port 9999 as an example)

    ssh -D 9999

    In your SOCKS aware programs (email, browser, etc…), set the SOCKS5 proxy as localhost:9999

    It’s not as good as having a VPN with a proxy at the other end, but it will work in a pinch.

  5. Thankfully I am currently using a secure connection so I can log in to boingboing, a site that can be sidejacked by Firesheep easily. For those of you wanting to try this, you do need a wireless card which can function in passive or “monitor” mode. If in Windows you will probably need to use different drivers then your standard set.

    For those who care, the program is great. I have already helped different people understand how to be more secure in there lives. It is funny how a friend will not listen to what you have to say about security until you begin posting the warnings as him on his favorite social networking site. Also interesting is that many sites that have a mobile variant are vulnerable even if the non-mobile version of the site is not.

    I this program is most important not b/c of what it does (since many people have been able to do exactly what this program does for several years at least) but because it makes it so incredibly easy. Btw, I will not list them, but not all banks are protected from this type of exploit, although they all should be.

  6. I installed this on my mac and a day later Virus Barrier caught it as a virus. I uninstalled either way.

  7. The problem with HTTPS everywhere, unfortunately, is that you need a trusted signature signing authority. Currently, as I understand it (and I only know this second hand, so correct me if I get some details wrong), you need to pay several hundred dollars a year for one of the commercial signing authorities to sign your SSL cert and allow for easy HTTPS. Otherwise, if you run a small website and want to use HTTPS, you’re users will get an ‘untrusted certificate’ error.

    This is of course not an issue for a big company like Facebook or Google, but a big problem with universally extending HTTPS to the entire web ecosystem.

    1. The problem with HTTPS everywhere, unfortunately, is that you need a trusted signature signing authority.

      Are you sure about that? Can sites not self-sign their certificates?

      That obviously loses some of the features available with a trusted signing authority, but still gets you some useful features.

      1. Can sites not self-sign their certificates?

        That obviously loses some of the features available with a trusted signing authority, but still gets you some useful features.

        I would argue they lose nearly all of the security benefits of SSL, and even makes it worse for users of sites that implement SSL properly, by getting them used to ignoring SSL errors.

        1. I would argue they lose nearly all of the security benefits of SSL

          I’d like to know more about what you see as the benefits of SSL.

          For most traffic all I need is to know that the communication to the server is encrypted so that other users at the coffee shop or whatever can’t hijack the connection or see what it is carrying.

          For my bank and other such high-value systems obviously I want a greater level of security where there are more reliable protections against more sophisticated types of attacks.

          1. For most traffic all I need is to know that the communication to the server is encrypted so that other users at the coffee shop or whatever can’t hijack the connection or see what it is carrying.

            Your communication to the server will be encrypted all right. The problem is you won’t know what server you are connected to. It could very well be that hipster looking dude over there playing man-in-the-middle with his laptop.

          2. The problem is you won’t know what server you are connected to.

            Can you explain briefly how SSL with certificates signed by a signing authority prevents a man-in-the middle?

          3. Browsers and operating systems come preconfigured with certificate authority information to bootstrap SSL/TLS. CAs can sign other CAs, too, through chained certificates, allowing the use of CAs not included in a browser/OS as de facto valid.

            When a browser and server initiate an SSL/TLS connection, the browser can opt, using the CA information that it has built in or from the OS out of band (not in the same communications channel that could be compromised) to contact the CA to validate the server’s certificate information.

            A man in the middle would need a valid certificate for the domain signed by a valid CA in order for the browser to accept that security is established. There have been social engineering attempts, and also some revoke CAs that improperly issue certificates without checking the identity of the party requesting it. (There’s a certificate revocation process, too.)

            A man-in-the-middle with a still-valid certificate for a popular domain signed by a still-valid CA (before it’s discovered) could compromise connections if it could also poison ARP and potentially poison DNS!

          4. Did Glenn Fleischmann’s explanation make sense to you?

            Just to reiterate – that’s what the CA signing process is for – it’s the CA certifying that they have verified that the person who submitted the certificate request to them, is in fact
            – who they claim to be (in the case of a personal cert such as you might use for email encryption), or
            – a legitimate operator of the domain name for which they requested the certificate (in the case of a certificate for a server)

            So, now, you enter in your browser’s address bar, and hit return. The browser requests the OS to make a DNS query, to look up an IP address based on the name, but that result could be incorrect due to error or deliberate tampering. The browser makes a connection to that IP address, but that connection could also be misrouted due to error or deliberate tampering.

            Now, the browser establishes the SSL connection. It checks that the certificate is for the host name, that the period of validity of the cert hasn’t expired, and that the cert is signed by a trusted CA.

            If all that holds, then the browser will let the connection proceed without alerting you of an error, having ascertained that
            – It is in direct, untamperable, unsnoopable contact with a server that is in possession of the certificate that was just presented to it.
            – The host name in the certificate matches the host name the user intended to connect to.
            – The certificate is currently valid.
            – An organization this browser (or operating system) is configured to trust has certified that the certificate presented to the browser, was requested by a person who was entitled to make such a request on behalf of the Bank of America.

            That last statement is actually somewhat weaker than the others – a basic certificate only certifies that they’re entitled to make the request on behalf of the domain An extended validation certificate (if I’m remembering the term correctly) will extend to cover what corporate entity is making the claim to the domain name. Modern browsers will display additional information when they see an extended validation cert.

    2. Yes and no, sheepdawg.

      The key term in “HTTPS everywhere” is actually the “Everywhere” part. The vulnerability Firesheep targets is the use of authentication cookies sent without SSL, after a login process that (typically) used SSL for the credentials themselves.

      It’s true that SSL certificates cost a few hundred bucks, which can be an issue at times for smaller sites, but this is targetting sites that already have SSL certificates, but design their sites to not use that SSL protection completely.

      Oh, and @IPFREELY – If you’re on a small coffeeshop network, the odds are very high that the WiFi network will use private addresses, and everyone in the place will be NATed to the same Internet-visible IP address once their web traffic hits the Internet. At that point, you and the cookie-hijacker at the next table have the same IP anyway. And, depending on the NAT scheme, it’s quite easy for a single internal computer to bounce around from one Internet-visible IP address to another, inside the expiration lifetime of a cookie (to say nothing of walking down the block from the coffeeshop to the library).

  8. I remember reading an article a while back, in which there was an interview with an undisclosed source working at Facebook. I could have swore that they were using coded storage to prevent theft and manipulation, but yeah, there’s some other old school tracking software and even Microsoft has free TCP monitoring. Can the same cookie be used by multiple IPs?

  9. Um, I’m installing AnchorFree and came across this on the EULA: “It is AnchorFree’s policy to respond to notices of alleged copyright infringement that company with the Digital Millennium Copyright Act, For more information, please go to AnchorFree’s DMCA Notification Guidelines.”
    Isn’t that a bit ominous from a supposedly anonymiser/secure service? Makes it sound like AnchorFree is a honeypot rather than a serious service… am I wrong or paranoid on this one?

  10. There are a few different approaches that people can take to protect themselves. Most are over the technical abilities of most users unfortunately.

    One simple option is a Firefox plug-in and it provides secure SSL encryption on any connection and is literally just download and go, instant protection. Full disclosure, I do work for the company, but the product is in beta and free, so give it a try and please share your feedback. Thanks! David

  11. I don’t know nothin’ bout no SQL/MAC/HTTPS/VPL/SSL/LOL juju, but I do know that tempting people with free software that would let them snoop on or log in as other people in the room…

    …would be a great way to trick people into downloading your malware. :)

  12. How to firesheep before firesheep:

    I wrote that back in June, but the actual vulnerability is inherent to ALL PHP SITES.
    Well, all php sites that don’t encrypt, anyway.

  13. Seems to me the security issue is inherent in the wireless router, not the web hosting service.

    addressing the issue where it is broke would be more effective than shotgunning the upstream services.

    Secure encryption between the pc/laptop/smart-phone and the wireless router would close this hole.

    So how about an SSL-like security protocol for each connection on ‘open’ wifi networks?

  14. OK, now explain how the average web user is supposed to protect themselves. Specifically, what are the settings for our laptops and where exactly do we go to set them????

Comments are closed.