Monthly Archives: October 2010

Samy, the father of the MySpace worm (aka samy worm) recently released a new technique to persist cookies virtually forever in a browser. He named it evercookie.

“evercookie is a javascript API available that produces extremely persistent cookies in a browser. Its goal is to identify a client even after they’ve removed standard cookies, Flash cookies (Local Shared Objects or LSOs), and others.

evercookie accomplishes this by storing the cookie data in several types of storage mechanisms that are available on the local browser. Additionally, if evercookie has found the user has removed any of the types of cookies in question, it recreates them using each mechanism available.” — described by Samy.

When people are looking around how this cookie can be removed from their browsers, Samy is trying to improve it by adding new more techniques. Currently during it’s cookie creation, it tries to store in different places in your browser using 13 mechanisms so that just clearing browser’s cookie doesn’t remove evercookie. It’s so powerful that many smart users will not be able to clear it even, general users are far behind. HTML5′s session storage, local storage, global storage, and database storage via SQLite makes it more persistent. Already some security researchers have identified how this can be removed in Safari, Chrome but not yet from Firefox. The technique I am going to describe works in firefox 3.6 with Samy’s current version.

Go to Samy’s evercookie demo page. Click on “Click to create an ever cookie”. Make sure evercookie is stored in every place except ‘userData’ storage (it’s for IE). You may need to click on ‘click to rediscover cookies’ few times to store it in every place.

Open another tab and close the first (samy’s) tab.

Now open Silverlight Home Page and delete Silverlight Isolated Storage. To delete, right click any Silverlight application then Silverlight > Application Storage > Select the website samy.pl > Click on Delete… finally click on ‘Yes’

While toying with a bug in Google signup page, suddenly found a security hole related to redirection attack combining Google sign in page and goo.gl (URL shortener) service. Provably you have noticed that if you are not logged in your Gmail account already and hit the http://www.gmail.com page in the browser’s address bar, it is redirected to something like:

Notice that the above location has a ‘continue’ parameter which basically assists the user to redirect in the given location. I tried to tamper this location, when I put different domain (which Google does not own) it shows an error like: “The page you requested is invalid.” I tried with some domain which Google owns, it works then fine. Suddenly I remembered the giant’s new service http://goo.gl and just thought an idea which finally worked.

First of all I created a sign up page which is similar to Gmail Sign up page and then hosted it in my domain. I shortened the URL using goo.gl which becomes http://goo.gl/mRIl. As the ‘continue’ parameter only allows Google’s domain, I used it in the following manner:

Now if you hit the above URL, you will see the Google’s actual login page and then if you provide your valid credential and hit the ‘Sign in’ button, you will be redirected to my Phished page which is identical to Google’s login page. Don’t fear at all, I am not collecting your credentials. It’s just a proof of concept how the new redirection attack can be used by the hackers to compromise your Gmail credential.