3

Am doing a Firesheep Demo in a few weeks as a security awareness project. However I can't seem to get it working, and I'm wondering if it's just because the handlers it ships with are now outdated because everyone has fixed their sites.

I am going to continue to troubleshoot from the promiscuous drivers etc. side of things, but was wondering if:

  1. Anyone could tell me which sites are still vulnerable to Firesheep?

  2. Could someone share the handler scripts that work against those sites? (I'll of course try writing them myself, once I can tell that it's working as expected).

Edit: Thanks for the comments. I do understand what makes a site vulnerable, but it would still be great to have some examples from those who have a currently working install of Firesheep, just for some certainty. And a sample of a known working handler script would be fantastic!

scuzzy-delta
  • 9,303
  • 3
  • 33
  • 54
  • 2
    Any website that doesn't use HTTPS across all connections that pass a session cookie are vulnerable to it. In other words, 99% of the internet is still vulnerable. – Steve Feb 13 '12 at 04:01
  • 5
    StackOverflow.com and security.stackexchange.com :( – rook Feb 13 '12 at 04:14
  • Thank you all for feedback. Problem turned out to be hardware-related. Resorted to using a Mac as the attacker and finally got some handlers working :) – scuzzy-delta Feb 22 '12 at 21:16

3 Answers3

9

Bottom line, anything that does not use HTTPS for all connections is vulnerable to Firesheep.

I can imagine that a lot of the original handler scripts no longer work because a large number of sites have fixed their sites to use HTTPS. Or if they were really lazy they just modified things slightly to obscure things.

I tried out Firesheep when it was released and I couldn't listen to public traffic with my laptop's built-in wifi card. If that is the problem you are having it is probably because it doesn't support monitoring mode. A 10-20$ usb wifi dongle will solve that problem. I have an ASUS USB-N13 that supports monitoring mode. I believe it goes for 20$ or so now.

As Rook mentions, the whole Stack Exchange network of sites is vulnerable. In fact, last time I checked the creators of Stack Exchange don't even think it is important. Or at the very least it was not important enough for the difficulty involved.

Firesheep is intended to show the well known insecurity of not using HTTPS. It did it's job well as many website started using HTTPS right after its release.

There is another use for Firesheep that is a little less known. It can also be used over encrypted WPA2-AES networks to show the "Hole196" vulnerability in WPA2. I don't believe the original version of Firesheep includes this functionality but modified versions exist that do. The creator of Firesheep thought that including the WPA2 feature was too dangerous, and I agree. (citation needed)

Community
  • 1
WalterJ89
  • 747
  • 6
  • 10
  • I'm not sure HTTPS needs to be used for everything or you are vulnerable. HTTPS just needs to be used for everything that you want to keep private from eavesdroppers and tamperers (and recognize that even with HTTPS - they can still find out how much traffic was sent and which servers sent it). – dr jimbob Feb 16 '12 at 22:11
  • 2
    @drjimbob well more accurately firesheep just looks for session cookies that are sent in plaintext and just hijacks them. Anything that you are not logged into won't have a session to steal. Also any sites that don't set the "secure" flag for sessions are vulnerable to leaking the session info in plain text. – WalterJ89 Feb 17 '12 at 00:17
  • Thanks for the clarification. (I use wireshark frequently for various debugging purposes. I don't have a desire/need to steal cookies so never really looked in to firesheep; and just assumed it could steal more than it could). – dr jimbob Feb 18 '12 at 16:22
3

As rook, pointed out stackexchange sites do not use secure (HTTPS-only) cookies or HTTPS anywhere on their sites (other than authentication through a third-party).

That means that when you are logged in to stackexchange an eavesdropper (using firesheep, wireshark or similar) can steal your cookies that indicate that you are logged into stackexchange. They can then use these cookies for months to access your account as you.

Now they may also be able to grab your actual password that's tied to your username if they eavesdrop when you login, depending on the mechanism you use. That is if you login through google/yahoo/myopenid/facebook your login credentials will be protected to eavesdroppers capturing packets over the network.

However (!), if you sign in using a stackexchange account there is no https (even in the form's post action), so your username/password is sent to stackexchange in plain text to anyone bothering to listen.

Community
  • 1
dr jimbob
  • 38,768
  • 8
  • 92
  • 161
0

There are two kinds of sites that are vulnerable:

  1. Sites that uses HTTP anywhere on the site. Some sites only support HTTP and don't support HTTPS (e.g., StackExchange); they are vulnerable. Some sites use a mix of HTTP and HTTPS (e.g., Amazon); they too are usually vulnerable.

  2. Sites that use cookies that don't have the secure flag set. Cookies with the secure flag will only be sent over HTTPS. Cookies without the secure flag will be returned to the site over any connection, including both HTTP and HTTPS. (If a site sets a non-secure cookie over a HTTPS connection, it will still be sent on HTTP connections.) Thus, if the site sets any non-secure cookies, an active attacker can trigger your browser to connect to the site via HTTP and then steal the cookie. This applies even if the site uses HTTPS sitewide.

To defend against Firesheep-like attacks, sites must do two things:

  1. They must use HTTPS sitewide. (Don't use HTTP for anything.)

  2. They must set the secure flag on all cookies.

They need to do both: just one is not enough.

D.W.
  • 98,420
  • 30
  • 267
  • 572