Sophos Cloud Optix
Firesheep has already taught 750,000 people how to hijack your unencrypted WiFi sessions with a single click.
So here’s how to extinguish Firesheep with a technological defence that you can put together in just 60 seconds, even when you’re on the road, and even if you’re connecting over unencrypted WiFi to start with.
Once you’re done, you can browse over unencrypted WiFi access points with no more risk than you’d browse at home.
This is a solution worthy of 1980s American pacifist technohero Angus MacGyver himself. (But no need for a mullet. Honestly.)
Watch and enjoy:
(Enjoy this video? You can check out more on the SophosLabs YouTube channel and subscribe if you like)
nice one
how about win users?
Windows clients? Or Windows servers?
There are various SSH server choices for Windows, paid and free. A later commenter has mentioned freesshd, which AFAIK is closed-source freeware based on code from weonlydo.com, who offer commercial SSH products, including source, for Windows.
I haven't used either of these, so I can't offer any recommendations.
There are also various ports of OpenSSH, but the ones I've seen are not true Windows ports. Instrad, they are ports to Cygwin, which is a Unix-to-Windows API layer which you run on Windows to make Unixy code easier to port. As the Cygwin guys say, "there is no guarantee that Cygwin is as secure as the Windows it runs on."
As for Windows clients, I recommend PuTTY in the video, simply because I have used it for years. The program PUTTY.EXE replaces ssh, and PSCP replaces scp.
What's with the trend toward doing stuff like this as videos? I hate video presentations with a purple passion. Post it as words with screen shots and I'll look at it.
It's 2:30 in the morning and I don't want to wake up the household playing a video. And I don't want to have to put on headphones.
OK, got that off my chest. Back to bed.
Hmmm. That makes me feel _great_! All that work (several minutes of creative effort!) on a trip down MacGyver Memory Lane (BTW that's Audacity's wahwah pedal effect at the end of the soundtrack remixy bit) with my MacGyver sight gag, all wasted because you don't like headphones 🙂
Actually, why not try watching the video with the sound off? I think you'll find that the documentation you need is all there – the video is, for the most part, screen shots with words documenting the downloads and commands you need to use.
Watching or skipping through 4 minutes of video to gain a concept that probably only requires a quick glance of a couple of lines to get the idea is overkill.
Invest in a cheap pair of headphones.
I agree that your average news source should shut up and provide an article, as that's one of my great pet peeves. I can skim much faster than someone can talk.
But the best part of Duck's videos _is_ the audio. If it talks like a Duck, it's worth a listen. 😉
Agreed – I like to read/scan at my speed, not whatever speed the guy making a video likes, and you can't scan a video.
That's nice… For someone who only heard about Linux/SSH yesterday… A much much easier and more flexible solution is to use the -D option of OpenSSH (the server that is installed on 99% of machines) to activate the builtin SOCKS server:
ssh -D 8000 your.srv.
And for windows user, I recommend FreeSSHd, it should achieve the same goal.
Ah. Yep. I just checked and found out for myself (should have known this!) that dropbear sshd supports SOCKS redirection, too. So this approach can even be used with an xWRT Linux distro on your favourite router…nice.
I am still rather partial to the TinyHTTPProxy.py solution, though. I am fond of the terminal window which logs the HTTP requests for you. (And the Python code is easy to tweak if you want to use the code for logging which websites carry what third-party download penalties.)
Interesting to see which sites suck in what content from whose external servers 🙂
What I don't quite understand is what makes Firesheep specific to Wifi connections? Everywhere I see discussion of it, it's always in connection with open Wifi. But looking at the creator's blog, it doesn't seem like it's specific to that at all?
Firesheep _isn't_ specific to WiFi. You could use it on a corporate LAN, though I hope that the sysadmin would catch you out and, ahhh, "take action" 🙂
(To back myself slightly here, in the video I deliberately said Firesheep "grabs unencrypted authentication cookies off the ether as people around you surf".)
The ultimate issue is the lack of end-to-end HTTPS for web sessions in which thereis personal information, rather than the medium over which those unencrypted sessions are transmitted. So the article's title might indeed have been better, if less punchily, written as "Extinguishing Firesheep for safer browsing on utterly wide-open networks."
Of course, unencrypted WiFi access points are one of the riskiest places for getting sniffed and subverted, so if you are worried about unencrypted HTTP, then open WiFi networks are the places to worry the most (or to avoid altogether without suitable safeguards).
My HTTP proxy solution (or the SOCKS one given by Rincewind above) does not remove the risk. But it does shift it to a part of the network you probably trust a lot more – I alluded to this in the video by saying no more that that using SSH to move the unencrypted traffic to another part of the internet makes surfing on dodgy WiFi networks "as safe as if you were surfing at home".
So, indeed, YMMV. But open WiFi spots are definitely risky, and three quarters of a million Firesheep downloads haven't made them any safer 🙁
Nice one – can use it on anything really.
Interested to know how Opera's mobile service affects the firesheep data gathering beastie since it it effectively proxying everything through the opera servers.
Anyway, more use than the "detect Firesheep" type add-ons 🙂
I'm not so sure about the safety of this as it runs an open proxy on your linux server. Anyone on the internet may set their browser to use http://shell.example.org:8000/ as proxy and request whatever they like over your internet connection.
It is only an open proxy _if port 8000 is open to your server from outside your network_, which it shouldn't be.
Perhaps I should have clarified this.
But my assumption is that your server – being an SSH shell server – has SSH open, but _not_ any other ports. In other words, you have to be able to connect inwards via SSH in the first place to do the redirection. (That also means you can only make a connection to the proxy over a secure tunnel, so the proxy traffic is always encrypted.)
You'll note I redirected localhost:8000 (i.e. localhost on the airport laptop) to localhost:8000 on the server (i.e. localhost on the shell server). That was to limit the redirector. I ought also, for correctness, to have run the TinyHTTPProxy.py on the localhost interface _only_. I now recall I did not do so (the video shows it listening on 0.0.0.0, or 'all interfaces').
But a properly configured shell server – only SSH traffic allowed inbound, with decent password, public key, or OTP login security in place – doesn't become an open relay in this way. You have to get in via SSH first to connect to the proxy on port 8000 and thus to get back out.
Thanks for the clarification. Yes, port 8000 was open on my server to the machine I was testing it from.
Why do you need a proxy!?
Just use `ssh -D 1080 host.example.com`
Been doing it for years. Easy. Although this will only protect web browsing. Anyone using IM/Chat can still have details stolen.
If you do run a (SSH) server at home then better to install OpenVPN and encrypt everything 🙂
I don't disagree. Moving _all_ your traffic over an encrypted tunnel from a less trusted internet connection to a more trusted one is, indeed, comforting. It also makes it rather easy, with a single firewall rule, to prevent anything getting onto the less trusted network unless it's encrypted.
One mild advantage of the "HTTP only" approach – provided you remember that's all it is – is that for travellers from some parts of the world (Oz being an example), your home server may frequently end up quite some distance away from your road PC, in both space and time. Also, some connection plans charge for data by volume, and using an encrypted tunnel hits your home connection twofold.
Pushing _all_ your traffic through a VPN can therefore be slow and expensive. So you might be willing to let, say, your OS security updates come through unencrypted (since it's authentication which is most important in this case, not confidentiality), whilst tunneling only your unencrypted web traffic.
But If you can afford to – you're right, encrypt the lot. And put some pressure on Facebook et al. to do the same.
You never commented on the fact that the tinyhttpproxy is redundant…
That was suggested above – I replied there.
Also, don't forget that SOCKS just proxies TCP connections, whilst an HTTP proxy "outsources" the whole HTPP request-and-reply process, including the DNS lookups used.
If you use SOCKS for HTTP security, your DNS requests can still be manipulated (and sniffed) at the insecure end. So if you do use SOCKS (5, but not 4) then don't forget to use its "delegate DNS to the other end" option – however, IIRC in Firefox you need to use "about:config" to turn that setting on and off.
So whilst the solutions are very similar, they aren't truly identical, and neither subsumes the other.
You do know this concept has been used in the windows world to bypass corporate firewall content filters for at least 10 years. It’s funny how Linux power users always think they are so clever when they invent a solution to something, rather than look beyond their own forums to discover someone on another OS already solved their problem a decade ago. Sorry all you Linux users had to wait for this… I’ve been doing it on Windows for years.
Not sure that there's an "invention" here, expressed or implied. And amusing to see you focusing on Windows versus Linux. (The SSH code used in the video comes from the OpenBSD crew, and first saw release in 1999, whilst the HTTP proxy was written for BeOS in 2001.)
Please don't use this sort of technique to bypass corporate firewalls, inbound or outbound. Either argue your case and get the rules changed, if you can't do your job because of IT policy, or find another job, if you genuinely can't do your job and IT won't adapt to let you do so.
There was a postscript at the end of the video pointing windows users to try Putty, which has ssh support built into
I really cannot understand why the press is pushing this Firesheep thing so strongly now. Firesheep actually uses a really old attacking technique – which became popular again since thanks to Wifi shared media is popular again. Like it was years agao when ethernet switches were far too expensive and simple ethernet hubs were used instead. Or even before when 10Base2 was popular.
I wonder why nowadays websites don't check the session cookie's originator's IP address (anymore). It's so simple – the webserver just has to check if the session cookie was sent from the IP adress the SSL encrypted logon was done some minutes before. if it was, everything is OK – if it wasn't, someone stole the cookie and now tries to access another's account. Of course the attacker could also take over the victim's IP-address if he is on the same network segment (or same WiFi network), but the victim at least would notice that.
There isn't anything novel about Firesheep – except, of course, that it proudly gives single-click hijacking capability to anyone who wants it. And that's three quarters of a million "researchers" so far, and counting. Ergo, it is newsworthy, and therefore it has achieved one of its stated goals – to highlight the lack of HTTPS on many mainstream websites which ought to be offering it.
Sure, there are all sorts of tricks a web server can use to make cookies harder to reuse. You can tie them to IP number – except that on many WiFi networks, everyone has the same IP number as far as the remote server is concerned, thanks to NAT at the WiFi-to-fixed-line gateway. And you can update each user's cookie every time a new page is requested – but that just shortens each cookie's lifespan. It doesn't make them unsniffable.
The cookie is a session access token, so it ought to be encrypted all the time. And that access token is almost always there specifically to "protect" access to the personal data it authorises your browser to fetch. So that personal data ought to be encrypted all the time, too.
Do you not think that 'Blacksheep' is a satisfactory answer to the 'Firesheep' problem?
(The Firefox Add-on/Plug-in from Zscaler.com Labs).
Saves all that fuffing about with Proxy servers etc.
Nope.
Blacksheep simply "baits" Firesheep by making bogus account connections and watching to see if any Firesheep-like followup requests appear on the network, thus revealing that someone is running Firesheep (or that someone is running a bogus Firesheep designed to "bait" Blacksheep into thinking someone is using Firesheep, and so on, and so on 🙂
WiFi operators can use Blacksheep as a stopgap measure to detect and to do something about miscreants on their networks, such as throwing them off the LAN, at least temporarily. But as a measure for protecting every user's traffic on the network, it is approximately useless. Here is why:
1. It is only reactive. It runs every so often (by default every 5 minutes) and tells you someone has already been up to no good.
2. It relies on making bogus network requests itself. So it's at least mildly anti-social, especially if every user runs it all the time.
3. It warns you only if someone is up to no good with Firesheep. It doesn't warn against any other active sniffing tools.
4. It doesn't protect _your_ traffic at all. If you're worried about Firesheep on your current LAN, you should be worried about packet sniffing in general. Passive sniffing (listening and thus reading your personal data, without sending any packets) is undetectable and unpreventable by this tool.
Even a proxy server (whether my MacGyvery HTTP proxy solution in the video , or the abovementioned SOCKS proxy built into SSH), or a VPN, is only a partial solution – your personal data is still sent and received unencrypted _somewhere_, just not from the untrusted network you are on now.
You can't properly solve the problem of unencrypted personal data flying around in a broadcast medium with anything other than encryption.
Personally I am thankful for this video as it was very helpful; and to all those with rude comments to Ducklin; back-off. No-one said "you" had to watch the video let alone comment on it. If you don't like video's then why did you come here to watch it in the first place.
Its a bit long winded and technical for most every day users you will find in the likes of starbooks or Mcdonalds… Shame there isnt a simple solution.
Interesting Paul! What do you think about a solution like https-everywhere from EFF: https://www.eff.org/https-everywhere
Why not use it in addition, instead of, er, instead?
Your HTTPS traffic will then go locally over the otherwise-insecure LAN, and be encrypted (so you don't pay for that traffic at home where the proxy is located – in some parts of the world, a home proxy can impose both latency penalties and bandwidth costs, e.g. in Oz, where many plans have excess data charges and permanent uplink speed throttling).
But the HTTP traffic – including unencrypted content linked to from sites which do use HTTPS – is also encrypted, at least on the inescure LAN, thanks to SSH.
As the EFF itself notes, "HTTPS Everywhere can protect you only when you're using sites that support HTTPS and for which HTTPS Everywhere includes rules."
Well and good for the IT and technical savy user – but what about the rest of us that just want a quick fix without the big learning curve?
You could look for a third-party VPN (virtual private network) provider. A VPN works by grabbing _all_ the network traffic before it leaves your PC, encrypting it, sending it over a tunnel (the VPN part) to a remote server, decrypting it, and sending each packet on its way as if your PC were plugged directly into the remote server's network.
In other words, it's like the abovementioned HTTP proxy, except that it encrypts every network packet (if it's a proper VPN), rather than just encrypting the HTTP traffic at the HTTP application level.
You'll probably need some special software (or special configuration settings for built-in software if you are a UNIX/Linux user) from the VPN provider. You will definitely need to trust the VPN provider at least as much as you trust your current ISP, of course, since they get all your packets to decrypt (and bear in mind that the servers where they do the decryption may be outside your jurisdiction). And you may or may not need to pay a fee of some kind.
In short, you're paying (in some way) for someone else to host on your behalf the equivalent of the SSH server you saw me using in the video.
Would any proxy be a good defense for this?
The ideal solution would be for HTTP browsing to be encrypted from your computer to the server and back, for every transaction. (That's the end-game Firesheep is supposed to push us to.)
Second-best is to encrypt the HTTP traffic from your computer to an intermediate server, on a network you trust more, and to do the HTTP requests-and-replies from that more trusted server.
For the second approach you need some sort of proxy (as suggested above, HTTP, SOCKS or full-on VPN) and an encrypted tunnel to it.
There's no point in using a remote proxy which you access unencrypted, of course.
MacGyver's mullet is necessary as it is his trademark signature. He rocks it.
Glad technologically challenged peeps like me can just use https in facebook & now in twitter. No need to be like MacGyver anymore.
Using the ssh -D user@ip.of.home.system is probably a better way to go for a few reasons:
1) it's simpler
2) it's more secure, since you don't have a proxy server listening at home for anyone to use
3) you tear it down when you're done; it's only run when you need it.
As far as other applications (IM, chat, et al ) they can be configured to use this proxy as well. You define it the same way as in the proxy.