4

What are the sysadmin's thoughts on mitigating the 'firesheep' attack for servers they manage?

Firesheep is a new firefox extension that allows anyone who installs it to sidejack session it can discover. It does it's discovery by sniffing packets on the network and looking for session cookies from known sites. It is relatively easy to write plugins for the extension to listen for cookies from additional sites.

From a systems/network perspective, we've discussed the possibility of encrypting the whole site, but this introduces additional load on servers and screws with site-indexing, assets and general performance.

One option we've investigated is to use our firewalls to do SSL Offload, but as I mentioned earlier, this would require all of the site to be encrypted.

What's the general thoughts on protecting against this attack vector?

I've asked a similar question on StackOverflow, however, it would be interesting to see what the systems engineers thought.

pobk
  • 275
  • 1
  • 7
  • 2
    All your site content doesn't need to be encrypted. You should be serving your images and static content from another domain, anyway, to avoid the overhead of sending cookies along with each static asset request (see http://blog.stackoverflow.com/2009/08/a-few-speed-improvements/ for background). – Evan Anderson Oct 27 '10 at 16:19

5 Answers5

5

As long as session data is passed in the clear between server and client, you are vulnerable to some kind of hijacking on unsecured networks. The stateless nature of HTTP pretty much guarantees that anyone with your session data can pretend to be you to the server.

So what to do? You need to securely pass session information from server to client, without eavesdroppers being able to intercept it. The surest, easiest way is to make your site all HTTPS, i.e. no unencrypted traffic. This is very easy to implement, as you don't have to change your application, only the servers. The downside is that it increases the load on your servers.

If that's not an option, then you need to somehow obfuscate the session data that the server passes to the client. And the client needs some scripting to "de-obfuscate" the session data to pass back to the server on the next request. Yes, this is "security through obscurity", and everybody knows that it doesn't work. Except when it does. So long as your site is not a high value target, obscuring the session data will prevent casual users of this 'firesheep' thing from hijacking your users. Only when/if your site gets on the radar of someone willing to reverse-engineer your obfuscation will this mitigation technique fail.

Steven Monday
  • 13,599
  • 4
  • 36
  • 45
  • 3
    I really want to upvote you but I can't get behind "security by obscurity" at all. Rather than thinking about this in terms of "security by obscurity" why not consider that a 2nd tier solution (if a site can't handle doing HTTPS) would be to use HTTP digest authentication rather than forms-based authentication with session cookies. It's still vulnerable to MiTM attacks and TCP-level hijacking but, at least, no credentials cross the wire (air) in the clear and third-party attackers can't heist your credentials. – Evan Anderson Oct 27 '10 at 16:16
  • +1 @Evan: I completely forgot about HTTP digest auth. Being a cryptographic protocol that securely shares secret state between client and server, it is a better solution than any stateless security-through-obscurity obfuscation kluge. – Steven Monday Oct 27 '10 at 19:13
4

Why would you have to encrypt the entire site?
Just set up a subdomain, login.yourcompany.com, encrypt that bit, set the secure flag on the cookie (stops it being passed over anything other than a secure channel), and set up the login server with an internal trust (however you want to do this is up to you) to the rest of the application.

Tom O'Connor
  • 27,480
  • 10
  • 73
  • 148
  • Well, user personalisation that happens on the site doesn't work then since the session is not available to the main site. – pobk Oct 25 '10 at 17:50
  • Why? Ever heard of memcached? Share your sessions between your application servers. – Tom O'Connor Oct 25 '10 at 17:51
  • The problem is the cookies. The fact they're unencrypted means that someone can sidejack someone's session. Where they're stored is irrelevant. Once they're sent in the clear, they're vulnerable to being sniffed. The reason it's a problem now, is that anyone who can install a firefox extension (pretty much everyone) can now do the sniffing. – pobk Oct 25 '10 at 17:59
  • Assuming they're on an unsecured network. – mfinni Oct 25 '10 at 18:02
  • Yes. Assuming you're on an unsecured network. I'm thinking from the perspective of protecting my users. – pobk Oct 25 '10 at 18:03
  • Huh? login.xyz.com is encrypted www.xyz.com gets the stored session data from the backend, but only login.xyz can write cookie data. The website appears to the user as being personalised, as the server has the session ID from the cookie. – Tom O'Connor Oct 25 '10 at 18:03
  • ALTERNATIVELY: construct your sessionID to contain something about the browser being used to access it. You can pull all sorts of stuff with javascript, so just use that to create something that ties that cookie to that user's browser. – Tom O'Connor Oct 25 '10 at 18:08
  • If the sessionID contains things from the UserAgent, there's nothing to prevent the attacker from sending a UA to match the victim. – mfinni Oct 25 '10 at 18:19
  • Who said anything about the UA. There's other stuff you could use. – Tom O'Connor Oct 25 '10 at 18:20
  • There's actually a deeper point in this lot. If someone wants to steal an identity, there's probably bugger all you can do as the systems guy to stop it. HOWEVER, if the session ID is hashed against the UA, it'll probably cut down on the script-kiddies going "ohai letz h4ck up th1s guyz profile". It won't stop a determined cracker/thief/etc, but it'll cut down on the fly-by attackers. – Tom O'Connor Oct 25 '10 at 18:28
  • @Tom Not a bad idea, especially as user-agent-strings are getting ever more unique. However, the UA string is in the same packet as the cookie so getting and submitting that is dead simple to the right extension. – sysadmin1138 Oct 25 '10 at 20:38
  • 1
    But you can't protect the unencrypted bulk of the traffic over www.xyz.com from a MITM, so an active attacker can arbitrarily mess with it, to say nothing of passively snooping on it. And how do you deal with valid browser complaints of mixed https/http content? – nealmcb Dec 24 '10 at 21:39
  • In this vein, see Ben Adida's proposal/code for "SessionLock Lite". No protection against active attacks or eavesdropping, and vulnerable to short-lived attacks, but it helps while you engineer your SSL solution: http://benlog.com/articles/2010/10/25/keep-your-hands-off-my-session-cookies/ – nealmcb Jan 07 '11 at 15:50
2

See Ben Adida's proposal/code for "SessionLock Lite". It admittedly offers no protection against active attacks or eavesdropping and is vulnerable to short-lived attacks. But it might help in the immediate term while you engineer a real SSL solution: http://benlog.com/articles/2010/10/25/keep-your-hands-off-my-session-cookies/

nealmcb
  • 297
  • 3
  • 10
0

Credentials should always be encrypted, never passed in the clear. What's so hard about that?

mfinni
  • 36,144
  • 4
  • 53
  • 86
  • The credentials for login aren't sent in the clear. The cookies, however, after being logged in, are not. – pobk Oct 25 '10 at 17:47
  • 1
    Aha, the first article I had found on Firesheep mischaracterized the problem. You could have added some details to your question. Firesheep is new enough that I don't even see it on Wikipedia, so the specific vulnerabilities would be worth enumerating in your question. – mfinni Oct 25 '10 at 17:54
  • 1
    @pobk: The cookie is acting as a proxy for credentials. If the cookie can be used to impersonate the user then it's a credential. – Evan Anderson Oct 27 '10 at 16:18
0

From a local admin perspective:

In order for firesheep to work on a wired network, the attacker would have to perform ARP poisoning on your switch infrastructure. Traffic to and from other computers will never reach the attackers PC, unless they first exploit the network.

From a service provider perspective:

I would want my site, or at least any auth or cookie traffic to be SSL encrypted.

From an end user perspective:

I would want the provider to keep my session safe, so I don't even have to think about typing in "https://". It should force me to be safe.

JakeRobinson
  • 2,904
  • 18
  • 26