More SideJacking

Our sidejacking stuff was named one of the top 5 hacks of 2007. Since then, we've noticed a few more things about it.

To recap: websites typically encrypt your password so it cannot be sniffed, but then send you an unencrypted "session-id" for that session. The session-id is either some random data in the URL, or more often, random data in an HTTP cookie. A hacker who sniffs the session-id can then use it to gain access to that session, which usually means gaining access to the account. Thus, the hacker can read your Gmail/HotMail/YahooMail, look at what books you've ordered from Amazon.com, control your MySpace/Facebook page, and so on. The hacker still cannot get your password nor your credit card number, but can most everything else.

SSL doesn't protect Google Mail

When I originally tested sidejacking, I found that there were some solutions. For example, Salesforce.Com by default encrypts EVERYTHING over SSL. While some of their customers choose to use non-SSL for some reason, the majority of their customers are protected.

SSL is not always complete. A good example is Gmail. In theory, using the HTTPS version of Gmail should protect you by going to https://mail.google.com/mail, but this doesn't work as you think. The JavaScript code uses an XMLHttpRequest object to make HTTP requests in the background. These are also SSL encrypted by default - but they become unencrypted if SSL fails.

When you open your laptop and connect to a WiFi hotspot, it usually presents you with a login page, or a page that forces you to accept their terms and conditions. During this time, SSL will be blocked. Gmail will therefore backoff and attempt non-SSL connections. These also fail - but not before disclosing the cookie information that allow hackers to sidejack your account.

This happens to Dave Maynor a lot. He leaves Gmail running using HTTPS. We sit down at a coffee shop. He opens his laptop to read a file. He doesn't even want to connect to the WiFi hotspot. However, the WiFi stack connects anyway, and Gmail sends out his session-id. I then connect to his e-mail account before he realizes what he has done. This has happened a lot, he has become very paranoid, and the first thing he now does whenever he sees me is verify his WiFi is turned off.

Hacking tools outlawed

Germany, and now the UK, outlaw the distribution of hacking tools. My sidejacking tools (Ferret, Hamster) are exactly the sort of thing they outlaw.

Does anybody know the legal ramifications of this? Does that mean I can no longer travel to those countries? Does that mean I can't travel anywhere in the European Union? BlackHat Amsterdam is coming up, and I need to know whether I shouldn't go.

This also begs the question why I distribute these if they are hacking tools. The answer is: because they demonstrate the problem. People don't believe a problem exists unless they can see it for themselves. Hackers don't need my tools - they can use the standard Wireshark product and the Mozilla cookie editor to do the job instead. What my tools do is make it obvious so that a reporter can point-and-click and hack their own accounts. Web 2.0 is fundamentally insecure because data isn't encrypted (except for passwords and credit card numbers). This insecurity exists because people can't see for themselves how the problem affects them. With my tools, they can see the danger they are in, and sidejack their own accounts.

This is part of living in a free society. Vulnerabilities released with Proof-of-Concept code help us understand the vulnerability, and security in general. Conferences like BlackHat are much more interesting because presentations release code that prove their assertions. We don't have experimental evidence in our industry, all we have is code.

Sure, the downside is that it helps hackers, but in the end, it's the defenders that win. Hackers had the edge over Windows for many years. Windows XP SP2 caught up with them, and now Vista is ahead of the hackers. The reason for this was the free and open society where we discussed and proved problems with code.

Which cookies to sidejack?

One of the problem with my tools is that they don't always work as easily as I would hope.

The basic problem is that I don't see the "Set-Cookie" sent from the server to the browser in SSL. I have to guess what that cookie is by seeing how it is used. A cookie is attached to a directory, and is sent for all accesses to that directory and subdirectories. If I see cookie "x=y" sent with subdirectory "/foo", it may actually have been attached to "/". If the browser accesses directory "/bar", I won't know if I should send the cookie or not.

One solution to this problem is to create my own accounts, and within my own browser look at where the cookies have been set. Unfortunately, the cookie editors I've used only show the permanent cookies, not the temporary cookies. In order to crack open the temporary cookies sent via SSL, I have to either rewrite a cookie editor or do a man-in-the-middle decryption of the SSL stream.

However, for HotMail, Gmail, etc., I've made some guess about what where the cookies are attached, and hard-coded them into the Hamster source code. These seem to work pretty well.

The bad part about this is that my tool may not work for a website. This will lead people to the false sense of security that sidejacking isn't a problem. However, sidejacking is ALWAYS a problem: there is no way to fix it other than encrypting the data with SSL. Just because the program guesses wrong doesn't mean that a hacker can't figure out the correct guesses and gain access to the data.