Sidejacking with Hamster

What is Sidejacking?

Sidejacking is a form of “HTTP session hijacking” that works with “passive” eavesdropping.

HTTP session hijacking is where the hacker grabs your “session cookies”. Your session with the web server is identified with a unique cookie. This cookie is sent to your browser at the start of the session, and your browser echos it back from that point forward.

There are man forms of session hijacking. Some use cross-site scripting to grab them from your browser. Some use “man-in-the-middle” attacks to intercept the connection then resend it. The sidejacking method uses passive eavesdropping of cookies. Users collect cookies using a packet-sniffer, then import them into the browser. Unlike other methods of session hijacking, there is nothing the user can possibly see that would tell them their session is being hijacked. They can’t “View source” to find errant JavaScript (as they could with cross-site-scripting attacks). They can’t sniff their own traffic is see that it’s being changed (as in man-in-the-middle) attacks.

In addition, sidejacking allows for offline attacks. Session cookies last a long time, sometimes for years. That means a hacker could capture packets with a packet-sniffer at one point, then weeks later in another part of the world, import the cookies into the browser and access the session.

How Hamster works

Hamster is a proxy server. There are a couple ways sidejacking could work. One way would be a browser add-on. Another way would be as a proxy server. The hacker would connect through the proxy, which would then rewrite the cookies on behalf of the hacker.

The following shows Hamster in action. On this screen, we see the web browser “console” screen.

To explain what we see here. The hacker has started monitoring the Ethernet adapter “eth0”. So far, 14,671,978 packets have been sniffed so far. So far, 1,517 objects were found on the wire, such as cookies and URLs. Virtually all of these are repeats. We found 3 IP targets, but only two of which have cookies associated with them.

Our own IP address is “23.23.23.118”. Unfortunately, we will probably sniff our own session cookies at the same time. Never choose that as your clone target, or bad things will happen.

The victim’s IP address is “23.23.23.101”. The victim appears to be using Gmail, and has the login name of “aardvark.zebra”. By clicking on this IP address in bottom of the screen, we set this as our “clone target”.

When we select a new clone target, URLs appear in the left screen. Those at the top are URLs that we think might be interesting. The largest list below that is all the URLs we’ve seen from that IP address.

When we click on the URL “http://mail.google.com/mail” when our clone target is set, up pops their Gmail screen.

The important thing to remember, we don’t know the victim’s password, we just have their session cookies.

Here is what the victim sees on their screen. In this example, the victim is running Windows and Internet Explorer. As you can see, the victim sees a normal Gmail session, and there is nothing the user can discover in order to see that a hacker on Linux with Mozilla has hijacked their session.

Building Hamster for Linux

Hamster exists as two programs. The first is “Hamster”, which is the proxy server you use. The second is “Ferret”, the tool we use to grab session cookies.

The project/makefiles are largely unnecessary. You can just compile all the source files together. The errors that pop up can be resolved pretty easily.

To build on Linux, grab hamster.zip and ferret.zip and extract them.

To build Hamster, go into the directory “hamster/build/gcc4” and type “make”.

The binary will be dropped into the “hamster/bin” directory. Notice that this directory already contains “favicon.ico”, “hamster.css”, and “hamster.css”. These are used by the web server. When the web server runs, this should be located in the current directory with Hamster. Note that Hamster will run fine without these, it makes it a little nicer. For example, it should detect when the state has changed and auto-refresh the screen for you – without JavaScript, you’ll have to keep hitting refresh yourself.

Now go into the “ferret/build/gcc4” directory and do the same thing. This will drop the “ferret” executable in the “ferret/bin” directory.

Now install the binaries somewhere. Both ferret and hamster need to be in the same directory.

Now run “./hamster”. This sets up the proxy listening to port number “1234” (by default).

Now start your web browser. Hamster works as a proxy, so we need to configure the browser’s proxy settings. This is why it’s a good idea to create a separate “hamster” account from your normal user account, so that you can trash the browser’s proxy settings and cookies without worrying about hurting your primary browser.

Now browser to the site “http://hamster/”. This website doesn’t exist, it’s a virtual website in the proxy. When you browse to that website, you are accessing the internal Hamster console. When you browse to any other websites, you will go out to the Internet.

Look for the “Proxy” entry under the status information. This will tell you the status of the underlying Hamster proxy. If it crashes, you’ll get a warning message here that it’s not running. Otherwise, the first status message you’ll ssee is “No cloned target”. We’ll show you how to get the cloned target below.

The top of the screen contains several paragraphs of help information. To make them go away, just click on them (assuming you’ve got JavaScript running).

When you click on the “adapters” menu item, you will go to a screen that allows you to start monitoring on an adapter. What really happens here is that it will start the ‘ferret’ program running in the background that sniffs the adapter in promiscuous mode looking for cookies, then sends them back to Hamster.

Unfortunately, the Hamster application itself won’t list which adapters you have available. You’ll have to go to the command line to fine that out. For example, on Linux, you’d type “ifconfig” to get a list of adapters. You might find one called “eth0”. You type that into the Hamster screen, and hit “Submit” to start Ferret running on that adapter. Note that Hamster supports many kinds of WiFi adapters. You can either monitor the adapter you are using to connect to an access-point, or one that you’ve put into monitor mode for sniffing.

After clicking submit, you’ll be sent back to the main screen. If everything goes well, you’ll see that the “Adapters” status is now monitoring “eth0” and that packets are being captured in the background.

After waiting for a few minutes, you should start seeing IP addresses appear.

We can click on that IP address in order to clone its sessions. Notice that the “Proxy” status will now change and inform you that all proxy requests will contain the cloned session cookies from that IP address. In the right hand window, we can see the websites that the victim is visiting. At the top we list likely targets that hare hijackable, but other URLs below that may also be hijackable.

In that left window, if you click on the [cookies] menu, you’ll get a dump of all the cookies we’ve seen so far for that IP address. You can browse the cookies to see if you have anything interesting there. For example, when hijacking Gmail sessions, the important cookie for the session is the “GX” cookie attacked to the “mail.google.com” domain.

When you click on a URL, the browser opens up a new tab containing that URL. If everything works correctly, you should now have access to the victim’s account.