Skip to content

Facebook: Vers XSS/CSRF sur le réseau social

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-vulnerabilites-csrf-et-xss-ver-destructeurs-sur-un-reseau-social/


Facebook est un réseau social de plus de 500 millions de membres, c’est également le second site le plus visité au monde derrière Google (qu’il vient de dépasser en terme de visites aux USA). Notre équipe a récemment effectué un rapide audit de sécurité de Facebook afin d’établir si oui ou non les données de ses utilisateurs y étaient en danger. Nous nous sommes cantonnés à l’essentiel et ce fut largement suffisant. Voici les détails complets de nos trouvailles.

I. DESCRIPTION DES VULNÉRABILITÉS

Facebook utilise un système anti-CSRF basé sur deux jetons respectivement nommés post_form_id et fb_dtsg. Ces jetons change fréquemment, et sont certainement construit à partir de paramètres aussi divers que la date du jour, l’heure de création du compte, l’id de l’utilisateur, et sûrement beaucoup d’autres. Déterminer les valeurs de ces jetons pour un utilisateur précis est, à notre avis, chose impossible.

Heureusement, Facebook offre une fonctionnalité épatante appelée “pré-visualiser mon profil”, permettant aux utilisateurs de voir comment leur propre profil apparaît aux yeux de n’importe quel autre utilisateur. On peut y accéder via l’url http://www.facebook.com/profile.php?v=wall&viewas=<viewer_id>. Mais cette fonctionnalité possède un bug. Lorsque l’utilisateur courant a autorisé (via ses paramètres de sécurité) les autres utilisateurs à publier sur son mur, un formulaire est présent à côté de chaque post afin de poster des commentaires. Dans ce cas précis, lorsque l’on renseigne le paramètre viewas avec l’id d’un utilisateur lambda, le script retourne, entre autres choses, le jeton post_form_id de cet utilisateur avec le formulaire nécessaire pour publier des commentaires. Par exemple, lorsque l’on autorise quiconque à publier sur son mur et que l’on se rend sur http://www.facebook.com/profile.php?v=wall&viewas=4, on obtient en cadeau le jeton post_form_id de Mark Zuckerberg. 😉 Ce bug se situe également au niveau du fil de news http://www.facebook.com/ajax/stream/profile.php?__a=1&profile_id=<user_id>&viewer_id=<victim_id>.

Il y a néanmoins deux inconvénients majeurs : premièrement, on a besoin de l’id de la victime pour récupérer son jeton post_form_id. Ensuite, cela ne résout pas le problème du second jeton anti-CSRF fb_dtsg, qui ne peut pas être récupéré de cette manière. En ce qui concerne le premier problème, il est assez facile à résoudre si l’on utilise une minuscule faille CSRF située sur la version mobile de Facebook m.facebook.com. En effet, le script like.php, lié à l’action “j’aime” si chère à nos amis Facebookers, ne requière aucun jeton anti-CSRF : on peut ainsi l’utiliser lors d’une attaque CSRF afin de récupérer le nom et l’id de la victime. A noter : lorsqu’un utilisateur est loggé sur le site principal, il est également loggé sur les versions mobiles m.facebook.com et touch.facebook.com.

Le second problème aurait pu être plus épineux à résoudre si l’équipe Facebook ne nous avait pas laissé la possibilité d’envoyer des demandes d’ajout à la liste d’amis sans le jeton fb_dtsg sur la version tactile touch.facebook.com. Et beaucoup de choses peuvent être faites une fois ami avec la victime!

Terminons cette description avec notre ultime trouvaille, deux jolies failles XSS situées sur chaque version mobile de Facebook, autrement dit m.facebook.com et touch.facebook.com. Plus précisément, les scripts incriminés sont http://m.facebook.com/l.php?u=<external adress>&h=<hash> et http://touch.facebook.com/l_warn.php?u=<external adress>&h=<hash>, chargés de rediriger l’utilisateur vers une adresse externe fournie en paramètre. Lorsque l’on omet le paramètre h, le script retourne un message d’avertissement incluant cette adresse externe, mais sans que celle-ci ait été correctement filtrée au préalable. Voici deux exemples d’injection : http://m.facebook.com/l.php?u=http://ex.xss/<script>alert(‘XSS’);</script> et http://touch.facebook.com/l_warn.php?u=http://ex.xss/ »<script>alert(‘XSS’);</script>

II. IMPACT DES VULNÉRABILITÉS

L’impact de ces failles de sécurité peut être énorme. Nous avons créé deux worms différents afin de démontrer le potentiel de ces failles. Ces worms se propagent tous deux via une application Facebook qui charge silencieusement un script externe malicieux. Le premier worm tire partie des failles CSRF afin successivement de récupérer l’id puis le post_form_id de la victime, et enfin d’envoyer une demande d’ajout à la liste d’amis à l’attaquant via touch.facebook.com. L’attaquant accepte ensuite la requête, récupère toutes les informations personnelles de la victime, publie un message sur le mur de celle-ci afin d’assurer la propagation du worm, puis détruit le lien d’amitié avec la victime. Au final, ce worm récupère silencieusement toutes les informations personnelles de la victime.

Le second worm est quant à lui nettement plus destructeur : il utilise les failles XSS afin de lancer une tentative de phishing, basée sur la confiance que l’utilisateur a en l’url apps.facebook.com des applications Facebook. La victime a le choix entre renseigner son email et son mot de passe, et cliquer sur un bouton qui lance une requête de modification de l’adresse email de contact (ce qui est possible sans le mot de passe de l’utilisateur sur m.facebook.com). Une fois l’adresse email de contact modifiée, le mot de passe du compte de la victime est changé via la procédure “mot de passe oublié”. Dans les deux cas, l’attaquant se retrouve en possession d’un mot de passe valide lui permettant successivement de se logger sur le compte de la victime, de voler toutes les données personnelles, messages privés inclus, d’envoyer un message privé à tous les amis de la victime afin d’assurer la propagation du worm, de publier tous les messages privés sur le mur de la victime, de rendre le profil visible à tous les utilisateurs, puis enfin d’effacer toutes les données personnelles (photos, messages privés, vieux messages du mur).

Ces scénarios ont été illustrés dans deux vidéos élaborées par notre équipe, où nous avons simulé la propagation de ces worms sur une communauté-test restreinte. N’hésitez pas à les regarder :

III. SOLUTIONS

Facebook a été averti des failles de sécurités ici décrites. Celles-ci ont toutes été corrigées, à l’exception de la vulnérabilité liée à la récupération du jeton post_form_id : cette faille n’est désormais plus exploitable car Facebook a supprimé la possibilité d’envoyer des demandes d’ajout à la liste d’amis sans le jeton fb_dtsg sur touch.facebook.com.

IV. CREDITS

Ces vulnérabilités ont été découvertes par John Jean pour Wargan Solutions.
Suivez-moi sur twitter @johnjean

Contacter John JEAN (john at wargan dot com)
Nous dégageons toute responsabilité quant aux éventuelles utilisations délictueuses de ces informations.

-----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-----
Published inCVE-advisories

7 Comments

  1. David David

    Bonjour et merci pour cette article clair 🙂

    Il y a en ce moment une page nommée « Elle est enceinte à 5 ans et demi, regardez c’est hallucinant ! o_O » qui utilise une faille « like ».

    Hier, il y avait 600.000 victimes, aujourd’hui ça a doublé. Selon vous, la faille utilisée a-t-elle accès aux données « personelles » ?

    • John JEAN John JEAN

      Bonjour,

      sans connaitre la vulnérabilité c’est dur de répondre 😉
      Et je n’ai malheureusement pas trop le temps de gratter en ce moment !
      Je vous tiens au courant si j’ai le temps d’investiguer.

  2. David David

    Rebonjour,

    j’ai du coup gratté, et meme si la propagation est incroyable, l’impact est moindre puisque leur technique ne permet « que » de partager et « liker », leur but ici est d’amener à un lien au final, du spam en somme.

    La technique utilisée n’est pas une faille en soit mais une technique de fishing qui joue avec les z-index et la transparence des frames.

    ils incluent leur propre frame où il faut cliquer sur des coulers, mais mettent par dessus et en transparent d’autres frames likebox et sharer de facebook, ce qui fait que l’on clic en réalité sur celles-ci.

  3. HoLbLiN HoLbLiN

    Article parfait et clair, rien à redire !

    Bravo pour l’explication et la découverte des failles !

  4. overdose overdose

    Sympa, moi je me demander si y’avait des vulns lier a leur traducteur php -> c , mais j’ai + penser au csrf au départ. en fait je penser au film « the social network » et dedans il dénonce la vuln des sites du campus de laisser l’accès au page des étudiants devinable facilement genre photo.php?id=78, en incrémentant l’id. Le truc c’est que sur son propre site y’a le même genre de faille: http://www.facebook.com/#!/profile.php?id=133713371337 🙂

    Je pense qu’on peut être un bon attaquant, mais un mauvais défenseur.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *