Google : All Your Base Are Belong To Us

Depuis toujours, Google permet de faire des recherche de fichiers par nom d’extension. La syntaxe est simple mais finalement peu connue : « filetype:<ext> ». Ceux qui sont familiers de ce type de recherches ont forcément remarqué que tous les fichiers n’étaient pas traités de la même façon. Lesquels et pourquoi ?

Des fichiers suspects a priori

Les fichiers audio et vidéo ne sont pas proposés par Google. Vérifiez : une recherche sur « filetype:mp3 » renvoie moins de 10 000 résultats. En général, ce sont des pages HTML dont l’URL se termine par « mp3 ». Pas de musique. Même chose pour les AVI, les MP4, tous ces fichiers présents en masse sur le web, même en ne considérant que les productions légitimement partagées, ne sont pas indexés.

Les éditeurs de musique et de films ont réussi à convaincre Google d’une chose : si l’ensemble des contenus étaient visibles, l’immense majorité des données disponibles seraient des fichiers soumis au droit d’auteur. Or, les internautes ne respectent généralement pas ce droit.

Le prix de cette suspicion ? Les contenus légaux ne sont pas directement accessibles. Les films et musiques produits sous licence Creative Common, par exemple, sont sacrifiés sur l’autel de la défense des intérêts économiques de quelques sociétés. L’argument est toujours le même : il en va de la survie de la création artistique.

Vos données sont nos données

D’autres fichiers sont beaucoup mieux traités par Google. Parmi eux, certains représentent un réel danger : les extraits de bases de données.

L’immense majorité des sites web actuels repose sur un langage (PHP) qui permet d’interroger une base de donnée (SQL). L’intégralité des contenus se trouve dans la base. Il n’est pas rare que les administrateurs fassent des extractions de leur base de donnée à des fins de sauvegarde ou de test. Très souvent, l’extension attachée à ces « dump » est de type « .sql ».

Une recherche de type « filetype:sql » renvoie près d’un million d’entrées (soit 100 fois plus qu’une recherche sur les MP3). Dans ces fichiers, on peut trouver pèle-mêle :

  • des informations personnelles (les vôtres)
  • des données confidentielles (bancaires, médicales)
  • des mots de passe (parfois en clair)
  • des informations financières

Dans une société où la sécurité des individus primerait sur les intérêts économiques, on pourrait s’attendre à ce que le principal moteur de recherche mondial filtre ce type d’information. Ce n’est malheureusement pas le cas, et des millions d’informations confidentielles sont disponibles pour qui veut bien les chercher.

Dans ce cas précis, aucune connaissance particulière n’est nécessaire. Les données étant disponibles dans le cache de Google (si !), il n’est même pas nécessaire d’accéder au site concerné. Pas d’injection SQL, pas de brute force… un navigateur et un moteur de recherche suffisent. Effrayant.

All Your Base Are Belong To Us

Longtemps, j’ai alerté les administrateurs des différents sites concernés pour qu’ils suppriment les fichiers incriminés. Et puis je me suis demandé si je ne prenais pas le problème à l’envers. Google a les moyens de protéger ce type d’information. Ils le font pour les fichiers au format MP3, ils pourraient le faire pour les dumps SQL. Chaque jour, de nouvelles bases de données apparaissent sur la toile. Pas une semaine sans que des données privées soient publiées.

Comment alerter le public, les administrateurs et faire pression sur Google pour qu’ils agissent ? J’ai décidé de mettre en avant, chaque semaine, une adresse fournie par Google et qui met en danger nos informations.

Cette semaine, c’est le site « Basaburuko Saskia », un GIE permettant aux consommateurs de se fournir directement auprès d’agriculteurs basques, que Google déshabille. La base du site se trouve ici. Elle apparait sur la première page quand on recherche filetype:sql « 2011-06 »… et est datée du 14 juin 2011.

Twitter Facebook Google Plus email


28 thoughts on “Google : All Your Base Are Belong To Us”

  1. Si les gens font n’importe quoi … Il faudrait punir ces entreprises qui néglige à ce point les données des gens qui leurs font confiance. Un accident, une erreur ca arrive, ca c’est juste intolérable. De la à downgrade google je ne sais pas.

    1. Ce ne sont pas toujours des entreprises. Ce sont aussi des associations, des groupements qui ne sont pas économiques et qui rendent de vrais services, etc.

      La responsabilité de l’admin est évidemment toujours en cause, et la sécurité par l’obscurité donne rarement des résultats.

      Mais puisque nos amis de Google ont les outils, et s’ils veulent rendre un vrai service aux utilisateurs…

    2. Entièrement d’accord. Google index ce que les scrawlers trouvent, sans exploiter de failles ni quoi que ce soit de ce genre.
      Si les développeurs et webmasters sont assez stupides pour laisser trainer des fichiers sensibles là où ils sont accessibles simplement avec un navigateur, et surtout qu’un simple robot peut les trouver, j’imagine que les vrais « méchants » les ont déjà depuis un bout de temps.
      J’hésite entre pebkac et Epic Fail :)

  2. Tant que ça ne touche pas les grands groupes (donc un max de monde en une fois), il y a peu de chance que Google fasse quoique ce soit. Prévenir les admins me semble plus efficace (mais plus laborieux aussi)

  3. Avec les bons mots clés / opérateurs c’est immonde !

    vous voulez monter une base mail qualifiée pour du spam ?
    filetype:sql wanadoo.fr

    monter un wikileaks ?
    filetype:sql inurl: ».gov »

    C’est scandaleux

    1. Je parle bien des fichiers qui sont DIRECTEMENT indexés. Ce que tu recherches, ce sont les répertoires qui sont lisibles pour le public (pas d’index.html) et qui contiennent des fichiers mp3.

      C’est très différent.

      Pour tester vraiment ce que je veux dire, crée une page avec un lien qui pointe vers un fichier .mp3 posé dans un répertoire non lisible directement. Dans la même page, mets un lien vers un fichier .sql (par exemple) qui se trouve dans le même répertoire non lisible.

      Attends que les robots de Google passent, puis tape « filetype:sql site:ton.site ». Tu verras que ton fichier est indexé. Tape « filetype:mp3 site:ton.site » et tu verras que le mp3 n’est pas indexé.

      1. comme précisé plus bas dans les commentaires, tout dépend de ce que ton serveur répond sur le content-type.
        Si tu balances le .mp3 agec un header content-type:text/plain il sera indexé. Inversement si tu balances ton .sql avec un content-type qui n’est pas du texte, il passera pas :)

  4. Je suis pas tout à fait d’accord avec la conclusion de l’article. Si google peut indexer un tel fichier c’est bien parce que l’admin lui en a donné l’autorisation en premier lieu en le publiant à la vue de tous et en ne l’interdisant pas dans le robots.txt.

  5. @TrucMuche : regarde bien la barre de défilement horizontale en bas de ton navigateur, il y a de très longues lignes qui contiennent des centaines d’adresses mail(633 occurrences « @ » trouvées).

    Ceci dit, cette « découverte » c’est un peu enfoncer une porte ouverte, le « Google Hacking » c’est pas vraiment nouveau. Si vous voulez en savoir plus, il suffit d’aller sur Google Books (sic…) : http://goo.gl/ReaQR

    Mais c’est bien d’en parler et de sensibiliser. C’est toujours hallucinant de voir tout ce qu’on peut encore trouver.

  6. Et du coup, les base de données open source seraient pénalisées! =P

    Il faudrait peut-être que les admin réseaux commencent à faire la différence entre les parties publiques et privées d’un serveur…
    Et que les États et les entreprises arrêtent de se soumettre aux maison de disques…
    Enfin, moi je dis ça, mais bon…

  7. D’accord pour les robots.txt essentiel ont peut même complètement cacher sont site de google si ont veut.

    Sinon pour les mp3 : site:free.fr intitle: »index of » mp3 artiste.

    Juste pas reconnus en filetype.

  8. Hm.. Il n’y a pas de « filtrage » a proprement parlé des fichiers mp3. C’est simplement que Google indexe avant tout du texte, et que la requete « filetype » n’est pas vraiment une recherche sur le type de fichier (ca n’ira jamais matter les entetes de binaires indexés par exemple), mais simplement sur le dernier élément après le dernier « . » dans une URL.

    Quelques exemples pour appuyer mes propos :

    [filetype:wav] : http://www.google.fr/search?q=filetype%3Awav
    43 résultats, est ce qu’on doit en conclure que Google filtre plus les wav que les mp3 ? non ;)

    [filetype:xyz] : http://www.google.fr/search?q=filetype%3Axyz
    [filetype:exemple] : http://www.google.fr/search?q=filetype%3Aexemple
    google indexe des trucs qui ne sont pas forcement des types de fichiers, seul le string présent après le ‘.’ est pris en compte

    Quand tu te retrouves avec des binaires indexés, c’est généralement que le serveur à renvoyé un mauvais content-type, sinon ca ne doit pas se retrouver la.

    ~

    Concernant les fameuses requetes permettant de faire ressortir des fichiers sensibles, ca a été souvent signalé. Je ne veux pas remettre en cause la qualité de ton article, on ne le dira de toutes façons jamais assez.. mais si on veut creuser sur cette piste il y a pas mal de sites qui se sont spécialisés sur ce type de recherche.
    Ces requetes étaient appelées à un moment des « google dorks ». Et un certain « Johnny » en a fait un vrai business.
    Après avoir récolté des milliers de requetes du genre à l’aide d’une communauté de bénévoles trippés, il a compilé le tout dans une DB, un bouquin, des confs etc..

    On en retrouve des traces dans la GHDB (Google Hacking DataBase) : http://www.hackersforcharity.org/ghdb/

    Certains dorks fonctionnent encore très bien..

    ~

    Bonne chasse :)

  9. @az : Je pense quand même qu’il y a filtrage. Google ne référence pas directement le fichier d’après son en-tête, c’est clair, mais uniquement les occurrences .extension qui se retrouvent dans des URL (même si ça ne pointe pas directement sur le fichier et que le .extension est en plein milieu de l’URL). Je doute qu’il y ait seulement ~10000 URL qui contiennent http://www.abc.def/neuneu.php?bobo.mp3&blablabla&yoyoyo ou autres. Tu vois ce que je veux dire ?

    Ce qui est cool, c’est que Google ne filtre pas encore (totalement) les .torrent, ça marche bien pour faire ses courses…

    1. En fait dans l’exemple que tu donnes, l’opérateur filetype matchera « .php »
      Tout ce qui vient en paramètre après le « ? » ne sera jamais matché par un « filetype: ».

      Donc non, je persiste, il n’y a pas de filtrage particulier :)

Laisser un commentaire

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