Author: DarkKnightH20

What is cookie theft?

To know what cookie theft is, you must first know what a cookie is. A cookie is a tiny file downloaded by your internet browser through a website. It is often used to track users, store information, or save settings. However, it is important to know that not all websites use cookies. In fact, majority do not. A solid hint as to knowing whether or not a website uses cookies is simply available by looking at its content. If there are user selected options that save once clicked, and/or a login area, then chances are that cookies are being used to store this information. Some websites, such as Google, use them more secretly to do statistical analysis relating to user activities (Note: I’m refering to the search engine itself, not their GMail, Shopping Cart, etc). Cookie theft, in short, is the act of stealing another user’s cookie.

Why would someone want to steal cookies?

Besides being tasty (oh, what a good joke), the art of cooking theft is most commonly associated with the stealing of login credentials, which is particularly easy if the user has “automatically login” enabled for the website in question. In theory (and commonly in practice), if you have another user’s login cookie, you can login to their account (sounds simple enough). Most cookies, if they contain important information (i.e. a password), are encrypted. An attacker can decrypt the cookie to find out the actual password. Thankfully, most cookies do NOT contain passwords. Instead, “Session IDs” can be used, which contain a script generated series of letters and numbers, usually in conjunction with the username. This, though more secure, is still subject to vulnerabilities, as sessions can be hijacked if the user replaces his/her own cookie with the newly obtained one. An easy solution to this is to restrict the session to work with only the original IP address used. Unfortunately, this is not very friendly towards those with dynamic IPs, thus can be thrown away partly.

How is it done?

Now that theory is taken care of, let’s talk about practice…How is it done? Through HTML injections usually, but pretty much any website that uses cookies and allows users to post HTML may be vulnerable. With that being said, since web scripts can be designed to filter out cookie theft attempts, you may have to encode the html and/or javascript that’s being used to hijack the cookie. However, that too can be filtered out, but ah, I’m getting ahead of myself. When stealing cookies, the attacker often creates a 3rd-party webpage that uses PHP, CGI, etc. to capture data in a format like so– http://www.darkknight.com/example.php?capt…t;DATA_HERE>

The “” text would be recorded to a server-side file. After being recorded, depending on the script, the page would then either display images, text, a fake 404 error, redirect, etc — basically anything to look less suspicious. OK, so the data is captured through a third-party script…but how do you feed the script the cookie? The most common way is through feeding it a little code called document.cookie. Majority of the cookie stealing methods that exist today use document.cookie. For educational purposes, I’ll now make a not-so-uncommon scenario in which cookie theft can be done…

Scenario

One day, you decide to visit a forum that you commonly go to. It turns out the owner decided to enable HTML so that people could make cool signatures using HTML instead of the built-in forum code. You see a post with the title “Hey Everybody, Look Here!” and you decide “Hmm…Ok…I’ll play ball” — so you click it. When doing so, you simply see a normal post with text saying “Boo!”. Naturally, you’re a little annoyed so you exit the post and go to bed angry. When you wake up, you are left to find that someone deleted your private messages, changed your signature and avatar to something vulgar, and made a million posts under your name…And, ontop of all of that, the admins are mad at you and want to ban you because they think you’re the one who did it. Oh no!

This scenario is not as uncommon as you might think. Remember what I said about document.cookie? Well, it can be used to steal cookies in a most invisible manner. An attacker can use invisible iframes to feed the cookie stealer (very stealthy), can redirect the page in question to feed the cookie stealer (not as stealthy), can use a popup window to feed the cookie stealer (a bad method, especially since so many people use popup blockers now adays), and, unfortunately, can even use a flash file to feed the cookie stealer (very stealthy), which is even more dangerous, as many community scripts (i.e. forums) allow for flash files to be posted.

Proof of Concept

The above PoC is a simple redirection-based script. It will feed the URL the cookie in a primitive, yet effective way. I will not post an example capture script, as I in no way want to promote the theft of cookies, but it’s a very basic code that many web scripters could create in less than a minute.

Note 1: To check if a website/webpage uses cookies, type java script:alert(document.cookie). If you would like to some reason copy this cookie, then typing java script:document.cookie is more copy/paste friendly, as it displays as plain text on a blank page.

Note 2: Firefox has tools available that allow users to modify their cookies for a particular website on the fly. This, undoubtedly, is of great assistance to those who perform cookie theft.

Note 3: Forums with HTML enabled are incredibly prone to cookie theft. Either enable adequate filtering or disable HTML altogether to help increase safety.

Note 4: Cookie theft is often used in conjunction with other vulnerabilities. As stated, often times it works hand-in-hand with HTML injection. However, it can also popup where you least expect it…an example situation — a CPanel vulnerability could help an attacker insert a cookie stealing script into the CPanel logs, which, upon viewing, would execute the theft of the CPanel cookie (Note: I used CPanel as an example for no particular reason other than it is commonly used).