Cross Site Identification - or - How your social network might expose you when you least expect it

Overview 

This post outlines a new attack technique in which publicly available information from social network sites, obtained out of context, can be used to identify a user, in cases where anonymity is taken for granted.



This paper is a generalization of a vulnerability in Facebook I described in the post: Facebook CSRF attack - Full Disclosure.


With the rise in popularity of social network  websites (SNs), people have grown accustomed to feeding these information-hungry sites with their personal details. However, most people maintain the idea that while doing so, their anonymity is kept intact when interacting with other, non-related sites. While this notion is reasonable, it is not always true, as will be demonstrated.

In this attack (dubbed Cross-Site Identification or CSID), one site, usually a SN, effectively becomes an identifying service that is used while the user is surfing, supposedly anonymously, in another site. I will call these sites the identifying and target sites, respectively.

When the user arrives at the targeted site the attack takes place:
The targeted site will silently cause the victim's browser to request the SN to share the user's personal details with the hacker. These details might be publicly available (i.e on the user's public profile), but their acquisition at this point, outside of the normal context of the SN causes the user's anonymity to be breaches and her identity known in the context of the targeting site.


The working assumption scenario for this attack is that the user is logged on to her favorite SN, and later, in a new tab, directs her browser to the targeted site. There is no connection between the two surfing sessions in the user experience, and therefor she expects to remain anonymous: If Betty has her Facebook open in one tab, she still expects to remain anonymous reading about, say, plastic surgery in another tab.



Actually, her SN website does not even need to be actually open: if she has not explicitly logged-off from it in her last visit, and chose a 'remember me' option when logging on, then her cookies are still valid. She is still authenticated and thus still vulnerable.

How it works

I've found the described vulnerability in Facebook a few months ago and wrote an extensive post about it here. It contains a detailed description of the attack technique and specifics of the Facebook attack, and might provide an interesting addendum to this post, especially if you want to see all the nuts and bolts put together.

For this reason, I won't go into the details here again, but I'll give a brief description of the general attack scenario: The identifying site, usually a SN, is forced to reveal identifying attributes about the user. This is usually done though a SN application (though not necessarily). The SN API either reveals this data by design, or can be tricked to do so. The data is the publicly available information (like name and profile picture) that is available to anyone viewing the user's profile anyway, so it seems like there is no problem. The problem arises when this process can be initiated without the user's consent, while she is visiting a completely non-related site (the target site). When the user visits the target site, her browser is made to visit the identifying site and trigger the payload (I.E visit the attacker's SN application page clandestinely, providing him with the user's identifying attributes).



The attack has two main use cases in relation to the target site.

1. The target site is controlled by the attacker. This is a malicious site owner wishing to uncover his visitor's identity, or a hacker will content placement control in another site.
   This is the simpler, less powerful version of the attack. The attacker can use any means necessary to initiating the attack (such as iframes, javascript etc).
   
   
2. The target site is a legitimate 3rd party site in which the attacker has no special privileges. This is a much more powerful version because the attacker, while being a normal user in the site, piggy-backs on the target site's reputation: The victim has no reason to suspect the target site, which could be very well known.
   
   Obviously, the hacker still needs some kind of hook to initiate the attack. In this case it is an embedded image link put in the target site that causes the effect. The image link eventually point the browser at the identifying site and triggers the payload. This can most commonly be carried out in the form of a comment on a forum or blog. An image can usually be added as part of the comment, or as the avatar picture. Another option is via an advertisement image set by the attacker legitimately in the target site.
   
   A different approach is in the form of HTML email's containing the rouge image link. In this scenario, the attacker is alerted when the victim opens his email box.
   
   As a last touch of grace, it is usually possible for the malicious image link to initiate the attack and return a valid image to the victim's browser causing no suspicious behavior resulting in the entire attack going unnoticed.
   
   

In my previous post, I dubbed the vulnerability in Facebook "CSRF personal information leakage vulnerability" but some thought and conversation (thanks A.D!) showed that it is neither a CSRF per se, nor a leakage of information. It's not exactly a CSRF because the victim's browser isn't tricked into performing any action apart from visiting a page (a CSRF token won't help here), and it's not exactly leakage because the information is publicly available! Its the out-of-context access to it that constitutes the attack. Furthermore, the vulnerability in the identifying sites found seems very minuscule (sometimes it is a feature!) when not considering this attack, so it is logical to assume that many other instances of it are in the wild. For these reasons I realized it's a new attack technique in its own right, and that was what motivated me to write this post. I suggest the name Cross-Site Identification (CSID).



Real world examples

Ah, the juicy bits.

As stated I've posted about the specific Facebook attack a few moths ago. While doing some (shallow) research, I found two other instances of the same vulnerability in Bebo and Orkut, which are reported here for the first time. By the way, these are the only three sites I've inspected so far, so I suspect there are many more open cases.


Facebook

I'll represent the video demonstration I made showing the effects of the attack on Facebook. The details are here. The vulnerability has been patched by Facebook after being informed about it, a few months ago.

Bebo
Bebo apparently uses a clone of Facebook's application platform. However, it was even easier to exploit for the purpose of this attack than Facebook was, as the identity of the user is given to the unauthorized application with little tweaking.

In Bebo, the default privacy settings is "Profile viewable by my friends only" which is good. However, even in this settings, the user's full name and profile picture are publicly visible.
The described vulnerability has been reported to Bebo, but is currently still open.

Attack walk-through:

1. Our victim, Henry Eight is logged to his Bebo account while surfing to the target site.
   
   
2. The malicious image embedded in the target site directs his browser to the attacker's newly created application. It performs two actions: Logs the parameters added by Bebo's server making the request, and redirects the victim's browser, currently looking for pixels, to a valid image.
   
   
3. Here is the logged information received by the attacker:
   
   

Note the victim's Bebo id given twice in fb_sig_profile_id, and in fb_sig_user.
4. The publicly available information Bebo gives out for this user ID can be fetched through its API, but for the sake of clarity, the following screen shot is the public profile for this user.
   
   

The profile picture and full name are given even though the user's privacy settings are intact.

Orkut
Orkut's applications framework is an implementation of the open source OpenSocial platform. A shallow investigation showed the site vulnerable twice. Both vulnerabilities are design flaws, one specific to Orkut, and the other in the OpenSocial specifications.
Both issues have been reported but are currently still open.


1) Recent Visitors

Orkut has implemented a feature called Recent Visitors turned on by default, that shows an Orkut user the last 10 people to have viewed his profile, with a link to their profile.

In order to use this feature to launch the described attack, the attacker sends the unsuspecting victim to his Orkut profile page using, for example, a hidden iframe (if it's his own site). Note that an image link can be used as before although the image will break.
Orkut does the rest by providing the attacker with the names and profiles of the victims.

As stated this vulnerability is a built-in feature in Orkut, turned on by default.


2) Signed Requests

Orkut, abiding by the OpenSocial specifications seems to keep from providing any information about the user of an application before it is approved. However, creating an application page with the Signed Request feature, has the effect of adding the OpenSocial ID of the viewing user to the request made to the application server.
The following screen shot is the request made by Orkut to the application server when the victim is forced to "view" the attackers application.

Note on the bottom, the proper response of the server to the application's request for personal information about the viewer: It is denied on grounds of permission, rightfully so, as the application has not yet been approved by the user.
However, note the added opensocial_viewer_id parameter. It is part of the parameters added when a signed request is performed. This parameter is, as its name suggests, the unique id number of the victim.

A user's opensocial id number is different from her Orkut id, therefor viewing the user's Orkut profile (like in the Bebo example) is not immediately possible. Perhaps it is possible to derive one from the other, or identify the user from this number in another way, but it's more important to note that this is already a vulnerability, even if somewhat to a lesser degree:

The opensocial_viewer_id parameter can effectively act as a cross-domain tracking cookie, allowing the attacker to track the victim across different target sites. Although the victim's identity remains unknown, his actions on unrelated sites can be aggregated using this technique.

This vulnerability is also a design flaw in the OpenSocial specifications.

Combined Attack Vectors


Apart from the pure form of the technique detailed above, different attack vectors that leverage other factors are possible. In the attacks illustrated below, the identifying information is not publicly available immediately, but is obtained through other means.

Leveraging trust
In most of the examples above, the user was tricked into interacting with a malicious SN application set forth by the attacker. The main difficulty (= the security vulnerability) was "convincing" the SN to play along without the victim's acknowledgment (= approving the application).
But what about a legitimate application?


When a user approves an application he explicitly allows it access to his personal information. But the app can abuse these rights by providing these details out of context as described, to identify the user.
The attacker can create a legitimate application, have users approve it for its legitimate front, and later use it to identify its users elsewhere. Another option is to use a vulnerability (such as an XSS) in an already popular application for this purpose: The victim's browser is directed to the vulnerable popular application, the SN identifies the user to the application (as it should, it had been approved!), but the hole in the application causes the identity to be transmitted to the attacker.

Leveraging an XSS
Imagine a library site which, after you logging in, shows your name and your lent books. Imagine further that the site contains an XSS. While not being very lucrative for an attacker in itself, it can be used to launch described CSID attack:
When the victim visits the target site, the malicious image link redirects to the library site with an XSS payload that snips the victim's name from the top of the page and sends it to the attacker (using an image request with parameters, for example).

Similarly, an XSS in any SN or SN application, or for that matter any site that identifies its users could be used to launch this attack. Think web-mails, game sites, shopping sites, forums, IMs, eCards... Any one of them, however benign, could serve as an identification service for its users while they are surfing other sites anonymously.

Leveraging a CSRF
Consider a site that publicly displays a user's identity in relation to an action he has taken. There are many such sites, for example: Wikipedia (history page), Flickr (comments), Yahoo Answers (questions and answers). Even Blogger.com (followers). The user is aware of the implications of his action (having his identity shown), and is actively choosing to do so.

But what if there is a CSRF vulnerability in the site?
In this case, a user that is logged-on can be forced to perform an action using a redirection from another location. In many cases the action itself might seem uninteresting enough (to a potential attacker), that CSRF protection is not implemented. However, a CSID attack can be launched exploiting this weakness.

Lets take for example Flickr comments. Imagine that adding a comment to a photo was not CSRF protected (which it is), meaning that it is possible to post a comment on behalf of a user without the user's knowledge. To perform the CSID attack, the attacker would post an image link on the target site that causes the victim's browser to comment some obscure photograph chosen by the attacker. When the victim (which is logged on to Flickr) views the target site he unintentionally posts a comment which is displayed along with his Flickr name under the photo. The attacker then simply views the Flickr page of the chosen photo, to collect the identity of the victim.

Note that I am not reporting the above listed sites as vulnerable, only providing them as potential examples. However I have found a few similar sites to be vulnerable in this way. I'll write an additional entry about this after allowing enough time for the sites' team to repair the problems.

Discussion and Summary

This new attack technique shakes the already loose foundations of anonymity while surfing the internet.
A user's identity is at risk of being exposed while visiting almost any site, or even reading emails. While the average user might be some what attentive when visiting questionable sites, she does not at all fear using legitimate, well known sites, which are just as vulnerably.

The severity of this attack is increased by the fact that with the introduction of tabbed browsing in all modern browsers, multitask browsing has become common practice. Most of us will have our Facebook or webmail page open in one tab while surfing the web in others. Doing so makes us potentially vulnerable to this attack. Also, it has become common to offer a "Keep me logged on" option, which causes the user's browser to remain authenticated even when the application window is not actively open.

Furthermore, the attack trigger can easily be rendered benign by the attacker at any point, completely removing any trace the attack took place. This can be done even in 3rd party sites not controlled by attacker. This is because the trigger is an image link pointing to the attacker's server. When the attack is "live", the server will redirect the request onto the vulnerable identifying site. To kill the attack, the attacker merely has to return a valid image instead. No traces are left.

Even further, in most of the above examples the image request remains in the hands of the attacker, even after the payload has occurred. This is true even in the case of failed identification (I.E the user was not logged in). This allows the image link to get a valid image in the end. It also allows cascading the attack to multiple locations:

The victim's browser, while trying to fetch an image embedded in a reputable site, will start hopping between social network (and other) sites one by one, triggering the disclosure of the victim's identity from some (the ones he is logged on to), silently skipping the others (where he is not), and ending up with a valid image to show on screen. All without the victim's awareness.



The real world examples shown here are the result of only a quick research. Further research will probably find many other popular sites susceptible to this attack, and more examples in the reported sites. This is apparent as some of the vulnerabilities found were design flaws indicating that the use-case of this attack had not occurred to the writers of the specifications.



How this attack differs from CSRF (addendum)
This question has been raised a few times and I would like to address it here.
While the two are similar, I feel they are not the same. CSRF by OWASP definition is "...an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated." In contrast, the exploits described in the paper require the end user to merely *view* a page on the vulnerable website. No action is taking place.

An action in my mind, is a two-step process: First the user requests the pre-action page, which contains the action button (and usually a form). The click on the button preforms the action and sends the user to the post-action page. CSRF is thus a way to skip the pre-action page, and send the user directly to the post-action page. (Via an email link, hidden iframe, image etc).

CSRF prevention is done with CSRF tokens: unique "challenge" tokens that are added as hidden values to the form in the pre-action page. When the form is submitted, the token is verified. Because the token's value is unknown in advance, construction of a malicious, direct post-action URL is not possible. While this method stops CSRF, it will not help with CSID.

Consider for example Orkut's "Recently Visited" feature. How would you use CSRF tokens (or anything else for that matter) to prevent it being used for CSID (i.e clandestinely sending the victim's browser to visit the attacker's profile), and still retain the current functionality (allowing direct URL to users' profiles, and counting profile views as visits)?

Similarly, If the social platform wants to allow direct URL access to it's applications, and adds the user's details to any request, you have a problem which, in my opinion, is not CSRF, and not fixable with anti-CSRF measures.

CSID and CSRF are similar in the fact they are both instances of the Confused Deputy problem: The browser is not sure if its really the user that is requesting it to go to some URL, or if it's a trick. This is a very broad issue touching the essence of WWW internet and not simple to settle. Google Analytics in a website is an example of the this as a feature rather than a security bug: The user's browser is hiddenly sent to another domain (Google) in order to perform an action (accumulating statistics for the site owner). Does the user want this action to take place? He is certainly not aware of it, nor has the option to prevent it. But we would not consider this to be CSRF even though it might meet the technical criteria. Clickjacking is another example in this family of attacks. But it is better seen as its own type of attack rather than more of the same. It is of course possible to see all these as one type of attack (or feature) but I feel something is lost in the generalization.


Writing these lines I see that CSID has two meanings. One is CSID as a payload: The disclosed of identifying details about a user out of context. The other is CSID as the vulnerability that allows this.
The CSID payload can be launched using existing vulnerabilities like XSS and even CSRF as described above. But in other cases it is its own vulnerability, such as Orkut's design flaws, and Facebook's
and Bebo's leniency in adding user information to requests.



If you reached this far, why don't you leave a comment?

Facebook CSRF attack - Full Disclosure

This post is the technical full disclosure of the exploit I reported here. The original post includes a demo video and a description of the attack. Please view it first as it is not redescribed here.
I intended this post to be understandable by anyone with a modest understanding of how the web works, not just security experts. So give it a try.


Update: I wrote a follow-up white paper describing this attack in a more general way, and providing more examples from other Social Network sites. The paper is dubbed: Cross Site Identification - or - How your social network might expose you when you least expect it



I'll begin with an outline of how a Facebook application works. Then I'll explain the vulnerability (that's the security hole), and finally, I'll detail the demonstrated exploit (that's what you can actually do with the hole).


How a Facebook App works
Anyone can create an application (or app) that will run within the Facebook platform (and many do!). An app is like a regular website with the additional benefits of the social network Facebook provides (such as friends, profiles boxes, walls etc).
Technically, a Facebook app is just like a website: its mounted on a normal web sever and serves content to HTTP requests. The difference is that while a normal website receives requests directly from its users, an app has the Facebook platform as a middle man, between the user and the application.


Click image to enlarge

Figure 1. A Facebook application architecture vs. a normal web sever.

In a regular web site, the user's browsers requests the web content directly from the web server. In contrast, a Facebook application has a "front" address in the apps.facebook.com domain. The user accesses this address and Facebook itself contacts the app server for the content through its real address back.quaji.com.

What Facebook tells the application about the user
Referring to Figure 1, When the user engages the application (arrow 1), Facebook will add some of the user's personal information when contacting the app server (arrow 2), so the response (arrow 3) could be personalized. What details exactly it sends along depends on many variables, most notabely if the user has authorized the app.

However, Facebook has a module called Automatic Authentication (which sounds like trouble just by its name...). This mechanism allows the app to receive some of the user's info automatically, without the user's consent. These details include full name, profile picture, and friends list.

This, as the saying goes, is a feature not a bug. Its a blaring example of the lenient security model Facebook adopted in the name of functionality, or in their own words: "to develop fully-featured social applications with the least possible amount of friction."
this means any application you access, even before you authorize it, knows quite a lot about you.
But at least you initiated the interaction, right?

The Vulnerability
In the role of the hacker, what we want is to set up an app, have the user's browser access it without his knowledge, and get all the personal information Facebook's Automatic Authentication so graciously gives us.
Facebook for their part try to take precautions against just this type of attack. The docs state:

"This parameter (the user ID) will not always appear. If the user has set stronger privacy settings or is redirected from a non-Facebook URL, this parameter will return null."

Now, 99% of the users do not change their default settings, so the first limitation is not a
problem. But the second is something that requires "fixing". It means that only if you actually engage the application by clicking a link to it (maybe on somebody's wall) will the personal info be sent. We need a way to trick Facebook into think the app page it is clandestinitly accessing, is a result of the user's interaction.

The core of the matter
It turns out that a simple redirect from one page to another in the same application, fools Facebook because the second request originates from a Facebook URL (the first request). Therefore, the second request activates Automatic Authentication and personal info is sent.
To illustrate this imagine the following scenario:

• Browser is directed to http://apps.facebook.com/hacker-app/step1.php
  Facebook correctly notices that the URL did not originate from with the Facebook domain, and no information is sent. However, step1.php causes a redirect to step2.php.
• Browser is directed to http://apps.facebook.com/hacker-app/step2.php
  This time, the access seems to have originated from the Facebook domain! Specifically from step1.php. Therefore, personal information is sent along with the request.

Voila.
We have managed to bypass the restriction set forth by AA. But what can we do with this?


The Exploit
Ah, the interesting part. :)
The simplest way to expoit this is by luring the innocent user to a page on our website (say by sending a link in the mail). In this page we can cause the user's browser to access any URL (using a hidden IFRAME for example). Specifically we'll send the user to: http://apps.facebook.com/hacker-app/step1.php.
This will cause the browser to then go to step2.php and we get the info.

However there is a much more powerful attack possible here (thanks S.B).
We can craft the entire thing in an IMG tag. An IMG tag also causes the browser to go the specified address looking for image data. And if the the browser recieves a redirect response, it relentlesly goes through it looking for those pixels.
The huge difference between the two approches is that many blogs/forum sites allow user comments to contain IMG tags, and therfore the attack can be launched without having the user visit our website. Instead, merely viewing a "treated" forum thread will cause the attack to take place.

The icing on the cake
Hacking is an elegant art. As such, an exploit is messured by its finishing touches, as much as its payload. While having an IMG tag point to http://apps.facebook.com/hacker-app/step1.php will work, it is suspicious, and the user ends up with a broken image. So we add:

• IMG tag point to a normal looking URL such as http://quaji.com/attack.gif. However, becuase the address resides on our server, this URL does not return an image but rather a redirect to http://apps.facebook.com/hacker-app/step1.php.
  This allows to stop the attack at anytime without leaving a trace by causing this URL to return a normal image instead of a redirect.
• The second app page, step2.php, after collecting the user's information, can further redirect the user's browser to an actual normal image. Facebook allows this, and a redirect from an application page to an external address goes unaltered. This causes the browser to finally find pixels and display an image to the user. The user will notice nothing, as the end behaviour is complete normal.
• Nothing breaks even if the user is not currently logged on to Facebook! Facebook allows access to its applications without login. Obviously, no personal data would be collected at step2.php but the browser would still end up with a valid image.
  

Lets see this all put together:

Click image to enlarge


Figure 2. The anatomy of the full fledged attack

1. User naively surfs to a well-known and trusted forum at forum.com.
2. The thread he is viewing contains a malicious comment with an IMG tag point at quaji.com
3. The user's browsers attempts to retrieve the image
4. but instead is redirected to http://apps.facebook.com/hacker-app/step1.php.
5. The request is forwarded through the Facebook platform,
6. to the hackers app server
7. and is again redirected to http://apps.facebook.com/hacker-app/step2.php.
8. and back to the browser.
9. Browser attempts http://apps.facebook.com/hacker-app/step2.php
10. The Facebook platform passes the request to the hacker's app server adding the user's personal information after being tricked into thinking it should do so.
11. To finish off, a redirect is issused to a proper image.

Aftermath
This is special type of CSRF attack in which the hacker not only causes an action on behalf of the user, he is also at the recieving end, obtaining the stolen information.
The attack in its final form is very powerful and it was surprising even to me. While the specific vulnerability in this case was a glitch in the Automatic Authentication process, the rest of the attack is based on the normal behaviour of web browsers and servers.

Update: I wrote a follow-up white paper describing this attack in a more general way, and providing more examples from other Social Network sites. The paper is dubbed: Cross Site Identification - or - How your social network might expose you when you least expect it




Hey, if you reached this far, why don't you leave a comment?

Facebook personal info leak vulnerability- or - How your identity can be compromised just by reading forum posts.

Update: The issue has now been resolved. I've written a full disclosure, but you should read this post first in order to follow it.

I've stumbled across a small security vulnerability in Facebook that, after some thought, turned out to be a way to launch a powerful and surprising attack.
The attack allows personal information including full name, profile picture, and friends list to leak to an eagerly awaiting hacker. The uniqueness of this attack, is that the unaware user's data may be stolen when she is surfing a legitimate, trusted site, not a site controlled by the attacker.

As a video is worth a thousand words, I've made one to show the proposed hack.
The video contains no artificial ingredients behind the scenes. It is completely “live” and was edited only for brevity.

What did I just see?
By merely viewing a forum page containing the rouge image, a user's personal information (full name, profile picture, and friends list) can be obtained by a hacker. It is not the image itself that does the trick. Instead, when the browser fetches the image, a chain-reaction starts that delivers these details to the hacker. The chain reaction ends with a valid image, which means that the unknowing user would not have a clue that anything out of the ordinary just happened.
In addition, note that a user's details are also at risk when one of his friends falls victim to this attack.

What can this be used for?
First off, it means your surfing anonymity is breached.
Any site you visit might contain the attacking image, and your identity is subsequently uncovered. Obviously, a malicious site owner may place the image in his site with the intention of launching the attack, but, as shown this is not the only case. In many sites such as forums and blogs, any passing user may be able to post the attacking image, via a comment for example, and steal the user's data as demonstrated in the video.
Imagine that someone could link your name and picture to all the web sites you visit, forums you read, and blogs you follow...
Furthermore, combined with another vulnerability that discovers your email address (any XSS will do) and you get spammer's paradise: A self-creating mailing list of people that are interested in any specific topic, by attacking relevant forums or web sites.

How does it work?
This hack only works if the user is logged on to Facebook during the attack. However, it is very common for users to have their Facebook page permanently open while doing other things. This, together with the vast amount of Facebook users, makes this attack a serious threat.
In the professional jargon, it falls under the category of CSRF attacks, which are very interesting and somewhat unintuitive. In a CSRF attack Evil Joe manages to trick your computer into performing actions on your behalf, without your knowledge or consent. Unlike classic attacks in which the hacker “breaks into” some computer to do his deed. While the potential damage of CSRF attacks is very severe, they are not generally well known by both users and web developers. Creating web sites that are not susceptible to them is tricky and requires special attention.
I've notified the Facebook security team about this issue, and it should hopefully be resolved soon.

Summary
From a technical point of view, I think this exploit is elegant and surprisingly powerful. So, I'll be sharing the details in a full disclosure, as soon as the threat is removed. If you're interested, check back soon, or follow.
In the meantime, I think that the mere existence of this attack should be an eye-opener to the surprising dangers lurking on the Web. It definitely was for me.

About this blog

I enjoy ideas that are counter-intuitive and surprising, because they are a good reminder that my firm grasp of "how things really are" shouldn't be as firm. As such, unique attacks in computer security are compelling, especially when they feel like an acrobatic maneuver in a tight space.

I work as a freelance security consultant, pen-tester, and developer.


Ronen Zilberman

Feel free to contact me at: ronen (a) quaji.com