Out of context information disclosure - or - the illusion of Internet anonymity

Overview 

This post will outline an 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.



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, 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.

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, she is still authenticated and thus still vulnerable.


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.


The attack has two main use cases:

1. The targeted site is controlled by the attacker.
   This is a malicious site owner wishing to uncover his visitor's identity.
   
   
2. The targeted site is a legitimate 3rd party site in which the attacker has no special control.
   In this case, the attacker embeds an image link into the site that triggers the attack when fetched by the victim's browser. This can most commonly be carried out in the form of a comment on a forum or blog, but can also be done in other ways. One example is via an advertisement image set by the attacker legitimately.
   It is usually possible for the malicious image link to initiate the attack and return a valid image to the victim's browser causing the entire attack to go unnoticed.

Real world examples



Ah, the juicy bits.


I've first encountered and described this attack technique here, related to a vulnerability in Facebook a few months ago.
Doing some quick research for this post, I uncovered two other vulnerable sites: Bebo and Orkut. By the way, these are the only three sites I've inspected so far.
 
Facebook
I wrote an extensive post on this Facebook vulnerability here. It contains a detailed description of the attack technique and specifics of the Facebook attack.
I dubbed it "CSRF personal information leakage vulnerability" but giving it some more thought I saw that it is neither a CSRF nor a leakage of information. It's not exactly a CSRF because the victim's browser isn't tricked into performing any action (a CSRF token won't help here), and it's not leakage because the information is publicly available! Its the out-of-context access to it that's constitutes the attack. I felt that its a new attack technique in its own right, and that what motivated me to write this post.

I'll bring here again the video demonstration I made showing the effects of the attack on Facebook.

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: Log 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:
   
   

As you can see, the victim's Bebo id is 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 internal 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 its 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 seem 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 a design flaw in the OpenSocial specifications.

Further Attack Vectors


Apart from the pure form of the attack detailed above, different vectors, that leverage other factors, are possible. In both the vectors below, the identifying information is not publicly available, 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 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 the described 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.

Similarly, an XSS in any SN or SN application, or for that matter any site that identifies its user's 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 identity service for it's users while they are surfing other sites anonymously.






Discussion and Summary

This new attack technique shakes the already loose foundations of anonymity on the internet. 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. 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.


The various flavors of attack can be categorized according to a few parameters. 

Target site

The target site can be a site controlled by the attacker, (a malicious site owner), or could be any 3rd party site that allows placement some outward pointing content (usually an image). This could be a comment in a forum site, a post in a blog, or even an ad image in any site.

The image link usually returns a valid image after triggering the attack, and may do so even if the identification is unsuccessful (user is not logged on). This means that such attacks can be cascaded.Thus one image link on the target site may attempt to exploit different identifying sites one after the other until successful, and still return a real image to the unsuspecting victim.

Identifying Site
The identifying site is usually a SN site that allows the creating of 3rd party applications and can be tricked (sometimes not even that) to disclose the user identity to the rouge application. Combined with another vulnerability such as an XSS, any site that has a log on feature can be used. Vulnerabilities in popular SN applications might also be used.

Information disclosed
Usually, the information is the publicly available information the identifying site shows about a user. In a minor case, no specific information is disclosed, but a permanent ID is given by the site. This can be used as a cross-site tracking "cookie".