Live data from Hacker News

Firesheep: Easy HTTP session hijacking from within Firefox

codebutler.com

111–120 of 356 posts

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#111

Here is a simple tutorial on how to set up an SSH Tunnel for Mac OS X http://bit.ly/cffjOY This way all your communication is encrypted

To be clear, that tutorial was made in 2007, so is a bit dated. Also, it shows how to set up FF to use the proxy, but the idea of a tunnel is not FF-specific, nor is this vulnerability.

One big issue with SSH-tunnel as a solution is that anything not set up to use the proxy still works, it's just quietly vulnerable.

Any suggestions on making TCP traffic which doesn't go through the proxy totally fail?

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#112
post #90

It seems fine to just enable SSL everywhere. But indulge me for a second in thinking of alternate solutions. Instead of sending a cookie, send a piece of javascript code (as part of the SSL-cloaked login handshake) that generates a new cookie for each request, and consider each new cookie in this sequence a "one time use" token. You can turn off SSL for subsequent requests and just use one of these new cookies each t…

I think all cookies are sent with every request, so cookies can't be used to (securely) pass data to the next page. It'd work just fine on the login page, but every page after that would have to renegotiate to generate a new cookie, meaning you basically just created SSL everywhere.

Local storage, however, could probably be used to do just such a thing, as it exists only locally. In which case you could just have the login page generate an RSA key pair, receive the server's public key in the response, and use that for any kind of secure communication on each page load. The server would have to remember sessions => encryption keys, but that's not too hard.

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#113
post #87

Earlier quoted context omitted.

Also don't web-mail your friends to tell them about the new accounts you just broke into :) At least not on that open wireless connection.

Good thing GMail has SSL enabled by default ;)

Yup, they're one of our examples of a "good" setup. However, Google leaks iGoogle and some other things (Latitude, address book, reader, ...)

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#114

Has anyone checked the source code to check that the passwords aren't sent to the author's website? :)

It's 100% open source! Please feel free to review it.

http://github.com/codebutler/firesheep

It doesn't currently do anything with passwords, it's only pulling out cookies from HTTP Response headers. But it would be trivial to also get passwords in non-HTTPS requests for logins with the same method.

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#115
post #59

What can an end user do to minimize this? This exploit is for insecure Wifi networks- so only using encrypted Wi-fi or Ethernet would seem to remove this attack vector. Is there a real risk that someone (besides the government) can see your cookie?

logging out will cause the captured sessions to be useless. So remember to logout. VPN is really the best overall option.

Most sites don't properly invalidate sessions when you log out, you can't protect yourself as well as you think. See our slide on this topic:

http://codebutler.github.com/firesheep/tc12/#18

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#117
post #73

Earlier quoted context omitted.

I've personally been working from cafes and tunneling everything through SSH for years To where? I suspect it's to a server, VPS, or similar, and the connection is unencrypted from there to its endpoint. This being the case, could someone with a server on the same subnet be running a browser remotely (or even just tcpdump) and doing a similar thing with your logins? (This is just some thinking out loud and I may be t…

Virtually no modern wired networks use hubs anymore, they're for the most part switched. Unlike wireless networks where packets are broadcast freely in to the air, the switch checks the destination address and sends the packets only to the endpoint. There are some attacks like arp-spoofing and flooding which can defeat this, but they don't work well against modern enterprise-grade switches like you would find in a da…

Have a bazillion karma points. I didn't realize that switching resolved that whole problem. This is why I continue to bring up stupid hypothetical situations on HN from time to time ;-)

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#118
post #24

The sidebar is not showing up for me after installing and restarting. Firefox 3.6.11 OS X 10.6 firesheep-0.1-1.xpi

Same setup. Sidebar shows for me after selecting it from the View -> Sidebar menu, however it pops up with a message that says "Run --fix-permissions first." Not sure where I'm supposed to run this flag.

There is so many hoops I have to jump to make this work in OS X.

$ mv firesheep-backend firesheep-backend.binary $ cat > firesheep-backend #!/bin/sh sudo /path/to/firesheep-backend.binary $@ ^D $ sudo chmod +x firesheep-backend

Then restart Firefox and start capture. You need to run sudo once every certain period.

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#119

Earlier quoted context omitted.

vpn/ssh tunnel/encrypted wifi

Encrypted WiFi won't stop clients on the network from sniffing your packets. It will , however, stop unauthorised computers from sniffing any network data.

I would have expected each wireless client, on an encrypted network, to negotiate its own key with the access point -- so you'd only see neighbors' traffic if the access point chose to rebroadcast it to you.

Are you sure that neither WEP nor WPA/WPA2 do it this way?

Re: Firesheep: Easy HTTP session hijacking from within Firefox

#120
post #107

Earlier quoted context omitted.

When Gmail switched on SSL for everyone earlier this year they added "no additional machines" ( http://unblog.pidster.com/imperialviolet-overclocking-ssl ). Regarding IPs, there's a bigger issue here. People are used to being able to shut their laptop at home and open it back up at work without having to re-authenticate all their browser tabs. If you filter by IP this breaks. SSL requires no changes to user behavior.

What about pairing the auth token with a browser fingerprint? [1] It would make it harder to troll an open network for random victims, and wouldn't annoy the user. [1] Perhaps a hash based on something like this https://panopticlick.eff.org/

yep then you extend it to something as simple as having a second ID in localStorage or a flash cookie

then the next version of this plugin just spoofs all of those parameters as well

the only solution[1] is SSL and client certificates

[1] in the case of being on the same network

Post reply on HN