According to Facebook, Graph Search not only helps people finding information about their friends, it also helps them to know what information they reveal about themself. I find this objective questionable especially in France where many people are still not aware that Graph Search even exist [1] and yet have their profiles searchable by anyone in the US. Yet, Graph Search is certainly very useful and educative about what could go wrong with tagging and shared content.
The issue of the Friend List
When Facebook announced Graph Search in January, I was surprised by their decision to not show friends lists that could be recomposed by browsing timelines. Recomposing part of someone friends list was time consuming but possible if you spent time scrolling down the timeline.
Last July update of Graph Search makes it even simpler to retrieve list of friends of people who hide it. Indeed, Graph Search now allows you to search who liked or commented on photos. Since some content is only visible to my friends, only they can comment or like my pictures. Having a list of people who liked or commented on my photos is like having a list of my friends with who I share things on Facebook. Some people that I do not know commented on my photos, but that’s a negligible fraction.
Unwanted side effects
Surprisingly, it seems that you can even know if someone liked a photo you don’t have access to. Indeed, in some circumstances, you cannot see which picture has been liked; you only know that someone liked a picture (see bellow). It goes against Facebook claim that Graph Search only gives you access to information you already had.
Update: In fact, the person who liked the picture is not searchable but she appears in the search results because she liked a public photo.
The picture liked by the first person is accessible, not the second one
Another annoying effect is that queries like “People who liked photos by me” returns a list of people with who I’m no longer friend. And it’s pretty easy to spot these people because they are systematically at the end of the result list.
How bad is it?
To measure the fraction of the friend list that could be retrieved through Graph Search, I listed the number of results that were listed when I search for:
Q1 :“People who liked photos by X”
Q2:“People who commented on photos by X”
Q3:”People who uploaded photos liked by X”
Q4: “People who uploaded photos of X”
Unfortunately, Graph Search does not (yet?) support ‘OR’ queries so there is no easy way to quantify the overlap between these four queries . I reported numbers of confirmed retrieved friends (using the “mutual friend” filter) and the total number of retrieved people because it also includes former friends. I compare that to the number of friends I have (and I thank my friends who did not hide their friends list).
X
Q1
Q2
Q3
Q4
N Friends
Ratio
me
59 ( 73)
43 (45)
42(54)
19(20)
207
28.50%
I made some tests on a few friends and I obtained similar results [2], queries Q1 and Q3 are the more effective queries in general. On average, Graph Search returns 30% of friends, plus some former friends. I guess I could retrieve up to 40-50% by combining the four queries. It’s problematic because many people assume that their friend’s lists are safe, but this safety goes away when they share likable photos or when they like photos.
Since “Like” visibility is public, you can even retrieve some friends of people with who you have no connection. I can imagine many circumstances where having your list of friends publicly available is very problematic.
What can you do?
Unfortunately, you cannot prevent your friends from liking content you share with them. Likes are not like tag or comments: they cannot be removed. The only current solution is to not share “likeable” content or to ask to people to not like it, but that’s very counter intuitive on Facebook. In the end, you can only hide friends who don’t “like” you.
Another solution is to obfuscate the list of people who liked your pictures. I probably rely too much on obfuscation, but asking people you don’t know to like your photos is currently the only technical solution to prevent stalkers from quickly retrieving your friends.
Acknowledgements: Thanks to my stalked friends who do not share their friends lists, they motivated this post. Thanks to those who do share their list, they helped me to make this post relevant.
[1] If you have not yet enabled “Graph Search”, I recommand you to do so. See http://www.fredzone.org/comment-activer-le-graph-search-de-facebook-929
[2] I’ll post more results when I’ll get their consent
After finding an information leakage in Google Search, I’ve been curious to see if there were no other pieces of information that could be gleaned from other Google services. To verify this, I visited my Google Dashboard, replaced my SID cookie and clicked on all the HTTP services that were listed.
My first attempt failed as I was systematically redirected to the account page where I was asked to enter my password. I then tried to also spoof the HSID cookie — also sent clear text — but because HSID cookie is an HTTPOnly cookie [1], it cannot be modified by a script or by the user: the cookie can only be modified by the server.
Spoofing HTTPOnly cookie
The best solution I found was to install a local proxy to intercept the HTTP traffic and then modify the cookies (I recommend Burp free edition which does a good job). It is then quite simple to replace the HSID cookie in the sent requests.
This time it worked, I was able to log into two services under with the spoof account:
Google Alerts: I was able to view and edit the mail alerts that were configured for the spoofed account.
Google Social Content: This service lists all your Gtalk contacts (that means most of the people you chatted with a couple of times).
Google Contacts: This is the Gmail contacts manager, it allows you to view, edit and create Gmail contacts. Quite useful if you want to get a list of persons to spam. An attacker could also attempt to replace the mail address of a contact with its own mail address.
Google Reader: You could see and edit RSS subscription.
Google Maps : You could see the maps associated to the spoof account.
There might be other vulnerable services but I think this list is already quite exhaustive and each of the listed service is likely to provide sensitive information.
Design flaws
Spoofing an unsecured cookie to hijack a session is nothing new. Nevertheless, there are two design flaws that HSID and SID cookies spoofing more critical:
These cookies can be used to provide an access to multiple services: when Google created these services, it did not assign a specific cookie for each of them. Therefore a single pair of cookies provides an access to all these services.
SID cookies are still valid even after the user logout: if a user thinks his session has been compromised, there is nothing he can do to revoke it. It seems that this was already pointed out 4 years ago .
Conclusion
Google is working on these issues and they should be fixed soon (users are already redirected to encrypted search [2]). Therefore, a next step would be to check if other major Web service providers have a better cookie policy.
Reference:
[1] Jeff Atwood, “Protecting Your Cookies: HttpOnly”, http://www.codinghorror.com/blog/2008/08/protecting-your-cookies-httponly.html
[2] Evelyn Kao, “Making search more secure”, http://googleblog.blogspot.com/2011/10/making-search-more-secure.html
Back in February, I re-discovered a small flaw in Google Search: result personalization leaks the list of results you clicked on. This leak was already known and mentioned in a paper by Castelluccia et al., but several features added by Google made it critical.
First there is the possibility (for web search history users) to only view result that have already been visited (visit http://www.google.com/webhp?tbs=whv:1).
Second, with Google Instant it is possible to view visited links quickly without living a trace in the victim Web Search history (the attack is not-destructive).
Third, when Google display previously visited search results, it used to provide the query that led to the results searching when he clicked on the result, thus the attacker knew which keywords the victim was usually searching for and could have enter these keywords in a search box to get new results which will suggest new keywords to type and so forth and so on…
The third point has been addressed by Google very recently, when they introduced the new interface with the black top bar. Vincent Verdot and I wrote a paper about this flaw. In order to conduct an experiment, we’ve been working on a proof of concept and an evaluation tool that we used to gather results.
Proof of concept based on Firesheep
This proof of concept is based on Firesheep (I just added a module and modify the attack launched when a SID cookie was captured). Firesheep is only working with the latest version of Firefox 3.6, do not expect to run it on Firefox 5.
With our version of Firesheep, when a Google SID cookie is captured, the account name appears in the Firesheep sidebar. Double clicking on it starts the attack; double clicking again displays the retrieved list of visited links.
The Evaluation tool
We also designed a Firefox extension which downloads your web search history on your computer, issue a couple of search queries (mostly searching for extensions like: « .com, .fr, .us, .html, www, … ») and see how many clicked links can be retrieved.
We’ve run this experiment with a dozen of account and sent the result to Google. We’ll soon publish the paper as a technical report.
How to protect your Click History
We’ve been in contact with Google Security Team who is working on a fix that should soon be deployed. In the meantime, make sure you’re not logged in your Google account when you’re connected on an unsecured network.
If you do not use Web Search History you may also purge it and disable the feature (visit https://www.google.com/history).
Also, TrackMeNot and Unsearch will reduce the exposition of your click history.
Running the Test
If you want to run the test 5 minutes:
A Google Account with Web Search History enabled. To check that you activated it, visit https://www.google.com/history; if it asks you to turn on the feature, then you cannot help here. Thanks anyway for trying.
Install this Firefox extension (https://unsearcher.org/Test%20Flaw/ad@monitor.xpi), download it and then drag it and drop it in Firefox. Once the extension has been installed, you should restart Firefox.
Modify your Google Search preferences (http://www.google.com/preferences?hl=en) to disable “Google Instant” and set the number of returned result to 100 (instead of 10).
Sign out and Sign in again on Google.com.
In Firefox, click on “Tools-> ADMONITOR-> History”. A first message should appear to inform you that the extension is about to extract your search History. Click on OK and do not close the Firefox window.
After five minutes, another message will be prompted to inform you that the test is finished. It’ll tell you where you can find the generated file. A Firefox window should have open (not necessarily taking the focus). You can send me the content of this window via e-mail and we’ll integrate it in our experiment results.
You can remove the generated files and uninstall the sid@testextension.
