More on cookies(sidejacking) and browsers

I spoke about sidejacking in recent posts and the advantage a hacker can gain with a users cookie. Cookies are used to authenticate users to a domain and cookies are stored locally somewhere on your computer. I wrote perl sniffers that can sniff the relevant cookies to pull of a sidejacking attack but its so much easier to just copy them to a thumb drive when you have physical access to the victims machine.

In IE, cookies are stored as simple text files that can be open with notepad or wordpad for easy viewing. The location of the stored cookies from IE is in "c:\documents and settings\user_name\cookies". Each text file represents a stored cookie. You cant just copy them onto your machine and hope to gain access to your victims account. There is an index.dat file that seems to be a very important file thats constantly in use and cant be opened while the operating system is running (this file contains the list of legit cookies that should be loaded in IE). However if you were to obtain those cookies, open them up in an editor and input them into your browser using a cookie editor, then you are just clicks away from pulling off a sidejacking attack.

In firefox, the cookies are not stored as individual text files, but rather in a database file called "cookies.sqlite". This file is located at "c:\documents and settings\user_name\application data\mozilla\firefox\profiles\xxxx.default". As it is a database file you will need a sqlite databse editor in order to read its contents. I use this free sqlite manager called SQLite Database Browser 2.0. For security reasons you wont be able to read this database file on its own. There is a "permissions.sqlite" file that also needs to be copied to the same directory as cookies.sqlite as well. So the cookies.sqlite and permissions.sqlite files are both needed in order to read the contents of the cookies.sqlite folder. Just copy both to the same folder together then you should be able to open them up in the sqlite browser program and read the cookie information.

Now we know where the cookies are stored, what can we do from here?
Well, if you have physical access to a users machine you can sneakily copy those cookie files to your thumb drives and process them when you get home to your attacking machine. Whats even more clever is to create an auto-run script that automates this process. So you would have a malicious usb thumb drive and when you plug it up to a victims machine, it copies the necessary cookies from the victims machine to the thumb drive in a few seconds (say 5 seconds). The attacker can takes those cookies home and munch on them as he grins in amazement as he reads his victims eamils without even logging in with the relevant user name and password.

Stealing cookies to impersonate web-users and hijack user accounts (Sidejacking)

This post is more on theory behind such an attack and why they work. I blogged about a tool called ferret and hamster in the past which can be used to demonstrate this attack. When i first saw the awesomeness of such a tool a line was drawn between me having the understanding of what was really going on and being a script kiddie. I knew how the attack works and why it works but it was never something i could've accomplished on my own. That is no longer the case anymore :)

The idea behind the side jacking attack is to impersonate a user via their cookies and session IDs. Cookies and session IDs are two mechanisms that a webserver may use to authenticate or remember its clients. For example, say you log onto gmail and you exit that web browser session without signing off, the next time you open up your browser and navigate to the gmail sign on page, you would notice that you are automatically signed in. This is because there are certain cookies and session ids stored in your browser that is being used to authenticate you to gmails servers.

This attack isnt quite difficult using tools like ferret and hamster that are already out there but sometimes things don't work like they should. I've encountered such problems and decided to digg deeper into this and see how i can do this attack without using such tools and maybe i can understand why they work sometimes and fail the other times. The difficulty in writing such a program is in figuring out what cookies to clone. In my research i also found that only the content field in the cookie might be used to authenticate the user and not so much the expiration date and time fields. Haven't tested on many sites but i tested on one of my favorite music discussion forums, www.boxden.com.

I wrote a few perl sniffers including one(specifically tailered to sniff the cookies from the boxden.com domain, that extracts the cookie information in an easy to read format. When the sniffer sees the necessary cookies from this domain, including session and userid cookie information, it pulls them out and dumps them to standard output(screen). I can then quickly manually use a firefox extension to edit and or add cookie information as necessary. After insertion of the required cookies, i can then navigate to the domain (in this example, www.boxden.com) and with some good luck, you would now be impersonating someones user account. You now would be able to read their emails, edit some of their personal information etc. Its for this reason users should be more concious, not only when using public internet hotspots, but even at work and their homes as well. This type of attack can best be mitigated by remembering to logout from all your web sessions.