Facebook: Vers XSS/CSRF sur le réseau 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.

Partagez cet article !

    7 thoughts on “Facebook: Vers XSS/CSRF sur le réseau social

    1. David dit :

      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” ?

    2. John JEAN dit :

      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.

    3. David dit :

      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.

    4. HoLbLiN dit :

      Article parfait et clair, rien à redire !

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

    5. overdose dit :

      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.

    6. overdose dit :

      LOL je repost y’a pire http://www.facebook.com/album.php?profile=1&id=133713371337 fonctionne alors que http://www.facebook.com/profile.php?id=133713371337 n’est pas config pour que les non amis voit les photos

    Laisser un commentaire

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