For anyone who has SSH access to a server (but not VPN) and is wondering what to do when you need some security in a pinch, here is a quick fix...<p>Open an ssh connection to a server you have access to using something like the following:<p>ssh -ND 8887 -p 22 rufus@12.120.186.8<p>where 8887 is the port on your laptop that you will tunnel through, -p 22 is the port the ssh server is on (22 is the default but I use a different port so I am used to specifying this) and the rest is your username and the address of the server<p>Set your network to point to the proxy. On a Mac that would be…<p>... Open Network Preferences…<p>... Click Advanced…<p>... Click Proxies…<p>... Check the SOCKS Proxy box then in the SOCKS Proxy Server field enter localhost and the port you used (8887)<p>... OK and Apply and you are done!<p>Now you can surf safely.
There are probably going to be a lot of people negatively affected by this for quite some time to come. One thing to point out is that there are grades of things. There is "public", and then there is "top hit on Google". Similarly, there is "insecure" and then there is "simple doubleclick tool to facilitate identity theft".<p>How many millions of dollars and man hours is it going to take to lock down every access point? How many new servers are going to be needed now that https is used for everything and requests can't be cached?<p>America was a better place when people could keep their doors unlocked, and when someone's first response to a break-in was to blame the <i>criminal</i>. By contrast it's fashionable among a certain set (no doubt including the author of this mess, Mr. Butler himself) to hold that the real culprits are the door manufacturers. What said facile analysis excludes, of course is that there is <i>always</i> a greater level of security possible. The level we currently employ reflects our tradeoffs between the available threats and the cost/convenience loss of bolting our doors and putting finials on our gates.<p>Butler has simply raised the threat level for everyone. He did not invent a new lock or close a hole. He's now forcing lots of people to live up to <i>his</i> level of security. Congratulations to the new Jason Fortuny.
This is kind of a big deal. Not a whole lot of people are aware of this vulnerability and among those who are it's likely only a small subset that knew how to exploit it until now. I suspect all of the coffee shops in the college town where I live will have people using this starting tomorrow.<p>I've personally been working from cafes and tunneling everything through SSH for years, but in my experience almost no one else does this.
This is one of many reasons Loopt has used SSL for all[1] traffic from the very beginning. At least WiFi has fairly limited range. Cell networks[2] (and satellite internet[3]) can be sniffed miles away.<p>In addition to making session hijacking harder, using SSL keeps crappy proxies from caching private data. Remember when some AT&T users were getting logged in as other users on Facebook's mobile site? The cause was a mis-configured caching proxy.<p>Raising awareness of issues like this gets them fixed. Until a service's users demand SSL, it won't be offered. Unless the service is Loopt :) It's not a noticeable computational burden, but it does increase latency and cost money (for certs).<p><pre><code> 1. Not images
2. Older GSM crypto can be hacked in real time with rainbow tables now
3. Usually not encrypted at all</code></pre>
<i>Nice</i>. A solid demonstration to show next time your webmaster doesn't want to set up SSL everywhere.<p>That said, the current cartel-like setup of certificate authorities (protection money and everything!) makes SSL annoying and expensive if you want the browser to not have a fit. Especially for small-scale projects. But there's really no excuse for larger sites.
Thanks for posting this. It convinced me to upgrade SSL support from "something that would be nice to implement if I was bored someday" (BCC is not exactly security critical -- except, on reflection, the admin pages) to "drop everything and get it done."
I thought the title of this submission was slightly misleading. This is not a security vulnerability from within Firefox, it's a Firefox plugin to reveal security vulnerabilities in a wide range of websites.
Thanks to the EFF and the Tor Project we need not worry as much thanks to their HTTPS Everywhere project, a plugin for Firefox: <a href="http://www.eff.org/https-everywhere/" rel="nofollow">http://www.eff.org/https-everywhere/</a><p>Any questions:<p><a href="http://www.eff.org/https-everywhere/faq" rel="nofollow">http://www.eff.org/https-everywhere/faq</a>
The explanation I've always heard for not using HTTPS 100% of the time is that it puts an substantial load on the server, and for many sites it's overkill. Setting aside the subjective topic of "overkill" ... how much more CPU-intensive is it to serve pages over HTTPS compared to HTTP?
Is there another application besides the FF extension to dump the packets and process them? How does this work?<p>EDIT: Sorry, I asking specifically how this FF extension works.
Makes a strong case for everyone to start tunneling their traffic back to a trusted network.<p>I've been trying out sshutttle <<a href="http://github.com/apenwarr/sshuttle>" rel="nofollow">http://github.com/apenwarr/sshuttle></a>. It only tunnels TCP traffic, so you still have DNS and UDP traffic on the local network.
I think this should be a call to arms to network, web and system admins everywhere. This is a problem that everyone knows about but nobody wants to do anything about since it requires additional setup. Usually the barrier is a technical issue that the end user can't figure out. However since submitting forms via SSL is something the developer can do without impacting the end user at all, this is a simple fix for just about any website. You need a static IP and an SSL certificate, and they are both cheap.<p>Running out of IPv4 space is an issue in this regard, but hopefully with more people wanting SSL it will push providers to IPv6 quicker. Nicely done EricButler!
Title is a bit misleading. This is a front-end to libpcap, and can be used for hijacking any token-based-auth, not just HTTP.<p>It just happens that they released w/ support for social networks as a demonstration.
It seems fine to just enable SSL everywhere. But indulge me for a second in thinking of alternate solutions.<p>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 time to verify identity because an attacker won't have your cookie generator.<p>This javascript is really just an encryption key and algorithm, and if you implement it correctly, it should take quite some time for snoopers to reverse engineer the encryption key based on a sequence of one-time-use cookies.<p>Logistically, I suppose you would run into some trouble setting a new cookie for each request depending on how the page is loaded. For instance, if the user pastes a url into a new tab manually, then this system wouldn't have a chance to set the new cookie first.<p>However, I think you could architect a system that solves this. For instance, put the javascript token generator source in local storage. If a new page loads with an invalid key, that new page can just get the cookie generator code out of local storage and manually refresh the page's content by making a request with a valid token. This should be quick enough for most users not to notice, in the rare case that they circumvent the site's usual navigation.<p>A downside is obviously that the content itself is still not safe, but at least the account would be. Any thoughts?
You can slightly reduce the dangers stated here by logging out immediately after you are done doing whatever it is you are doing. This will make the captured session useless.<p>The best solution is of course to get a VPN acct and use it when you are at free/open wifi spots. I use WiTopia (www.witopia.net)
What can an end user do to minimize this?<p>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?
The main problem will be with SaaS apps that allow custom domains names (i.e. <i>mywebsite.com</i> instead of <i>mywebsite.mysaasprovider.com</i>).<p>I made an early decision to enable SSL everywhere in Trafficspaces with the obvious downside being that I need to allocate a dedicated IP address each time someone requests a custom domain name.<p>I used to get worried that perhaps it would have been better to <i>only</i> provide SSL in specific stages (such as sign-in and payment) and <i>only</i> through a generic domain name. Not any more.<p>Firesheep clearly vindicates that decision.
Why don't Facebook and other major sites check the user agent and IP address of client as well, instead of just relying on a cookie? That would solve this problem in 99% of the cases, right?
It states that it works for "open networks". What does that mean? All networks that you have access to? Including those in Cafes where they give you a key to log in? Or just networks that are completely open? And why does it work at all? I thought the wlan access point would encrypt the communication between itself and the computer. Would be interesting, which protocols are vulnurable to this and which are not.<p>I guess the logging of raw wlan packets is a one-liner under linux? Does anybody know it?
So wait... this works regardless of wireless card? I've tried to use BackTrack on my mac before and it failed due to the card not being able to run in passive mode.
It's an interesting assortment of sites that are "supported" out of the box. Some of them are pretty harmless (bit.ly, Flickr), some could cause some pretty serious hassles (Google, Amazon), and some could be absolutely devastating (Deleting someone's Slicehost account? Ouch...).
On my Macbook Pro (purchased 1 year ago) it doesn't seem to be able to capture traffic on my wifi. It can see sessions originating from another browser on the same Mac, but not other macs on the wifi network.<p>Is there a way of debugging what's going on?
I'm eagerly waiting trying this out once a Linux version becomes available.. looks very nice! Unfortunately I don't have a Windows or OS X installation available to me at the moment.
Here is a simple tutorial on how to set up an SSH Tunnel for Mac OS X <a href="http://bit.ly/cffjOY" rel="nofollow">http://bit.ly/cffjOY</a><p>This way all your communication is encrypted
On the other hand, stealing somebody's real life identity is not that hard either. But it does not happen too often, in part because it's illegal.
Stealing somebody's cookie on the Internet is a crime just as is stealing somebody's driver's license.
Although technical solution to this security hole is desirable, it's not the only solution available.
Linux installation needs work. README is empty, and the INSTALL says use ./configure which doesn't exist. ./autogen.sh complains about needing xulrunner-sdk path, which is isn't something normal for linux.<p>Edit: Oops! Linux support is "on the way." I guess I assumed since linux is the easiest platform to get your driver to go into monitor mode.
Interesting. I was going to do something similar but keep it limited to Facebook chat. That way you could eavesdrop on conversations in the room and impersonate people, etc. This is actually probably easy to program and more versatile at that.