Facebook CSRF and XSS vulnerabilities | Destructive worms on a social network
Posté le 5 octobre 2010
Facebook is a social networking website with the second highest number of visits worldwide, and over 500 million active users. Our team recently performed a quick security audit of the main Facebook site along with its mobile versions. Here are the full details of our findings.
I. DESCRIPTION OF THE VULNERABILITIES
Facebook comes with an anti-CSRF system based on two tokens, respectively called post_form_id and fb_dtsg. These tokens change frequently, and are certainly built upon several parameters including time of day, time of account creation, user id, and many others. Determining the values of these tokens for a specific user is, to our view, impossible.
Fortunately, Facebook provides a functionality called “profile preview”, allowing users to see how their own profile appears to any other user. It can be accessed using the URL: http://www.facebook.com/profile.php?v=wall&viewas=<viewer_id>. And this functionality has a bug. When the logged-in user allows anyone to comment on his wall (via his privacy settings), a form (at least) is given to allow users to comment on published posts. In such a case, when you fill the viewas parameter with the id of any user, the script returns – amongst other things – the post_form_id token of this very user, along with the form needed to comment on the wall. For example, setting your privacy settings adequately and going to http://www.facebook.com/profile.php?v=wall&viewas=4 will reveal the post_form_id token of Mark Zuckerberg. ;-)
This bug can also be found on the ajax feed http://www.facebook.com/ajax/stream/profile.php?__a=1&profile_id=<user_id>&viewer_id=<victim_id>.
Two drawbacks : first, you need the victim’s id to retrieve his/her post_form_id token. Then, you still need the second token fb_dtsg. The first problem is actually an easy to solve problem if you use a tiny CSRF flaw located on the mobile version m.facebook.com. Indeed, the “like” script does not require any anti-CSRF token: you can use it in a CSRF attack to retrieve the name, and thus the id, of the victim.
N.B. : when a user logs into the main site then he is logged on any mobile version as well, so everything is exploitable on the main version.
The second problem could have been a serious problem if the Facebook team had not left us with the possibility to send friend requests without the fb_dtsg token on the touch version touch.facebook.com. We consider this as a flaw since a lot can be done once you are friend with the victim.
We finish the description of the flaws with our last findings, two XSS flaws located on each mobile version of Facebook, namely m.facebook.com and touch.facebook.com. More precisely, the incriminated scripts are http://m.facebook.com/l.php?u=<external adress>&h=<hash> and http://touch.facebook.com/l_warn.php?u=<external adress>&h=<hash>, redirecting users to the provided external address. When one omits the h parameter, the script returns a warning including the external address, that is not correctly sanitized before being sent back. Here are two proof-of-concept URLs :http://m.facebook.com/l.php?u=http://ex.xss/<script>alert(‘XSS’);</script> and http://touch.facebook.com/l_warn.php?u=http://ex.xss/ »<script>alert(‘XSS’);</script>
II. IMPACT OF THE VULNERABILITIES
The impact for these flaws can be huge. We have created two different worms in order to demonstrate the potential of these vulnerabilities. These worms both spread via a Facebook application that silently loads an external malicious script. The first worm takes advantage of the CSRF flaws by successively retrieving the id and post_form_id of the victim, and sending a friend request to the attacker through the touch version of Facebook.
The attacker then accepts the request (automatically), steals all the personal info, publishes a post on the victim’s wall to ensure the spreading, and removes his friendship with the victim. To sum up, this worm silently recovers all personal info on the victim in a few seconds.
The second worm is far more destructive: it uses the XSS flaws to perform a malicious phishing attempt, taking advantage of the trusted URL apps.facebook.com to fool the victim. The victim has the choice between giving his/her email+password, and clicking on a button (« Cancel ») that launches a request that changes his/her contact email (which is possible without the user’s password on m.facebook.com), finally leading to the modification of his/her password using the “forgotten password” procedure. Once the password recovered or changed, the attacker logs into the victim’s account, steals all the personal info including private messages, sends a private message to all the victim’s friends to ensure the spreading, publishes all the private messages on the victim’s wall, make the victim’s profile visible to anyone, and finally erase all the personal data (photos, private messages, old posts).
These scenarios have been illustrated by our team on two videos, where we have simulated the propagation of these worms in a small community. Don’t hesitate to watch them :
Part I: CSRF security flaw on Facebook | How to build a silent CSRF worm:
Part II: XSS on Facebook | How to build a XSS destructive worm:
All these flaws have been reported to Facebook. All of them are now patched, except the post_form_id flaw on the preview functionality : this flaw is no longer useful since Facebook removed the possibility to send friend requests without the fb_dtsg token on touch.facebook.com.
These vulnerabilities have been discovered by John Jean for Wargan Solutions.
Original advisory: http://www.wargan.com/facebook-multiple-vulnerabilities-051010.php
Follow me on twitter @johnjean
We accept no responsibility for any damage caused by the use or misuse of this information.
Special thanks to Alex Rice (Facebook Security Team) for his kindness and responsiveness.
—–BEGIN PGP PUBLIC KEY BLOCK—–
Version: GnuPG v1.4.9 (GNU/Linux)
—–END PGP PUBLIC KEY BLOCK—–