La façon dont Facebook Notes gère les balises d’image en HTML pourrait donner à un hacker la possibilité de lancer une attaque DDoS contre une source externe en utilisant la puissance du réseau pour l’amplifier. Pour ceux qui ne le savent pas, Facebook Notes fonctionne un peu comme la plate-forme de microblogage Tumblr et est intégré au réseau social. Il permet aux utilisateurs d'écrire, de modifier et de publier du contenu avec 63 206 caractères au maximum que Facebook a imposé comme limite sur les mises à jour de statut. Facebook permet aux utilisateurs d'intégrer différentes balises HTML dans leurs notes. Cependant, la façon dont Facebook traite les balises <img> pourrait présenter de sérieux problèmes pour les sources et les hôtes de ces images.
Dans son blog, le chercheur Chaman Thapa écrit que « Facebook Notes permet désormais d’utiliser des balises <img>. Chaque fois qu’une balise <img> est utilisée, Facebook récupère l’image depuis un serveur externe et la met en cache.». Il explique que Facebook ne met en cache chaque image qu’une seule fois, mais la version mise en cache peut être contournée en utilisant des paramètres GET aléatoires et qu’en envoyant suffisamment de requêtes GET, cela pourrait créer une condition de déni de service pour le serveur hébergeant le fichier image. Thapa affirme que de gros fichiers comme les PDF ou les vidéos peuvent amplifier l’attaque.
Pour ce faire il est passé par quatre étapes.
- La première consiste a créer une liste de balises d'images uniques .
Code : Sélectionner tout 1
2
3
4<img src=http://targetname/file?r=1></img> <img src=http://targetname/file?r=1></img> .. <img src=http://targetname/file?r=1000></img> - Ensuite utiliser m.facebook.com pour créer des notes qui seront tronquées silencieusement à une longueur fixe.
- Créer plusieurs notes du même utilisateur ou d'un utilisateur différent. Chaque note provoquera plus de 1 000 requêtes http.
- Voir toutes les notes en même temps. Le serveur cible aura alors une inondation massive de requêtes http get. Des milliers de requêtes GET seront envoyées à un serveur unique en l'espace de quelques secondes. Le nombre total de serveurs Facebook y ayant accès en parallèle est supérieur à 100.
Avec des ressources informatiques limitées, Thapa a réussi à générer près de 900 Mbps de trafic sortant en obligeant Facebook à récupérer un fichier PDF de 13 Mo. Thapa affirme que 12 des serveurs de Facebook ont tenté de récupérer le fichier PDF quelques 180 000 fois.
Thapa a signalé ce bogue à Facebook le 03 mars dernier qui avait d’abord mal compris la vulnérabilité, pensant qu'il ne pouvait provoquer une erreur 404, et qu'une telle erreur ne constituait pas un bogue à fort impact. Par la suite, après cette démonstration et des discussions, le réseau social a admis l’existence du bogue. Cependant, Facebook a expliqué à Thapa qu’il n’aurait pas droit au versement d’une quelconque prime parce qu’il n’a pas l’intention de le corriger, car il n’existe pas de moyen d’empêcher les attaques sans que la fonctionnalité globale n’en pâtisse. Facebook a tout de même salué le travail du chercheur le qualifiant à la fois d’intéressant et de créatif et espère le voir toujours participer au Facebook Bounty Program.
Toutefois, dans la documentation de Facebook pour les développeurs, le réseau social fait part d'une méthode pour obtenir l'adresse IP qui appartient au Facebook Crawler. Un moyen d'éviter ce désagrément serait donc de bloquer les adresses IP.
Source : blog Thapa, Facebook
Et vous ?
Que suggérez-vous ? 
