Monday, January 14, 2008

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, 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, 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.


mokum von Amsterdam said...

Are you ever going to release an iPhone version of hamster and ferret or should I shut up about it? :D

Arshan said...

There are lots of tools like Paros or WebScarab will allow you to intercept all of your own SSL traffic, and perform MITM operations in general.

SideJacking is a cute name but I think cookie sniffing has been a known issue in appsec for a while. However, it would appear that it took your tools and talk to get other people talking, so I applaud your efforts.


Ron said...

Is sidejacking cross-platform? Do hamster/ferret find cookies in their default locations for OS X/ Linux?

SkynetBbs said...

I don't think this is an issue on FON wifi hotspots hence they are sponsored by google and thus allow *.GOOGLE.COM in http/https while you are not yet authenticated.

Robert Graham said...

I don't think this is an issue on FON wifi hotspots

It's less of an issue, but it's still a threat if the hacker generates RST packets.

Bryan said...

Sorry if my question exposes my ignorance of the issue, but suppose that I do either or both of the following will I be susceptible to sidejacking:

1) Always log out of gmail/google accounts etc after using them (doesn't this terminate the session cookie hence any sidejacker would need to have the new session cookie transmitted only after an SSL session is created and I am authenticated?

2) Use WPA on a WAP (so in a sense does not address your security concern as it appears more directed at "open" WAPs, that is public access)?

Glenn Fleishman said...

I spent a reasonable amount of time reading the German law you're referring to and studying reactions to it and commentary. Of course, you need a Rechtsanwalt (German attorney) to be sure, but the law seems to state clearly that the release of software that makes it possible to commit acts that are themselves in violation of the act violates the act.

The folks who made KisMAC, as you know, divested themselves of the software, the Web site, and their involvement to avoid potential fines and imprisonment just by the de facto nature. With your software hosted outside Germany, if you didn't bring the software with you, and had no specific intent to distribute it while there, unless a prosecutor had an animus against you, the law doesn't seem to call for your arrest.

But merely having the software on a laptop without and not even using it would probably constitute an offense.

Ryan said...

This is an interesting issue as most users would have no idea than this information is being leaked outside of the information channel whilst waiting for the establishment of the SSL connection.

I haven't tried but does a "Google cookie" also grant access to the other google accounts a gmail user may have?

SA said...

Very nice article. A good read and learn. Thanks.

thebig said...

'Hacking tools' distribution isn't illegal under UK law. This was brought in under the the Police and Justice Act 2006 as an ammendment to the Computer Misuse Act 1990 (CMA); but they are yet to be made 'active' by bringing them into force in law.

Eric Hacker said...

Since Google Toolbar keeps one logged in across all Google sites, like this one, doesn't that present similar sidejacking risks. I don't have time to check.

If I were in Maynor's shoes and hanging around you often, I'd have a VPN setup so that I couldn't do anything except through the encrypted tunnel to a safe place. Most of my paranoia is not from what my enemies might do, but from what my friends will do.

Nicholas Weaver said...

Its actually EVEN WORSE.

The Gmail GX cookie does not have the SECURE attribute set.

So all you need to do is to someone who still has the cookie set (not necessarily logged in) is..

1Arp cache poison or TCP packet injection to modify their web surfing.

2Have the next URL they fetch return a 301 redirect to

3Capture the GX cookie as it is sent.

4Inject as the reply a 301 redirect back to their original URL.

Voila, you have their GX cookie, and they did not even have to have gmail open!

Nicholas Weaver said...
This comment has been removed by the author.
Ed said...

Ryan, this might answer your question

Koh said...

Would this hacking works for non-wireless network too? I am using secure Gmail at home LAN and I do not want my neighbor to eavesdrop on me!

cyber_eagle said...

I live in the UK and am pretty concerned about these laws too. The wording of the UK law is not as bad as the German one however, and as a legitimate security researcher you are probably gonna be ok. Right now there's a nasty uncertain feeling about the whole thing though. Also as 'thebig' commented, the law is not yet in effect in the UK anyway.

We recorded a podcast discussing the UK law for sploitcast which is here.

Also, nice find! Those captive portals seem to be more trouble than they are worth.

Nicholas Weaver said...

Actually, the problem is even WORSE!

Against an active attacker, Gmail's cookie handling is so bad that SSL offers effectively no security over non-SSL!

I've got a summary here.

SA said...

I have written a article on "Orkut vulnerability". Further explores the strength of sidejacking !!

Chris said...

I tried sidejacking my Facebook account (both with hamster/ferret and manually with wireshark and the firefox cookie editor). Doesn't work anymore, but it did when I tried it a while ago.

Has anyone noticed if they've fixed the problem?

Samisoomro said...

"I review this site and getting good idea and view that written here, life lock is good industry taking good steps keep monitoring identity thieves and it always protect from wrong hands’ and taken full service . No one stop identity theft, but we almost completely cover it and its life lock guarantee. So we suggest visit this site hope you getting more knowledge.

sebastian nielsen said...

I know how to protect against "Sidejacking".

Have a encrypted value, either in URL.

The value is the action that the link or form does, like "send a mail" or "read a mail", "delete a mail" and so on, combined with a static value, like "VALID_STRING" and then the username. This is then combined with a hash of (username, action, User's IP, and a random value in database, and a server-side "password" that only the server knows, and today's date)

The whole thing is then encrypted with some symmetric cipher, preferably AES256. Only server has the key, and then the encrypted string is sent to the client..

Everytime a request is done, the cookie/URL data is decrypted, and then it checks that all the data hashes to the same hash as in cookie/url-data.
When a correct hash is received, the random value in database is changed, which means that the current url cannot be reused.

If a invalid hash is detected, it checks that the static string "VALID_STRING" is detected (this means that the AES encryption is correct), and that means somebody either is reusing a old URL or has tampered with the hash.

If a such invalid url is detected, with a "VALID_STRING" inside, it should immediaty log out the user.

This causes one of 2 things. If some hacker sniffs a URL and uses it, the real user will be unable to use the url, and the real user will log out BOTH the hacker and himself.

Or the real user uses the url before hacker, but then the hacker will log out both himself and the real user.

The system with "VALID_STRING" is to prevent DoS attacks by sending garbage to the server to log out users that isnt affected by sniffing.

Then SSL is not needed.

Robert Graham said...

I know how to protect against "Sidejacking".

Nope, that wouldn't work. It would break the "back" button and other things in normal usage. It wouldn't protect against a hacker who quickly intercepts the session, does lots of bad things, all before the user clicks on the next button.

Anonymous said...

Hey are you a professional journalist? This article is very well written, as compared to most other blogs i saw today….
anyhow thanks for the good read!

Anonymous said...

Nice fill someone in on and this enter helped me alot in my college assignement. Thanks you seeking your information.