[Infowarrior] - When cookies leak data

[Richard Forno]

When cookies leak data			
Written by Mike James	   
Friday, 02 September 2011 11:41

We all know that cookies need to be handled with care and new research indicates that the Google search cookie has  particular problems.

 http://www.i-programmer.info/news/149-security/2985-google-search-leaks-information.html

Cookies - we programmers love them because they make it possible to turn a stateless web interaction into a stateful application. The trouble is cookies have a reputation for being evil - and perhaps they are if not managed with great care. A recent research paper from Alcatel-Lucent Bell Labs outlines in great detail how an apparently harmless session cookie can be used to find out a great deal about a user.

So much so that the title of the paper is "Show me your cookie and I will tell you who you are". This is a little misleading because the paper also explains how to get hold of the cookie even if the user doesn't want to show it.

The cookie in question is the Google SID cookie which is used to identify a user to a range of Google services including Search. The problem is that this cookie is used by many different services with differing security levels. For example, the SID cookie is used to personalize the search experience and keep a record of what a user searches for and even which websites they visit. This data is gathered on the basis of just the SID cookie without any further authorization, i.e. you don't have to supply a password.

If you do want to examine the data they Google does ask for you to log in so the data is secure even if the cookie isn't - or is it?

The paper explains first how to hijack a users SID cookie which is a fairly easy task because there are many services for which the cookie isn't considered a security risk and it is transmitted in the clear. The SID cookie is valid on the entire *.google.com domain so all you have to do is get the user to visit a spoof Google website that uses HTTP rather than HTTPS. This turns out to be fairly easy in most cases.

Once the attacker has the SID cookie it at first appears to be useless because to see the users search history say or to do anything else requires authentication. This is the clever part. If the user has enabled Web Search History then any searches results are returned by Google color coded to show how many times they have been visited by the user. Performing a search using the SID cookie doesn't require authentication and by examining the color coding of the returned links you can tell if the user has visited them before.

So all you have to do is perform a wide range of searches and read off where the user has visited. This is made much easier by the use of the "visited" and "social" filters. The first only returns results that have been visited and the second returns only social posts and comments made by user.
 

Using the "Visited pages" filter and a search on the .info domain you'll discover I visit I Programmer a lot!


The authors conducted an experiment to see how much data they could retrieve just using the SID cookie. To do this they extended the FireSheep add-in to capture the cookie and display the results. Ten users were asked to run the experiment. All had search history enabled and 6 of the 10 knew nothing about it before the experiments. It is estimated that 50% of Google accounts have search history enabled and many are not aware of this.

Using a range of widely spread search targets .com for example with the visited filter on returns all of the .com sites that the user has visited. The experiment managed to retrieve typically between 10% and 80% of the sites that users had visited. The number of search targets was limited to avoid the user noticing the attack within their search history - although given that many were unaware that there was a search history this seems unlikely.

How can you protect yourself against this information leakage?

Simply use Google without logging into your account and the SID cookie isn't sent. You could also disable web search history. Alternatively always connect via a VPN.

In the long run Google needs to improve the security of even the apparently harmless SID cookie so that it is always transmitted encrypted.