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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Sécurité Discussion :

Une vulnérabilité dans Facebook permet de lancer des attaques DDoS contre une source externe


Sujet :

Sécurité

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Mars 2013
    Messages
    8 456
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Mars 2013
    Messages : 8 456
    Points : 197 830
    Points
    197 830
    Par défaut Une vulnérabilité dans Facebook permet de lancer des attaques DDoS contre une source externe
    Une vulnérabilité dans Facebook permet de lancer des attaques DDoS contre une source externe
    amplifiées par les serveurs du réseau social

    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 - Visualiser dans une fenêtre à part
      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 ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    18
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 18
    Points : 38
    Points
    38
    Par défaut
    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)

  3. #3
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Lead dév - Architecte
    Inscrit en
    Août 2003
    Messages
    6 691
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Lead dév - Architecte
    Secteur : Industrie

    Informations forums :
    Inscription : Août 2003
    Messages : 6 691
    Points : 20 222
    Points
    20 222
    Par défaut
    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.
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

Discussions similaires

  1. Aw Snap : le bug de Chrome permet de lancer des attaques DoS
    Par Michael Guilloux dans le forum Google Chrome
    Réponses: 1
    Dernier message: 11/04/2015, 23h13
  2. Réponses: 3
    Dernier message: 16/03/2014, 13h04
  3. Réponses: 5
    Dernier message: 13/12/2010, 09h17
  4. Réponses: 2
    Dernier message: 31/05/2007, 10h57
  5. [FPDF] Mettre des données issues d'une requête dans l'entête
    Par zoom61 dans le forum Bibliothèques et frameworks
    Réponses: 4
    Dernier message: 30/03/2007, 10h10

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo