With all the development that I’ve been doing lately on the AIM(R) Privacy Management software, I haven’t had much time to do the things that I enjoy. Namely, that means that I haven’t been messing around with websites and other random computers connected to the internet like I used to. But last night, I had a peculiar task that I set out to accomplish.
I was wondering what it would take in order to ‘hack’ a cookie. A cookie is supposed to be a piece of data placed on your computer by a remote website that your computer retains for future visits. Cookies allow sites to remember your name, for example. They sometimes also retain login information. This is where the vulnerability exists. A common method of storing authentication data in cookies is to store a username cookie, and a password cookie. Each time you visit the page, your browser sends those cookies, thereby automatically logging you in. Cookies, like all data sent via the HTTP protocol, are transmitted in plain text (unless of course you are visiting a website where the address begins with ‘https’ rather than ‘http’). Because this information is transmitted in plain text, anyone connected to the same network hub or on the same wireless router could easily view the contents of the transaction between your computer and the remote computer.
Sometimes, webmasters protect against accidental disclosure of your password as it is stored in cookies by using a technique known as ‘hashing’. Hashing is a one-way encryption scheme that converts your password into a garbled string that is machine readable but not intended for reading by humans. Most hashing algorithms are considered to be secure enough. The problem lies then in the fact that the hashed password is then transmitted in plaintext. A hacker would then have to take that plaintext hash and transmit it directly to the remote computer without having the remote computer attempt to re-hash that data. But, since the cookie on your hard drive is already hashed, all they really have to do is figure out how to transmit that hash as if it was a cookie stored on their computer.
Last night I actually wrote a PHP script that accomplished such a task, allowing me to transmit whatever cookies I wished to a remote website, then displaying the website in my browser. Shortly after, I found a plugin for Mozilla Firefox that allows you to not only view the cookies stored by a remote computer, but also edit them and delete them. I cannot emphasize the importance of this enough — cookie authentication is no longer a viable method of access control. An attacker merely needs to intercept a single packet containing a transaction in order to compromise the users account on the remote system. The problem is that now an attacker no longer needs programming or hacking skills and merely needs to be able to run both Ethereal and Mozilla Firefox and use basic copy and pasting techniques.
The experiment I performed last night involved a popular site for college students, TheFaceBook.com. With permission, I monitored a friend’s ethernet connection using Ethereal and a Motorola WN825G Wireless Notebook Adapter. Within seconds, I saw a single transaction between my friends computer and thefacebook.com. To some users, what was spat back out on my screen was garbage. But inside the HTTP header was a line that began with the word “Cookie:” and what followed was the data that their browser was transmitting to thefacebook.com. It appeared slightly similar to what is below (although I changed some numbers to make this data worthless):
Cookie: c_user=16153600; host=69.28.179.37; db=rpi; check_val=123639; c_code=11eacb6942f93e913f388b76ccbea0142;
Obviously, we can see a few useful pieces of information including the user number, ‘c_code’ and ‘check_val’. Both of the last two values are likely used to verify the identity of the remote user. However, within seconds, I had successfully manually entered those cookies into Mozilla Firefox using the Add N Edit Cookies extension. I typed in the address that their computer had requested — http://rpi.thefacebook.com/mailbox.php — and was immediately greeted by their message history. I was logged into their account without having any questions asked.
The moral of the story? Well, for most people, there is none. The problem is not with the users, it is with the developers. We must find creative solutions for these problems, or collectively agree to use HTTPS for even slightly sensitive data even though it incurs a higher processing cost. With HTTPS, these packets would be theoretically almost impossible to intercept. And without the data that I was able to sniff out above, this entire experiment would be moot. If you are interested in hacking cookies or forging cookies or even just experimenting with the cookie values other sites leave you, check out that Add N Edit Cookies extension for Firefox. And, of course, if you’re not using Firefox, you should switch away from Internet Explorer today!
0 responses so far ↓
There are no comments yet...Kick things off by filling out the form below.
Leave a Comment