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.

RAM(memory) analysis

What is stored in ram? Programs? Yes. Can you think of anything else? Well let me introduce you to a crucial aspect of almost every digital forensics investigation. Digital forensics doesn't stop at hard drive analysis as most indiviuals may assume but in many cases (most) when applicable, the RAM is also investigated. RAM can reveal many things that a hard drive wouldn't. Put simply, a hard may contain pieces of the entire puzzle and the RAM may contain the remaining pieces. Just as an example. If a user sent an email to someone using some outlook and deleted stored copy of from the "sent emails" folder, how would you attempt to recover that? First off, you probly wouldn't even have a clue that it exists. The hard drive would have information about outlook being used but the information ends there. Chances are that you wont be able to recover such info from the hard drive in this case but all is not lost. Back to the original question i started off with, What is stored in RAM? Alot on things to be put in one sentence. You can find programs, passwords, web pages, pictures, documents etc. These represent files and programs that were accessed from the time the system was started and been up and running. This means that you can recover files from RAM. Yes, you can use a method in which you can carve the files out of memory, using similar recovery techniques used in hard drives to recover data.

I'm gonna go through a simple demonstation, from obtaining RAM and tools you can use to analyze or carve files out of memory.

Mdd:
This is a windows based command line tool that can dump the contents of RAM fairly fast.
command: mdd.exe -o ramimage.img

After mdd has dumped the RAM, i then upload it to a typical linux distro for analysis (I use Backtrack 4).

I then can use the "strings" command and pipe the output to the "grep" command to search for keywords like 'password', 'vb_login', 'md5_password', 'confidential', 'secret' etc.

To get an idea of the websites browsed/visited in the time the machine was booted i like to use the following :

• #strings diskimage.img | grep "Visited:" |more
• #strings diskimage.img | grep "Referer:" |more

A more advanced utility that i find very useful is the Volatility frame work. Its a python based suite of tools used to parse RAM dumps for more specific information. This includes a listing of all currently running processes, a listing of running services and open ports (equivalent to the netstat command), lists the loaded dlls, lists open files and much more. Its more for the advanced user so i wont get into it but its not that very hard to use. Oh, in Windows XP service pack 3 (or 2, cant remeber which), you can get the SAM hashes from the acquired memory image.

xxd can be a usefull utility that gives you an alternative way to view memory.
#xxd diskimage.img|more

To carve files out of RAM i use scalpel or foremost. These programs allow you to carve files by first identifying special bytes that indicate the potential file types for files. The header and footer information may also be needed to carve out the entire file itself.

Autopsy is a more enterprise suite that combines ease of use and a nice interface into the methods that were discussed earlier. It groups investigations into cases and keeps everything you do organized. This tool is used by many professional organizations for investigating cyber crimnals, etc. but shouldn't be used by itself as an entire forensics solution.

Driftnet, - a sniffer for you(noob), but not so much for me

Although i can never find a situation where this tool becomes a must have for my security toolbox, maybe someone else might. Its a simple sniffer with a specific purpose. It looks for and captures images and can store them to a location you specify. Whats also cool about the tool is that it can display images instantly as they are seen across the wire in a little window panel that updates almost instantaneously. It only picks out jpeg and gif type images which is basically most of the images out on the internet anyways.

Drifnet also has the ability to sniff mpeg audio as well from the network and potentialy play them through a player such as mpg123.

Commands:
#driftnet -h //help, lists other available commands

#driftnet -i eth0 //sniffs images and displays them instantly in a little window as it sees them across the wire. You would have to click on the image to save them in the current folder.

For more information on this tool, google has lots of info for you to discover and the man pages are almost always available to you in linux.

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.