Mozilla Security Blog
Categories: Firefox Security

Cooling Down the Firesheep

mozilla

18 responses

There have been a number of reports about a new Firesheep tool that exposes a weakness in website security, letting attackers snoop on people using public networks, steal their cookies, access their accounts and pose as them on sites such as Facebook and Twitter. While the developers chose to use the Firefox add-on API, the tool could have just as easily been written and distributed as a stand-alone program.

The introduction of this tool reinforces the importance of websites configuring themselves to require secure connections.

Not too long ago we announced HTTP Strict-Transport-Security that can be used to — among other things — ensure your Facebook or Twitter cookies can’t be sniffed by someone using a tool like Firesheep. In fact, it’s built into Firefox 4. To protect their users from the this attack, a site simply needs to set the Strict-Transport-Security HTTP header when they serve you a secure log-in page, and make the rest of their site available over HTTPS. Firefox will take care of the rest: automatically fetching that site over a secure connection and blocking any third parties from seeing the unencrypted traffic.

We recommend that website authors make use of this header in order to protect their users.

But this technology is new to Firefox 4. To get HTTP Strict-Transport-Security support in Firefox 3.6, you will need to install an add-on that implements it such as ForceTLS. ForceTLS also gives you a way to opt-in to this extra security for sites who haven’t yet started sending that helpful HTTP header; it provides a user interface to add and remove sites that should never be contacted insecurely. Both HSTS and the manual opt-in are also available as part of NoScript. However, manually opting-in to HSTS on a site which does not yet make itself fully available securely may break the site; not all sites are ready for secure access.

If you are already using Firefox 4 beta or nightly versions, you can enable the additional controls with the STS-UI add-on. While the core Strict-Transport-Security features are already built into Firefox 4, this UI gives advanced users the ability to further ensure the security of their connections.

Sid Stamm
Conspiracy Theorist

18 comments on “Cooling Down the Firesheep”

  1. David Naylor wrote on

    “While the core Strict-Transport-Security features are already built into Firefox 4, this UI gives advanced users the ability to further ensure the security of their connections.”

    What does this mean? Is there anything that needs enabling for Firefox 4 to play nicely with servers that support this?

    1. Sid Stamm wrote on

      @David Naylor: Firefox 4 will work properly with sites that support HSTS by serving the Strict-Transport-Security header.

      You can enable Strict-Transport-Security on sites that don’t advertise the HTTP header using the optional STS-UI add-on. Be careful though, since not all sites are properly configured to serve all their content over HTTPS; enabling HSTS on a site not expecting it can cause bits of the site to break.

  2. David Naylor wrote on

    Ok, thx.

  3. Robert Graham wrote on

    There have already been standalone tools that do this, namely my Hamster program described here that was published in 2007:

    http://erratasec.blogspot.com/2009/03/hamster-20-and-ferret-20.html

  4. Concerned User wrote on

    Force TLS and HTTPS Everywhere are both great addons that help prevent this attack, SSL search bar addons are also available:

    http://is.gd/goIS0

  5. Daniel Veditz wrote on

    The id.gd link in comment 5 is broken (you can’t redirect to two URLs at the same time). It was meant to point at these two collections:

    https://addons.mozilla.org/en-US/firefox/collections/sslsearch/

  6. Georgia wrote on

    Is this issue relevant for home wireless password protected networks or just the public/no password areas?

  7. Daniel Veditz wrote on

    @Georgia: The attack can be performed by anyone in a position to observe your network traffic (wireless or not). In practical terms you are most at risk when using an unsecured wifi network, and less at risk to the extent your end-point is secured (WEP is easily cracked, WPA2 is good).

  8. James McKee wrote on

    I find it truly troubling that these types of exploits are available so easily on wireless hotspots. I think the problem could be addressed from a both network admin and a user angle though. It is the user’s responsibility to keep their security up to date, however I would like to point out that there should be some obligation on the part of the wireless provider to establish reasonable security measures unless they have stated otherwise (use at your own risk for example). While I certainly wouldn’t want to see a wave of litigation against hotspot providers for their users being hacked by other users on the network I think that the protection should begin at the hub you connect to.

  9. Daniel Veditz wrote on

    James McKee: this is a website problem, not a wireless hotspot problem. People attack free wifi spots because it’s where random unknown people can connect to a network with other potential victims. Depending on how the network is set up you could potentially do the same attack (using Firesheep, even) on a wired office network–if you were willing to risk messing with people you know rather than people you’ll never see again. And of course some people would be more, not less, motivated to mess with people they knew.

    As long as the websites are insecure in this way the attack can be performed anywhere along the network. Imagine, for instance, that you use a wireless hotspot secured with WPA2 encryption that requires you to get a password from the shop clerk. You may be secure from random bored Firesheep users, but the folks running the hotspot could do the same attack by watching the traffic going through the router. Yes, the store workers probably have less interest in hacking you than a visiting geek with a new toy, but do you really want your privacy to depend on the disinterest of every person involved in operating the internet infrastructure between you and the site?

  10. James McKee wrote on

    @ Daniel, right I understand that it’s not a “wireless hotspot” problem per se however you do state in your blog that “a new Firesheep tool that exposes a weakness in website security, letting attackers snoop on people using *public networks*, steal their cookies, access their accounts and pose as them on sites such as Facebook and Twitter”. I apologize for my assumption but when I hear the words “public network” I think of something unsecured and easily accessed by anyone i.e. a wireless hotspot or some other open network (such as one found at a University).

    Could you define what you mean by a “public network”?

    From what I read here http://codebutler.com/firesheep this attack is indeed best practiced on an open public wi-fi network. If you would explain what type of network these attacks are best executed on it would help me to understand better. While I understand this is not necessarily a “network” problem and is a “website” problem couldn’t there be some way for a network administrator to close the ports Firesheep uses in much the same way some networks block things like torrent clients? Thanks!

  11. SSL Certificate wrote on

    Reports have been trickling in that Microsoft’s anti-virus software is now detecting Firesheep as a threat, despite the fact that Firesheep poses absolutely no threat to the integrity of the system it’s installed on, and as mentioned earlier, has many legitimate uses.

  12. Daniel Veditz wrote on

    @James: Sid, who wrote the blog post, was talking about Firesheep, and it does indeed work “best” on a public network because that’s where random attackers can attach to the same sub-net as lots of insecure victims.

    Firesheep can’t be blocked like torrent clients because it’s not using the network, it’s merely observing it. There is no way to detect Firesheep use, and even if you could there’s no way to block its use other than to keep its users off the network.

    Before Firesheep empowered non-technical reporters to perform this attack, the exact same attack could be done manually by anyone who knew what Wireshark is.

  13. Daniel Veditz wrote on

    > as mentioned earlier, has many legitimate uses.

    I don’t see an earlier mention of any legitimate uses here, let alone “many”. I can think of one, getting reporters to write about the problem and thereby pressure the sites into fixing it. What else?

  14. Moose wrote on

    >I don’t see an earlier mention of any legitimate uses here, let
    >alone “many”. I can think of one, getting reporters to write about
    >the problem and thereby pressure the sites into fixing it. What else?

    What about running it on your home wireless network while other family members use the network to see where they are at risk and see how to plug the gaps ?

    What about a wireless hotspot (coffee shop, etc) doing the same to trial different security settings and see what stops Firesheep, etc the best ?

  15. Daniel Veditz wrote on

    > Firesheep can’t be blocked like torrent clients because it’s not
    > using the network, it’s merely observing it. There is no way to
    > detect Firesheep use, and even if you could there’s no way to
    > block its use other than to keep its users off the network.

    I was wrong: you can, in fact, detect Firesheep. Although it could have been written to be entirely passive, it does generate detectable network traffic gathering user information to present in its user interface. Zscaler has created a tool called “Blacksheep” it claims (I have not tested it) will detect Firesheep use. Some commenters report it makes Firefox crash on startup and I’m not endorsing or recommending this tool, just correcting my earlier misstatement.

    http://research.zscaler.com/2010/11/blacksheep-tool-to-detect-firesheep.html

    Armed with that information the manager of the wireless hotspot could theoretically ban the MAC address of any machine detected running Firesheep. In practice the typical coffee shop wouldn’t have the personnel to actively manage its wireless hotspot. Someone could write an automated tool that could be distributed to hotspot owners, but Firesheep clones may be able to morph faster than software updates could be distributed to the detection tool.

  16. Teisines paslaugos wrote on

    What about running it on your home wireless network while other family members use the network to see where they are at risk and see how to plug the gaps ?

  17. Daniel Veditz wrote on

    You can run Firesheep to get an idea of whether you or your family use any web sites that would be vulnerable to other people running Firesheep. BUT

    1) you can’t always “plug the gaps”. If the site isn’t available over SSL there’s nothing you can do but stop using the site. If the site does offer SSL support then a tool like Force-TLS or STS-UI can help protect you against mistakes in the site’s SSL support.

    2) Routing your traffic through a VPN or Tor may protect you against local Firesheep attackers, but you’re still vulnerable wherever the other end of the pipe comes out if the site isn’t using SSL.

    3) Firesheep is a demonstration, and for that purpose the author targets a limited number of popular services. Coming up clean in Firesheep only has meaning with respect to those services and doesn’t say anything about whether you’re safe using some other site. There have been “sidejacking” tools available for more than 3 years now (see Robert Graham’s comment 3 above) and with just a little more work the attack could be performed on any non-SSL site that interests the attacker.

    If your comment is in response to my comment 14 you’re saying a legitimate use for Firesheep is to detect whether you are safe from Firesheep. I admit I may have been exaggerating (slightly), but that use seems painfully self-inflicted. If Firesheep cost money it would almost border on extortion.

    No, the real point of Firesheep is to make the problem so painfully obvious that public outcry would force sites to fix what they should have fixed three years ago (again see comment 3).