Firesheep as applied to Cambridge
Many of you will have already heard about Firesheep which is essentially a Firefox extension which allows you to login to other people’s Facebook, Amazon etc. accounts if they are on the same (unsecured) network to you. This post is on my initial thoughts on what this means to the people on Cambridge University networks.
Essentially this whole thing is nothing new – in one sense people who know anything about security already knew that this was possible and that programs for doing this existed. The only innovation is an easy to use User Interface and because Human Computer Interaction (HCI) is hard, this means that Eric Butler has won.
In Cambridge we have unsecured wireless networks such as Lapwing and the CLs shared key networks and I think that Firesheep should work fine on these and so for example in lectures where lots of students are checking Facebook et al. (especially in the CL) there is great potential for “pwned with Firesheep” becoming the status of many people. However this would be morally wrong and violate the Terms of Service of the CUDN/JANET etc. If that isn’t sufficient – the UCS has magic scripts that watch network traffic, they know where you live and if you do something really bad they can probably stop you graduating. So while amusing I don’t think that a sudden epidemic of breaking into people’s accounts would be sensible.
So what does that mean for the users of Cambridge networks? Use Eduroam. Eduroam is wonderful and actually provides security in this case (at least as long as you trust the UCS, but we have to do that anyway). If you are using Lapwing and you use a site listed on the handlers page for firesheep (though don’t visit that link on an unsecured network as GitHub is on that list) then you have to accept the risk that someone may steal your cookies and pretend to be you.
What does this mean for people running websites for Cambridge people? Use SSL, if you are using the SRCF then you win as we provide free SSL and it is simply a matter of using a .htaccess file to turn it on. It should also be pointed out that if you are using Raven for authentication (which you should be) then you still need to use SSL for all the pages which you are authenticated on or you lose[0]. If you are not using the SRCF – then why not? The SRCF is wonderful![1] . If you are within *.cam.ac.uk and not using the SRCF then you can also obtain free SSL certificates from the UCS (though I doubt anyone likely to read this is).
So do I fail on this count? Yes I think I have multiple websites on the SRCF which don’t use SSL everywhere they should and I don’t think any uses secure cookies. I also feel slightly responsible for another website which both uses poorly designed cookies and no SSL.
Users – know the risks. Developers – someone is telling us to wake up again, and even though I knew I was sleeping.
[0]: Unfortunately I think that until the SRCF rolls out per user and society subdomains which will be happening RSN if you use raven to login to one site on the SRCF and then visit any non-SSL page on the SRCF then your Raven cookie for the SRCF has just leaked to anyone listening. Oops. Using secure cookies would fix this though I haven’t worked out how to do this yet – I will post a HOWTO later Update: if the original authentication is done to an SSL protected site then the Raven cookie will be set to be secure.
[1]: I may be wearing my SRCF Chairman hat while writing that – though that doesn’t mean it isn’t true.
Tags: code, firefox extension, firesheep, unsecured network, wireless
October 26th, 2010 at 15:52
Quick work! I only read about Firesheep a little before you posted. SSL on the SRCF probably has its own rhyme and reason, but it was a bit of a fiddle the last time I had to manage it (for the Petball site). Secure cookies as I remember it are a bit of a weak fix; they don’t add any extra layer of control to where the cookie is allowed to be sent, but just make sure that if it went out over SSL and the secure bit is sent, the browser ought never to send the cookie out not in SSL. So, if setting the secure cookie bit would prevent another SRCF from reading your cookie, all they would have to do would be to move to SSL themselves and they could get the cookie back. If Raven cookies are readable by other sites (not checked yet—really ought to know this already…) then the problem will be in the path and domain restriction, not the secure bit. The question of mis-sending cookies is separate to the problem of sniffing them over HTTP. Pinch of salt; memories going back a few years here.
October 26th, 2010 at 16:18
So the problem that setting the secure bit on the cookies solves is that it prevents local users sniffing your raven cookie. As you rightly point out this doesn’t help in the case that there is an attacker on the SRCF who can make you visit their site – but that is a rather hard case to deal with. What I do for this blog and what happens for phpmyadmin etc on the SRCF is that they first require authentication to Raven and then to the individual service and so even if an attacker on the SRCF (and we always assume we have an attacker on the SRCF because we have lots of broken php etc. running) gets you to visit them then they still can’t gain access to your databases etc.
October 26th, 2010 at 16:36
The reason that SSL was a faff for the Peterhouse May Ball website was that the Peterhouse May Ball had its own domain. It is possible that these days the SRCF could issue an SSL certificate for the Peterhouse May Ball domain though… ;-)
October 26th, 2010 at 16:49
Great post!
January 19th, 2011 at 22:23
(Late reply after seeing this on Google while setting up Apache for another SRCF site).
For the record: SRCF will always require SSL to be for the srcf domain. Each SSL certificate requires a unique IP. The SRCF will not buy an IP address for each society that wants to run SSL on its own domain. The trick is to the use the main domain as much as possible, with some clever jumping in and out of frames to force SSL for the bits that are cookie-dependent.
January 19th, 2011 at 22:47
IPv6 and possibly SNI ‘solve’ the problem of needing to buy additional IP addresses though they do of course come with their own problems.