Open an ssh connection to a server you have access to using something like the following:
ssh -ND 8887 -p 22 rufus@12.120.186.8
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
Set your network to point to the proxy. On a Mac that would be…
... Open Network Preferences…
... Click Advanced…
... Click Proxies…
... Check the SOCKS Proxy box then in the SOCKS Proxy Server field enter localhost and the port you used (8887)
... OK and Apply and you are done!
Now you can surf safely.
That link has screenshots to help you configure Firefox to use the ssh proxy.
ssh -ND 8887 -p 22 rufus@12.120.186.8
ssh -vND 8887 -p 22 rufus@12.120.186.8
I am using the Tomato firmware (http://www.polarcloud.com/tomato) which has an SSH daemon.
alias socks="ssh -ND 8887 -p 22 rufus@12.120.186.8"
That way I can just open a shell and type "socks" and be good to go (well and then do the system preferences deal, but I have an AppleScript that does that automatically).
SSH_Server -> FaceBook == Unencrypted
SSH proxies are not end to end encryption. They only protect part of the path. Not sure why this is being down voted. It's true. The tunnel is only between the client and the SSH server. The HTTP websites that you visit beyond the SSH server see your clear text packets.
Tunneling over SSH protects your traffic for that portion of the network (and out past your ISP as far as the remote end of the SSH tunnel).
An attacker would need different tools and resources to intercept your traffic between remote hosts.
The network from the SSH_Server to Facebook and much larger and more secure.
Silence Is Defeat provides SSH accounts for a small donation.
(I am not affiliated with them)
I'm going traveling for all of next month, the only sites I'll be checking where I'll be logged in is my hotmail account, and I might check my bank account (Chase) - both use https, so I suppose I'm in the clear then? (also when I click "log out" on these sites, it logs me out, but if my session has been hijacked, will it log the hijacker out of the session he's hijacked of mine as well?)
The Pandaboard[1] looks like a good fit, but the instructions to install a Linux distro are a bit scary [2]. I guess I could do it, from my Mac, but I'm a bit afraid to mess things up with the low-level disk utilities.
Does someones sells SD cards with a distro pre-installed? Or an equivalent device with an easier setup?
If not, there's probably a market for that...
[2] http://omappedia.org/wiki/OMAP_Pandroid_Main#Getting_Started
[1] http://www.amazon.com/Cisco-Linksys-WRT160N-RM-Refurbished-W...
If you can't afford that, you can always run a SSH server from your residence and use that.
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?
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 criminal. 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 always 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.
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 his level of security. Congratulations to the new Jason Fortuny.
When a tool like this rises to even a minimum level of public consciousness, you're better off thinking "people have probably been doing this for close to a decade" than "this asshole just ruined the internet by pointing out an obvious flaw that someone will now be able to exploit".
And yes, at some point, a door manufacturer that knows how easily their doors will open and how frequently people will just walk through does take on some responsibility to add a lock (and the homeowner to use it). It's going to cost more in servers? Okay, so what? It costs more to install seatbelts, are you upset at Ralph Nader, too?
[Edited to bring it down a notch]
Flat out false. Ever heard the term "crime of opportunity"?
What's your over/under on the number of identity thefts facilitated by Eric Butler's little gift? Let's make this empirical.
I hate this mythical "good old days" B.S. I know people who live in the country who don't lock their doors because they live in the country. The idea that people who lived in urban areas ever could leave their doors unlocked is absurd.
Our garage leads to my office, which in turn leads to the rest of the house.
We came home shocked to see it open, and even more shocked that not a single thing was missing.
Yes, but it's better than the alternative, where there would be an increasing number of people negatively affected for even longer. At least the problem is out in the open now and there will be public pressure to fix it.
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 criminal.
You are correct. But those days are long gone, and they're not coming back. Unless you want to throw out a good chunk of technology, kill half the people on the planet and go back living in communities where you knew personally everybody you interacted with during your entire lifetime.
Butler has simply raised the threat level for everyone.
Yes, he has. But he has also raised the defense-level for everyone, and by a greater margin. Before his post, there was a much larger divide between the people who knew about this exploit and those who didn't (the fox and the sheep, if you will). It's true that now more people can exploit those who don't know, but it's also true that even more people can defend against it.
He did not invent a new lock or close a hole.
Making other people aware of the hole is the first step in getting it closed, if you are unable to do it yourself. Shame on the rest of us for not doing this earlier.
This isn't a new threat. Just a new shiny piece of ware that lowers the bar a little further.
The main thing holding us back there are browsers that go apeshit if you load images via HTTP on an HTTPS page. Requiring JavaScript or other active content to be loaded from the same HTTPS server would be a good thing in many cases. I think currently ANY https server is allowed, which doesn't actually defend against any kind of XSS, so it's pretty meh. Or is there some kind of meta tag etc. that enforces same-origin? (If not, that would be a cool addition. Maybe a list of allowed domains?)
The analogy is not complete because in our situation there's a third party involved beside the victim and the criminal: the website. What if your bank leaves the vault unlocked so anyone can take your money? Isn't the bank at least partly to blame?
by now it is clear that unauthorized access to social networks can cause much distress and even worse to a great many people who use them.
Banks minimize their liability when they use SSL, facebook should do this too. at this point it should be clear that the effect on a person social life can be severe, career destroying, financially damaging, what have you, we are witnessing stories along these lines in increasing rates.
The release of this extension is a blessing in my view, it forces the issue that companies like facebook or twitter would prefer to ignore, or cover in obscure terminology, this simply demonstrates how trivial this is.
When Ingersoll Rand released the Kryptonite lock, they named it after the mythical element that would bring superman to his knees. Too bad the lock was revealed to have a design flaw that enabled cracking it up with a BIC pen, was it shameful to display that defective design?
Facebook etc... talk about privacy all the time. This forces them to walk the walk, not just talk.
Butler isn't doing anything earth-shattering, he is just reminding everyone AGAIN that the current system is messed up.
There will always be this debate about disclosure, but you can't ignore that it works. Sure, innocents suffer (and they would[they are!] anyway), but at least it's one more reason why websites should change to https.
What actually happened back in the day before people started forcing the issue with full disclosure was that the bad guys operated with impunity because the good guys couldn't work together because people got upset when folks let the "secret" vulnerability knowledge out.
I don't want to go back to those days. Things have improved so much since then.
Concrete example: are you a location based startup? Well, you might need to shell out $10,000 for a Google Maps API Premier key in order to get HTTPS.
"Access to the API via a secure HTTPS connection" http://code.google.com/apis/maps/documentation/premier/guide...
"Google Maps API Premier is extremely cost-effective, starting at just $10,000 per year." http://www.google.com/enterprise/earthmaps/maps_features.htm...
Multiply that by thousands and you'll begin to have some idea of the discussions going on at every web based company with a clue today.
For those who make their living in computer security, like Mr. Butler, of course it's a good day (and month, and year). Pretty good business when you can start fires and then get paid well to put them out. Serves them right, of course, because they shouldn't have built that house out of wood in the first place.
While we're on the topic, I don't understand how a lot of people fail to realize that spending on computer security is a lot like spending on national security -- you can always spend more money on it, thereby taking away resources from other priorities.
http://www.goodreads.com/author/quotes/23920.Dwight_D_Eisenh...
"Every gun that is made, every warship launched, every rocket fired signifies in the final sense, a theft from those who hunger and are not fed, those who are cold and are not clothed. This world in arms is not spending money alone. It is spending the sweat of its laborers, the genius of its scientists, the hopes of its children. This is not a way of life at all in any true sense. Under the clouds of war, it is humanity hanging on a cross of iron."
-- Eisenhower
Wrong. You don't need to use https for everything -- you can specify a domain and a path in the cookie. For things like images, videos and css, you still don't need SSL.
I've personally been working from cafes and tunneling everything through SSH for years, but in my experience almost no one else does this.
I can't think of a more effective way for him to convince them all to update now.
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 totally wrong - correct me ;-))
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.
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).
1. Not images
2. Older GSM crypto can be hacked in real time with rainbow tables now
3. Usually not encrypted at all[1] http://www.radiolabs.com/products/antennas/2.4gig/long-range...
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.
Works — of course — everywhere except IE6/7XP.
An alternative is to bind the user's session to their IP address, but that isn't fool proof either because of NAT, DHCP and certain big ISPs that tend to change IPs on the fly.
What cost-effective solution would you suggest?
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.
Looks like a great idea, but how do they prevent the man-in-the-middle from impersonating a network notary?
Ouch. I think it's time to set up that VPN I've been putting off...
It almost makes me angry that websites like Facebook and Twitter don't force all traffic over https. They've got the money and the expertise. They just don't care if your account gets sniffed and taken over at a web cafe.
amazon basecamp bitly cisco cnet dropbox enom evernote facebook flickr foursquare github google gowalla hackernews harvest live nytimes pivotal sandiego_toorcon slicemanager tumblr twitter wordpress yahoo yelp
Any questions:
HTTPS Everywhere is good but only works on known sites (and known domains for those sites).
And Tor, there's lots of cases where operators did bad things. Don't trust it for sensitive information. http://blog.ironkey.com/?p=201
Thanks to reading Techcrunch this morning, I read about this plugin which allows you to manually define which sites you want to force an HTTPS connection on:
Force-TLS https://addons.mozilla.org/en-US/firefox/addon/12714/
Mind you for any of these extensions to work the website you're visiting needs to be already accessible via ssl. If the site does not have encryption, these plugins can't force the sites to automagically start using the encryption it never had.
Quoting from that, "On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead."
You can amortise the session setup cost by ensuring the HTTPS session caching is enabled on your server (in Apache, the directive is SSLSessionCache). This will let subsequent connections from the same client re-use the same SSL session.
There are ways to work around this, if the non-https site immediately redirects to the https version and a "secure cookie" (https-only) is exchanged afterwards.
EDIT: Sorry, I asking specifically how this FF extension works.
I've been trying out sshutttle <http://github.com/apenwarr/sshuttle>. It only tunnels TCP traffic, so you still have DNS and UDP traffic on the local network.
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!
It just happens that they released w/ support for social networks as a demonstration.
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.
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.
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.
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.
A downside is obviously that the content itself is still not safe, but at least the account would be. Any thoughts?
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.
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)
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.
People should also be aware of the security implications of installing various software on their system. :)
It's very possible, given that the extension seemingly captures HTTP requests/responses. If passwords are sent or received in plaintext, then they can be captured.
Maybe someone who has developed a FF extension can lay my worries to rest -- could this have, say, a built in key logger which sends that data to the author?
I downloaded the source code from github and glanced through it, enough to comfort me somewhat, but I wasn't super thorough.
All that said, EricButler seems to be an HN member in good standing, and someone like that wouldn't do anything malicious, right? :-)
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?
Yes, if you login and your cookie is sniffed and spoofed then basically you just allowed the attacker to login as you at the same time.
Minimizing it is a little bit different: you can use a secure proxy/tunnel, you can limit your unencrypted wireless activity, you can make sure that sites that should be SSL encrypted are (stripping SSL is common when password sniffing) and you can avoid these services while on open wifi networks.
So remember to logout.
VPN is really the best overall option.
On reporting it, the response was essentially, "oh you didn't have to go to that much trouble, you could have just used your user/pass from curl…" Completely obvious to the fact that they're app/site was completely vulnerable to session hijacking.
One of the problems of app frameworks, if you don't know what they're doing (and more importantly, not doing) you can get yourself in a heap of trouble before you even realize there's an issue. But boy, you sure can make it to market fast. shakes head
Logging out doesn't kill the session.
It will, however, stop unauthorised computers from sniffing any network data.
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.
I used to get worried that perhaps it would have been better to only provide SSL in specific stages (such as sign-in and payment) and only through a generic domain name. Not any more.
Firesheep clearly vindicates that decision.
I was referring to cases where the account holder wants to use an custom domain name e.g. ads.mywebsite.com, instead of the generic mywebsite.mysaasprovider.com.
In that case, we'll need to host their certificate within our Pound load balancer and get it to listen on a dedicated IP.
I guess the logging of raw wlan packets is a one-liner under linux? Does anybody know it?
Once I upgraded to 3.6.10 worked awesome.
Firefox 3.6.11 OS X 10.6 firesheep-0.1-1.xpi
Digest authentication is safe against passive sniffing (it doesn't exchange any password/token in the clear and uses nonces), but it doesn't protect against active attacker who could modify server headers and replace "Digest" with "Basic" to reveal password.
Is there a way of debugging what's going on?
http://www.php.net/manual/en/function.session-regenerate-id....
This way all your communication is encrypted
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?
I'm going to be traveling for a while pretty soon and using a lot of internet cafes and other free wi-fi spots so I should probably get this set up - I'm worried someone will be able to grab my password while logging in to check mail.
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.
I shall call this experiment a success.