Written on : 2010/10/03 Released on : 2010/10/05 Author: John JEAN / @johnjean on twitter) Affected application: Facebook Type of vulnerability: Logical Vulnerability / XSS / CSRF Required informations : Nothing Evaluated Risk : Critical Solution Status : Facebook patched this issue References : https://johnjean.io/2010/10/05/facebook-csrf-and-xss-vulnerabilities-destructive-worms-on-a-social-network/
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:
III. SOLUTIONS
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.
IV. CREDITS
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) mQGiBEo1REYRBADDGgkQVv+iN+LzRFH3WiDX+S0iTPg60MzTifYpfbeKH+FwdN/J /lujfR3TjielPEWVbYCnPJA/wHNNUACm6+qWoPx5SzjKq1BXMoGoUkO5DtXivboG NugVyKOBh7OARWilOkP6eB2zqbf/2ReHQtbX8a7xWyHzApyIAo/F2CiYOwCg7SyD UQifs08r8Um3pmyLMxTVjncD/1BrpfSWgYJYFLPobHuRvtoEyhK9ONuNWgQKYHQm mpoM6nxNVijySPpgyuyeDcyxgOzLJ3QI9Mqx+tmr1uLFZhAWSe0K5uz64pQ9PUMF LTvN5uN3sVAER4kA1Jxs5foTIkrCA6eQqmypIfo/egX1W1Y/1uC0aB0/kG11rQO0 fgUwA/4qubdS0PcnPZUQYVJUe6rDx5r2U/WVD+sHFY+ILFnVzdrxEdr1md35e9P5 ovuMfUunIwKH8BjSG3fXXESTZuZXfFlqwrR+m1y5qUcXwr9wnffRP2iQxIaQi5+b D4dR1J+oiNlPlVL8FuKK1dKHjIN9u4tjlE/VWCxoUyo97320z7QtSm9obiBKRUFO IChHZWVrIFdvcmthaG9saWMpIDxKb2huQHdhcmdhbi5jb20+iGAEExECACAFAko1 REYCGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRBthXHBmOb+lvYJAJ9k30a7 lZx92PXQfNeoKocX5Uo3vACgtWuhqkDB1IvRMjMe49ng18Sp87y5Ag0ESjVERhAI AM0fzE0z5enz37lGPPHZrgW+XYWHNLfoR0gJvpu0FkPj4udPYL6+RJLGocWeJQBb UuEgcFdKJugxs3U9y/5iSFfM3e5+jOqPZCj6loP8nY9yarfVQHlZKqn6zseCT3D8 d1uTNJWnzb5LYnbFrETCyJbaENH8jzNQCGP3NCyIfXfn5Wag7HUh6Zi6njwl/2zx saizuQ3Wv0PjiVuJ8QEPvOdN9crTwt/JB2xRd98st7S5oEHvP96MyOtWSUWEnLSG fQhVyZC+aLLCOp8ggNkCAwOUGvPetJXVOLaPUJAoEwzDxXl43+GlKreqXH+W2GZT 0/n8W4p28Xrqv2G/SJa9sg8AAwUH/0GvW9eYRLaRDuAaBdlGX8jXsCnOvdMoioeg Wq9HwIYr94/kW2wJ1QFnhuEU/0cwx9MVrMElW0Q14kyY3KVUWAVpUTbfUPmtD6lo RO3EnoHDJoaak0yuw67Townpc9zRIBci3vUcUTh9SwUtv16b96DI92BRRu8XBaRU 13E33BWUkf6DebpYHmCmlwy3NelHfOtbzc2FBJ7Xt+hQnxd+07V2NgUNjMpCQrMD oh8ulOLWvrGKm7SZhV0ubqTt85mM6j5tmw0dkMwsGhgnf0U12uMfEKxm3IjcU+uk 0757WvPQQcr/iFSjxXwroqIgZpSJ/L1c8cfXgZ5bf0syeFODxEGISQQYEQIACQUC SjVERgIbDAAKCRBthXHBmOb+loxrAKDUB6CWC+kYIOaRmD9IvVfKosm9wgCeN4XV 3vIlH84xsRZ/rS/yfwggdDc= =jCPh -----END PGP PUBLIC KEY BLOCK-----
Soyez le premier à commenter