IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Une vulnérabilité dans Facebook permet de lancer des attaques DDoS contre une source externe
Amplifiées par les serveurs du réseau social

Le , par Stéphane le calme

10PARTAGES

1  0 
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.

  1. 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>
  2. Ensuite utiliser m.facebook.com pour créer des notes qui seront tronquées silencieusement à une longueur fixe.
  3. Créer plusieurs notes du même utilisateur ou d'un utilisateur différent. Chaque note provoquera plus de 1 000 requêtes http.
  4. 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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de raimbow
Nouveau membre du Club https://www.developpez.com
Le 29/04/2014 à 8:29
C'est exactement la même vulnérabilité qui a été trouvé dans Google Doc il y a quelques temps de ça. Sauf que dans ce cas là, Facebook utilise un système de cache qui réduit un peu l'ampleur du problème.

Facebook dis ne pouvoir rien faire, mais il me semble qu'ils pourraient quand même

  • Mettre une limitation sur le nombre de balise image dans une note
  • Mettre une limitation sur le nombre de note créés (Pas plus d'une par minutes)
  • Récupérer les images lors de la création de la note et pas lors de la première consultation
  • Ne laisser qu'un seul serveur récupérer les images
  • Récupérer les images une par une et non pas en parallèle


ça n'affecterais que très peu la fonctionnalité (au pire cela prendrais un peu plus de temps à enregistrer la note, le temps que le serveur récupère les fichiers)
1  0 
Avatar de grunk
Modérateur https://www.developpez.com
Le 29/04/2014 à 9:15
Récupérer les images lors de la création de la note et pas lors de la première consultation
Stockage de données inutile si la note n'est jamais consultée (ce qui doit être le cas d'un paquet de note j'imagine)

Ne laisser qu'un seul serveur récupérer les images
J'imagine que ce sont les serveurs CDN de facebook qui récupère les données pour qu'elle soit propagées partout dans le monde afin de servir au mieux le client.
0  0