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