Wednesday, August 19, 2009

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?

77 comments:

  1. Great article! Very informative and detailed. Thanks! It is good to have as much knowledge on Internet security as possible. It's a dangerous world out there.

    ReplyDelete
  2. My account was hacked several months ago using this very hack, and the miscreant used my account to forward porn links. Be very careful about playing around on Facebook!

    ReplyDelete
  3. nice job! I always love to read a good hack to get the day started

    ReplyDelete
  4. good stuff, very interesting. careful what information you put out there...

    ReplyDelete
  5. Awesome. I'm just assuming that this exploit must have been around for a while.

    That is incredibly elegant. There've gotta be a ton more just like it.

    ReplyDelete
  6. great discovery and a fantastic writeup. hope to see more work from you.

    ReplyDelete
  7. Wouldn't it have been easier to just 'spoof' the 'Referrer' header? In this case you would only need one app.
    Does anyone know how Facebook patched this vulnerability?

    Great article indeed!

    ReplyDelete
  8. Nice discovery :) twisted XSRF.

    ReplyDelete
  9. For this to work the user has to have accepted your "hacker-app" (or be a developer of the app in which case you don't have to accept). A dialog pops up first saying:

    Allow Access?
    Allowing "hacker-app" access will let it pull your profile information, photos, your friends' info, and other content that it requires to work.

    ReplyDelete
  10. Can you explain how a request for an image (/attacok.gif") can send a redirect? Typically, you would have .asp or .jsp file or like to redirect.

    ReplyDelete
  11. This is really NOT an exploit because you have to add the app in order for it to work. By adding an app you accept a TOC page that states the app will have this info.

    ReplyDelete
  12. To 'anonymous': Where does it say you have to have added the app? The description and video would appear to indicate that you do *not* have to do this at all.

    To inquirer: An HTTP server can respond to any request with a redirect, that's independent of what's being requested.

    ReplyDelete
  13. IT dosnt say it. Have you tried it? The video is by the developer of the app. (who automaticaly is added to the app).

    ReplyDelete
  14. Hey Ronen Z ,

    cool information. By this kind of attacks have been already been notified Its more like Phishing :-) , But still yes you have done a great Job in explaining it i appreciate it ;-)

    Regards
    Vijay

    ReplyDelete
  15. I just confirmed that you DO have to have added the app for this to work. So you have at some point already agreed to give this info to the app.

    That said the writeup is good, just wrong.

    ReplyDelete
  16. Great work! I'm curious, what specifically has Facebook changed in response to this attack?

    ReplyDelete
  17. I'm impressed but now I am extremely suspicious of all apps. Time to remove some personal info and photos. We need more info like this.

    ReplyDelete
  18. Maybe I'm missing something. The hacker can get your user name, profile picture, and friends list. So what? He does not have your password. And he is not a friend to your friends. So what can he do to you?

    ReplyDelete
  19. Don't know what to say other than "it is damn good writing".

    BTW, this forces me use a dedicated browser for FB. Wonder if it still work under incognito/private window.

    ReplyDelete
  20. Thank you for sharing that information in a detailed post!

    I have a question. You wrote "these details include..." Could you be more precise about the information that is effectively stolen and provide an exhaustive list?

    ReplyDelete
  21. Ajuaa con solo colocar el nombre de la persona tambien puedes acceder a esa informacion si la persona accede a sus datos aqui le dejo un ejemplo: BUSQUEN EN GOOGLE COOKUI MAUSTER y ahi les sale el come galleta del video lo unico diferente es que tienes que buscar a la gente si no que atraes a gente seleccionado

    ReplyDelete
  22. Interesting. This exactly the reason I have completely fake information and photos on my facebook account! ;-) bb

    ReplyDelete
  23. A few clarification:
    1. There is no need to pre-approve the app. That was in a sense the whole point of the attack. The vulnerable mechanism, aptly called Automatic Authentication, sends the app some information *before* the user approves it.

    2. Only publicly available information was disclosed. So if you set your details to private, you were safe. But as I wrote, the default option is public which means that the vast majority of users have it set just so.

    ReplyDelete
  24. This will be a pretty useful for all facebook users. I hope people can get maximum from this. Thanks for the detailed post.

    ReplyDelete
  25. I can see how you redirected from firstimage.jpg to malicious1.php but not how you managed to redirect back to a valid image.

    It seems to me that as soon as I redirect the image to a php and some html is executed, the image breaks. I tried to meta refresh from the php to a valid image, but to no avail.

    Could you elaborate on this?


    /Jonas

    PS. I'm not talking about this vulnerability but the image->csrf->image tactic in general.

    ReplyDelete
  26. Good work. Facebook acts as a proxy - and what if you place your own proxy in front of Facebook?

    Watch

    http://www.hacking-lab.com/movies/rp2/

    ReplyDelete
  27. What was the greatest hidden

    ReplyDelete
  28. I've lately been reading a lot about different vulnerabilities and I keep getting astonished how simple, yet elegant the attacks finally are. This article is no exception to that. Thanks!

    ReplyDelete
  29. Very interesting presentation of the malicious attack techniques. Makes me want to play safe and avoid social media networking sites such as Facebook, Twitter and Delicious. Are the attacks actually stoppable if those sites worked hard enough at repelling attack attempts?

    ReplyDelete
  30. Great Post!

    What exactly did Facebook do in order to resolve this issue?

    Thanks!
    Itay.

    ReplyDelete
  31. That is ingenious ... to follow up on Anonymous' question - has this hole been fixed by now? Seems even browsing with facebook still logged in poses a security risk

    ReplyDelete
  32. Sometimes I think ignorance is bliss. What an eye-opener. Thanks.

    ReplyDelete
  33. In reply to Anonymous from August 24, 2009 at 6:11 AM, the hacker gets your name, and they also know that you clicked the particular link or viewed the image that they used to trigger the attack. This means that they can link your name to some other online activity which you may have been trying to keep anonymous.

    For instance, perhaps someone blogs using a pseudonym about their work, and criticises their employer. The employer might be able to send an email with one of these links or images in it to the blog's contact address and find out what their real name is.

    I expect this issue has probably been fixed by now though.

    ReplyDelete
  34. Wholesale Lingerie, Newest Halloween Costumes And Corsets China Suppliers and Manufacturers, Plus Size Sexy Lingerie and more on walsonlingerie.com with Fast Shipping and Worldwide Delivery, Low Wholesale Prices.
    walson lingerie
    Corsets China Manufacturers
    wholesale corsets

    ReplyDelete
  35. The Vintage Wholesale Company The Vintage Wholesale Company.Walson Rockabilly are a vintage wholesale company who focus on vintage fashion wholesale. WalsonRockabilly Vintage Clothing wholesalers are the UK's leading,Shop wholesale vintage dress, cheap silk dress, vintage jewelry products from reliable vintage dress wholesalers on walsonrockabilly and get worldwide,We know wholesale vintage clothing. We're the only vintage clothing wholesaler that knows what it's like to be in your shoes,because we run stores ourselves.Always Vintage is a Wholesale Vintage Clothing Distributor. We offer more than ninety different categories of vintage clothing for you to choose from.
    Rockabilly Clothing
    Swing Dresses
    Rockabilly Dresses

    ReplyDelete
  36. I did not know that. So its a stupidity on facebook's end to put access tokens in the resource locator? hackear una cuenta de facebook

    ReplyDelete
  37. The Vintage Wholesale Company The Vintage Wholesale Company.Walson Rockabilly are a vintage wholesale company who focus on vintage fashion wholesale. WalsonRockabilly Vintage Clothing wholesalers are the UK's leading,Shop wholesale vintage dress, cheap silk dress, vintage jewelry products from reliable vintage dress wholesalers on walsonrockabilly and get worldwide,We know wholesale vintage clothing. We're the only vintage clothing wholesaler that knows what it's like to be in your shoes,because we run stores ourselves.Always Vintage is a Wholesale Vintage Clothing Distributor. We offer more than ninety different categories of vintage clothing for you to choose from.women roman costume
    halloween costumes flapper
    roman costumes for women

    ReplyDelete