Agreed, but I still think giving someone else full control is a bit too much. It's not the user's fault (most don't even know this is happening) and they're likely to be the victims here.
The script kiddies already have their scripts and already do this. Firesheep will hopefully allow users to see the problem in a way they can clearly understand.
This vulnerability (it hurts to even call it such at this point) has been around for years, and the attack has always been easy for a determined attacker to carry out.
How else are we going to convince people to secure their sites and protect their users? People have been presenting on this issue for years (Ferret & Hamster, Blackhat 2007) and companies haven't responded/cared. It's possible to solve this problem (Gmail is all HTTPS, and done correctly, Amazon has a tiered authentication system that properly uses SSL for important things, Wordpress does SSL right for accessing their admin interface) - companies need to step up and address the issue.
Definitely, I guess as a uni student, I'm worried about the majority of non-technical students who are going to have their sessions hacked and have no clue what hit them and cannot setup proxies/tunnels.
I'm not saying this isn't the site's fault. They definitely need a wake-up call.
This was already happening on a massive scale before this new app was released... I honestly don't think it will increase the number of attacks by all that much. It's brilliant as a tool for spreading the word though.
It was happening on a massive scale, but now a huge amount of really lazy people who didn't bother to do this before are. It had 3,000 downloads after 2 hours of release. The thing is, most universities have protection set up. It seems Cisco NAC is actually good for something. I never thought I'd say that. The extension certainly doesn't work on my campus.
It should be noted that Wordpress implements SSL for wordpress.com correctly, but any self-hosted blogs from wordpress.org need to be individually configured.
This is essentially the same argument that comes up with full disclosure. Yes, it's not pretty. Yes, it causes a lot of collateral damage. But it also makes the big players patch things up faster, while letting the knowledge out to the public, which of course consists of not only the script kiddies, but also the unsuspecting legitimate users.
Even the dumbest script kiddies have been doing this for years anyway. There are plenty of existing tools. This one just lowers the bar so your mum can perform the attack too.
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.
Exactly. I'm not a blackhat and my only "hacking" consists of forcing myself into my own systems which I've stupidly locked myself out of, yet I've managed to do much that this plugin can do.
The most un-ethical thing I have done was to take one of the OLPC XO laptops and convert it into a MITM machine, rebroadcasting the SSID it connects to while routing and logging all traffic anyone who connects to it generates. It took a weekend to setup using pre-existing tools and scripts and can be deployed anywhere I want within 2 minutes and run for up to 6 hours hidden in the bottom of my backpack. It was a fun experiment, and surely made me more aware of just how vulnerable I was outside of my home network.
Another point of interest, this weekend I hacked on a Minecraft bot for the Alpha version. In order to understand and dissect the connection protocol I needed to recreate, I used wireshark to dump and parse how the client authenticates and connects to the server. Even that transmits your username and password in plaintext.
re: the OLPC, what were you running on it? I have one in my closet and I've been meaning to put something that isn't the stock software on there for a long time.
and it still asks me to run it with "--fix-permissions". I guess it's time to go digging around in the source to try and find out what it wants me to do.
EDIT:
After a bit of digging, I found out that running it with --fix-permissions really just chowns the binary to root then setuid's it. I don't see anything wrong with it on the surface, but I'll keep digging.
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.
Sorry if it was misleading somehow, this is definitely not a vulnerability in Firefox. It's a Firefox extension that makes it easy to execute HTTP session hijacking attacks.
What should happen if you use iPhone tethering? Could it top into the vast people on that network? (I have absolutely no idea). If this is the case, the internet will have a panic attack in 2 days max.
No. Cabled tethering to a cell phone only gives you access to your own packets. It's like a switched network where only packets addressed to you are sent to you.
On 802.11 wireless networks your wireless network card is capable of capturing traffic addressed to other computers. When encryption isn't used or is compromised, you can steal their credentials.
Doing something similar against cellular networks would require a much more sophisticated attack with specialized hardware that's largely illegal in the United States. I would also hope that cellular communications are encrypted these days.
Nice. A solid demonstration to show next time your webmaster doesn't want to set up SSL everywhere.
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.
You can get SSL certificates for free for one domain, and they work with all browsers (except Opera, IIRC). Also, you can use Perspectives for Firefox, which I think is much better than the current system.
Ah, I can't remember the name now... Rapidssl? That's probably it. Check historio.us, the ssl cert there is a free one (which is, sadly, why subdomains don't validate).
Wildcard certificates are available for USD $49.90 from StartSSL (http://www.startssl.com/?app=40), which is rather more expensive than free, but shouldn’t be a hardship.
The only downside to wildcard certs through StartSSL is that getting one requires high-resolution proof of personal identity, to be kept on file outside local jurisdiction (the company's based in Israel) until the cert's final renewal or revocation, plus seven years.
I admire their model of only charging for operations which require human intervention, like identity validation, but handing over that degree of documentation for that amount of time requires a lot of trust, not just of the company as it currently exists, but as it will exist in the far future.
If there was a way to validate organizations which wasn't layered on top of an earlier validation of an individual, or if their decentralized web-of-trust was usable for class 2/wildcard certs, I'd be a big fan.
As it is, there's no reason not to use Start for class 1, single-domain certs, for which the validation is automated and reasonable.
Wildcard certs don't match the underlying domain, though. See, for example, dropbox.com instead of www.dropbox.com; they've got a wildcard cert and it's not valid for dropbox.com.
There are levels of pay for functionality, like subdomains, and being able to issue your own certificates.
For instance, from Verisign: a 1 year Microsoft code signing certificate starts at $499 [1]. A top-of-the-line (from their main pages) web certificate for a single server for one year: $1499 [2]
Off topic, but re: Perspectives. It allows your browser to compare notes with other nodes on the Internet ('network notaries') to ensure that everyone is seeing the same cert for a given website.
Looks like a great idea, but how do they prevent the man-in-the-middle from impersonating a network notary?
SSL is bad for the environment because it requires far more server side hardware... Well, I'm only partially serious about the environment thing, the question is, how can internet companies make it commercially viable to use SSL for everything? The added hardware and power costs make each user way more expensive, possibly to the point where they may not actually be worth it.
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.
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.
People bring up the Google stat, but you have to remember they have incredible engineering resources so they probably optimize in many features every day without adding additional machines. That doesn't mean every dude with a LAMP stack out there can turn on SSL and expect the same performance, just that it's possible with mongo manpower and talent to make it work. (Google doesn't even release the details of their web stack so comparing their stat is apples and oranges.)
How many web servers do you know of which are CPU bound, and not through massive code stupidity, and not I/O (in some manner - waiting on SQL, disk access, bandwidth)? Encryption can run while other threads are waiting for a response.
In general, it's a negligible cost; it adds a very minor delay compared to latency / transfer time, and uses CPU otherwise highly unlikely to be pegged. If you're pushing threading limits / CPU usage limits, you're probably inches from needing new hardware anyway, and SSL should be considered part of the cost of running a web server.
It's not completely negligible--even if CPU usage is negligible, it does add latency during SSL negotiation that might be unpreferable for some apps. The testing burden is a lot higher because one wrong link to http:// in CSS, HTML, or AJAX will cause big scary messages. And there is the IP address problem, you can't vhost as most people with Apache like to do.
That may have been true 10 years ago, but the overhead of SSL for CPU is almost nothing, and only a few ms of latency. Web applications are mostly IO and memory bound, anyways. We should be using SSL all the time, by default. There's no reason not to, at this point, aside from certificate authorities.
Startcom offers free no-BS certificate signing, and their CA is on most modern browsers, I believe. I think they could be suitable for small scale projects.
HTTPS also needs distinct IP addresses for distinct hostnames, so that the HTTP handshake, in which the Host: header appears, is already protected by an encrypted channel. No more having multiple websites on one IP address.
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.
A guy I know used to do this in airports (just for fun, didn't do anything malicious) by grabbing webmail logins. Running wireshark with some simple filters and watch the cookies roll in.
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.
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.
Thanks to the EFF and the Tor Project we need not worry as much thanks to their HTTPS Everywhere project, a plugin for Firefox: http://www.eff.org/https-everywhere/
Logging into insecure sites over Tor is probably not a good idea. It's always good to assume that people running exit nodes are not the most trustworthy.
HTTPS Everywhere is good but only works on known sites (and known domains for those sites).
I realize I should of put more emphasis on "as much" as yes this only works on only a few popular websites as defined by the plugin.
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:
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.
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?
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?
Your terminology "the network" or "your network" is still unclear; encryption to the AP could be unique per wireless network client, or not. If it is unique per client -- and it is my belief that recent standards, like WPA2 at least, provide this -- then casual passive eavesdropping by other wireless clients (as with the FireSheep tool) is thwarted. (And that's what most people are most concerned about.)
Are you suggesting that no generation of WEP or WPA protects against other authorized wireless users of the same AP, because they're "on your network"?
WPA enterprise allows a separate (changing) key for each user, typically what you get from an RSA token. Once it gets to the AP, it's then clear text (assuming HTTP) over the rest of the internet until it hits your (HTTP) service provider.
If you have control over the internet between the AP and your server, then you're safe. If you don't, then how safe you are depends on how much you can trust the owner of each router along the way. In general, you should be okay, except that every now and then you might end up on an untrusted router, and it's then game over.
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.
That assumes the session is killed on logout. I know from first-hand experience that at least one version of Merb didn't do that. I hacked a pretty popular geo-socially site by grabbing the session cookie and playing around, then logging out. Was still able check-in after I had logged out and for good measure verified that my session was still valid after changing the password. I assume they were using the default sessions setup so I guess it expired. Didn't keep it around to see how long it stayed around.
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
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?
Are your neighbours on your private network? If not, you don't need to worry about them capturing your network data, because they're not on the same network.
Plus, your source IP can change from request to request when your ISP transparently pushes you through one of many proxy servers. AOL does (or did) this, as do some large European ISPs whose names escape me.
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?
The cpu load can be mitigated with frontend https accelerators or proxies (think nginx as a load balancer doing the https). The real problem is the first connection. Browsers don't fall back to https, if nothing answers on http they'll give an error. If the first connection is over http then a man in the middle attack can succeed.
> If the first connection is over http then a man in the middle attack can succeed.
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.
Someone correct me if I'm wrong, but that's the exact vector point for a man-in-the-middle attack. First request over HTTP gets hijacked, redirected to a "secure" server, then you (the user) see the lock and go to town, secure in the knowledge that you're communications with this server are protected because they're encrypted.
Isn't that exactly why HTTPS sites are supposed to have expensive certificates issued by big companies? Otherwise the browser will display a big red warning message. If you ignore that warning, you deserve to be hacked.
If the request gets redirected to a HTTPS proxy site that the attacker has set up, that's a different story. But again, you should be checking what's in your address bar. No security system can rescue you if you can't tell the difference between "mail.google.com" and "mail.google.haxxor.com". But for those of us who actually read what's in the address bar, HTTPS is pretty good security.
Isn't that exactly why HTTPS sites are supposed to have expensive certificates issued by big companies?
There is virtually no cost associated with issuing a certificate. The fact that they are nevertheless prohibitively expensive for most private domains is partly responsible for the failure to adopt SSL on a broad scale.
Otherwise the browser will display a big red warning message.
While it is true that this warning is intended to protect users again man-in-the-middle attacks and other methods that redirect traffic away from the original source, it also prevents people with absolutely valid (but free) certificates from offering perfectly good encryption on their sites. This warning is misguided and does more to prevent the secure use of the web than anything else.
The remedies would be simple, but I guess commercial reasons prevent them from being adopted at the expense of everyday users.
> it also prevents people with absolutely valid (but free) certificates from offering perfectly good encryption on their sites. This warning is misguided and does more to prevent the secure use of the web than anything else.
Accepting self-signed certificates would not be a good solution. Anybody can sign a certificate with "www.facebook.com" in the Common Name field. Your communication would be encrypted, but you'd be communicating with the wrong guy. SSL was designed to provide both encryption and identification. Self-signed certificates provide only encryption.
Besides, certificates are already quite cheap if you know where to buy them. RapidSSL costs as low as $12/yr, which is just slightly more than the cost of a domain name, and it's recognized by all browsers including IE6. I wouldn't consider it "prohibitively expensive" if it costs less than two lunches.
There are, of course, many other ways in which the existing infrastructure is inadequate. Take a look at the list of CAs that your browser automatically trusts. It's a mess. But it's not easy to implement an alternative that can provide both encryption and identification with the degree of reliability that the current infrastructure has. Some kind of social trust mechanism might work, but we're a long way from standardizing on anything of the sort.
The CPU intensive part of a HTTPS connection is the initial key negotiation/session setup (using asymmetric encryption methods). The symmetric encryption of the actual traffic is pretty trivial.
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.
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."
OK, that's most likely too late to contribute to the stated article, but there was a talk by Michael Klishsin about a year ago, here're his slides: http://bit.ly/90qORL
(ssl, performance, certificates, lots of stuff)
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.
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'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 totally wrong - correct me ;-))
It depends on how secure the remote network is. If it's just another coffee shop, you're screwed. If it's your own Linode in one of those well managed datacenters, it would be pretty difficult for anyone to snoop that traffic.
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 data center.
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 ;-)
Switching doesn't resolve the problem completely. There are a range of complicated attacks that could be done, but can be detected in various ways in a well run NOC.
I guess if you really wanted to you could run a GUI tool like Cain (http://oxid.it/), but most people doing this type of thing would use something like Scapy or at worst, Yersinia.
So I'd agree, more complex definitely, significantly not as much perhaps (it depends on the type of attack as tool), as for deliberation I'd say about the same as the firefox plugin.
If you do run tcpdump you do pick up broadcasts and such, one of our VPS instances actually sees a load of DNS traffic for our subnet, which we think is the other VPS instances.
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.
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)
However they don't share the same session cookie for different service as far as I know (which they negotiate that through TLS protected link)
Likewise they have also made several other services TLS only (e.g. calendar, docs)
Makes a strong case for everyone to start tunneling their traffic back to a trusted network.
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.
Passwords are not a part of this... It's the session cookie, which is an entirely different matter. It's unique to the login process, so one compromised account isn't able to lead to compromising other websites. It's also time sensitive (generally) and so that hijacked cookie will expire. If he were collecting all this information, he wouldn't be able to do much with it.
Just because the user interface only exposes cookies, doesn't mean that passwords aren't captured and sent somewhere.
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.
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.
Not sure why you're being downvoted, seems like a legitimate question to me! I was a little leery of checking it out at first, too, but curiosity got the better of me...
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? :-)
>> 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?
If it could sniff packets on network interfaces why couldn't it send data to a website? ;)
This kind of FF plugin requires extensive C++ coding. But even simple plugins that are only JS could easily send your username and password (if entered within them) to any web server.
355 comments
[ 0.19 ms ] story [ 242 ms ] threadOuch. I think it's time to set up that VPN I've been putting off...
How else are we going to convince people to secure their sites and protect their users? People have been presenting on this issue for years (Ferret & Hamster, Blackhat 2007) and companies haven't responded/cared. It's possible to solve this problem (Gmail is all HTTPS, and done correctly, Amazon has a tiered authentication system that properly uses SSL for important things, Wordpress does SSL right for accessing their admin interface) - companies need to step up and address the issue.
I'm not saying this isn't the site's fault. They definitely need a wake-up call.
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.
The most un-ethical thing I have done was to take one of the OLPC XO laptops and convert it into a MITM machine, rebroadcasting the SSID it connects to while routing and logging all traffic anyone who connects to it generates. It took a weekend to setup using pre-existing tools and scripts and can be deployed anywhere I want within 2 minutes and run for up to 6 hours hidden in the bottom of my backpack. It was a fun experiment, and surely made me more aware of just how vulnerable I was outside of my home network.
Another point of interest, this weekend I hacked on a Minecraft bot for the Alpha version. In order to understand and dissect the connection protocol I needed to recreate, I used wireshark to dump and parse how the client authenticates and connects to the server. Even that transmits your username and password in plaintext.
Run with which command? and how?
EDIT:
After a bit of digging, I found out that running it with --fix-permissions really just chowns the binary to root then setuid's it. I don't see anything wrong with it on the surface, but I'll keep digging.
Any ideas?
I have filevault turned on. Moving the binary out of my home folder (and adding a symbolic link) solved the problem.
And yes, WinPcap is installed. I don't think it should matter, but I'm running Windows XP on a VirtualBox.
On 802.11 wireless networks your wireless network card is capable of capturing traffic addressed to other computers. When encryption isn't used or is compromised, you can steal their credentials.
Doing something similar against cellular networks would require a much more sophisticated attack with specialized hardware that's largely illegal in the United States. I would also hope that cellular communications are encrypted these days.
EDIT: Sorry, I asking specifically how this FF extension works.
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.
EDIT: I searched and it's actually http://cert.startcom.org/.
AFAIK this is common to all certs (free or otherwise). You need a separate one for each subdomain (including www).
I admire their model of only charging for operations which require human intervention, like identity validation, but handing over that degree of documentation for that amount of time requires a lot of trust, not just of the company as it currently exists, but as it will exist in the far future.
If there was a way to validate organizations which wasn't layered on top of an earlier validation of an individual, or if their decentralized web-of-trust was usable for class 2/wildcard certs, I'd be a big fan.
As it is, there's no reason not to use Start for class 1, single-domain certs, for which the validation is automated and reasonable.
For instance, from Verisign: a 1 year Microsoft code signing certificate starts at $499 [1]. A top-of-the-line (from their main pages) web certificate for a single server for one year: $1499 [2]
[1]: https://securitycenter.verisign.com/celp/enroll/selectOption... [2]: https://ssl-certificate-center.verisign.com/process/retail/p...
edit: it would figure the links don't work. Just go to www.verisign.com and those are a couple clicks from the front page.
http://www.cs.cmu.edu/~perspectives/firefox.html
Looks like a great idea, but how do they prevent the man-in-the-middle from impersonating a network notary?
http://web.monkeysphere.info/
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?
It's gotta be SSL all the time.
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.
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/
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
In general, it's a negligible cost; it adds a very minor delay compared to latency / transfer time, and uses CPU otherwise highly unlikely to be pegged. If you're pushing threading limits / CPU usage limits, you're probably inches from needing new hardware anyway, and SSL should be considered part of the cost of running a web server.
Works — of course — everywhere except IE6/7XP.
Firefox 3.6.11 OS X 10.6 firesheep-0.1-1.xpi
$ 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.
I have filevault turned on. Moving the binary out of my home folder (and adding a symbolic link) solved the problem.
Any questions:
http://www.eff.org/https-everywhere/faq
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.
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?
It will, however, stop unauthorised computers from sniffing any network data.
Are you sure that neither WEP nor WPA/WPA2 do it this way?
Are you suggesting that no generation of WEP or WPA protects against other authorized wireless users of the same AP, because they're "on your network"?
[rewritten completely to seek clarification]
If you have control over the internet between the AP and your server, then you're safe. If you don't, then how safe you are depends on how much you can trust the owner of each router along the way. In general, you should be okay, except that every now and then you might end up on an untrusted router, and it's then game over.
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
http://codebutler.github.com/firesheep/tc12/#18
Logging out doesn't kill the 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.
If the request gets redirected to a HTTPS proxy site that the attacker has set up, that's a different story. But again, you should be checking what's in your address bar. No security system can rescue you if you can't tell the difference between "mail.google.com" and "mail.google.haxxor.com". But for those of us who actually read what's in the address bar, HTTPS is pretty good security.
There is virtually no cost associated with issuing a certificate. The fact that they are nevertheless prohibitively expensive for most private domains is partly responsible for the failure to adopt SSL on a broad scale.
Otherwise the browser will display a big red warning message.
While it is true that this warning is intended to protect users again man-in-the-middle attacks and other methods that redirect traffic away from the original source, it also prevents people with absolutely valid (but free) certificates from offering perfectly good encryption on their sites. This warning is misguided and does more to prevent the secure use of the web than anything else.
The remedies would be simple, but I guess commercial reasons prevent them from being adopted at the expense of everyday users.
Accepting self-signed certificates would not be a good solution. Anybody can sign a certificate with "www.facebook.com" in the Common Name field. Your communication would be encrypted, but you'd be communicating with the wrong guy. SSL was designed to provide both encryption and identification. Self-signed certificates provide only encryption.
Besides, certificates are already quite cheap if you know where to buy them. RapidSSL costs as low as $12/yr, which is just slightly more than the cost of a domain name, and it's recognized by all browsers including IE6. I wouldn't consider it "prohibitively expensive" if it costs less than two lunches.
There are, of course, many other ways in which the existing infrastructure is inadequate. Take a look at the list of CAs that your browser automatically trusts. It's a mess. But it's not easy to implement an alternative that can provide both encryption and identification with the degree of reliability that the current infrastructure has. Some kind of social trust mechanism might work, but we're a long way from standardizing on anything of the sort.
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.
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."
I've personally been working from cafes and tunneling everything through SSH for years, but in my experience almost no one else does this.
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 ;-))
So I'd agree, more complex definitely, significantly not as much perhaps (it depends on the type of attack as tool), as for deliberation I'd say about the same as the firefox plugin.
If you do run tcpdump you do pick up broadcasts and such, one of our VPS instances actually sees a load of DNS traffic for our subnet, which we think is the other VPS instances.
I can't think of a more effective way for him to convince them all to update now.
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)
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.
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.
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. :)
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? :-)
If it could sniff packets on network interfaces why couldn't it send data to a website? ;)
This kind of FF plugin requires extensive C++ coding. But even simple plugins that are only JS could easily send your username and password (if entered within them) to any web server.
Once I upgraded to 3.6.10 worked awesome.