Google dork

Ce que ça change pour une organisation

Un dork n’attaque pas le site visé : il interroge l’index d’un moteur de recherche. Le risque tient donc à ce que l’organisation laisse indexer, et la Google Hacking Database (GHDB) en dresse la typologie : répertoires sensibles, fichiers contenant des identifiants ou des informations confidentielles, portails de connexion, messages d’erreur, serveurs et fichiers vulnérables.

Google documente lui-même les opérateurs qui servent de base à ces requêtes : site: limite les résultats à un domaine, filetype: à un format de fichier, les guillemets exigent une correspondance exacte et le tiret exclut un mot. Rien de tout cela n’est réservé aux attaquants, et c’est ce qui rend l’audit défensif simple : en lançant ces mêmes requêtes sur ses propres domaines, une organisation voit ce qu’un tiers verrait. Les contenus qui n’ont pas à être publics doivent alors être retirés ou protégés par une authentification.

La pratique a été popularisée en 2000 par Johnny Long, qui a catalogué ces requêtes dans la GHDB avant de la confier à OffSec en novembre 2010 ; elle est maintenue comme extension de l’Exploit Database.

Exemple

Exemple générique : une requête associant site: au domaine d’une PME et filetype:xlsx liste tous les tableurs que le moteur a indexés sur ce domaine. Si l’un d’eux contient un export de clients parce qu’un répertoire n’était pas protégé, n’importe qui peut le consulter sans avoir forcé la moindre protection.

À ne pas confondre avec

• La Google Hacking Database : catalogue de requêtes classées par catégories, alors que le dork est la requête elle-même.
• L’usage courant des opérateurs de recherche : cibler un site ou un format pour trouver une information est un usage ordinaire ; la requête devient un dork lorsque son but est de faire apparaître des contenus exposés par erreur.