Utiliser Google Dorking pour attaquer ou protéger sites, bases de données et objets connectés

Qu’est-ce que Google Dorking ?

Google Dorking désigne l’utilisation d’opérateurs de recherche avancés pour découvrir des pages, des fichiers ou des paramètres exposés par les moteurs de recherche. En une ligne : ce sont des requêtes Google très ciblées qui exploitent l’index public pour trouver des informations sensibles.

Définition concise : un “dork” est une chaîne de recherche avancée construite avec des opérateurs Google (par exemple site:, inurl:, filetype:).

Important : l’outil est neutre. Son usage dépend des intentions. Utilisé de façon malveillante, il facilite la découverte de vulnérabilités. Utilisé de façon défensive, il aide à identifier et corriger les fuites d’informations.

Pourquoi cela fonctionne

Les moteurs indexent ce qu’ils peuvent atteindre. Beaucoup d’entreprises laissent des pages d’administration, des sauvegardes, des exports ou des logs accessibles sans authentification ou via des URL prévisibles. Google les référence. Les opérateurs avancés permettent de filtrer et d’identifier ces éléments.

Syntaxe de base

La forme générale d’un opérateur avancé est :

operateur:mot-clé

Il n’y a pas d’espace autour des deux-points. Des opérateurs peuvent être combinés pour obtenir des résultats précis.

Exemples de requêtes (non exhaustif) :

site:exemple.com inurl:admin
intext:@gmail.com filetype:xls
inurl:8443 -intext:8443
inurl:group_concat(username filetype:php intext:admin

Types de dorks

Google Dorking se divise en deux grandes catégories :

• Dorks simples : requêtes qui trouvent des éléments cachés ou difficiles à voir avec une recherche ordinaire. Elles servent souvent à l’inventaire d’informations.
• Dorks complexes : requêtes combinées et ciblées, utilisées pour trouver des cibles vulnérables exploitables.

Opérateurs courants (dorks simples)

Note : certains opérateurs évoluent avec les versions de l’interface et des API de Google.

Exemples concrets et interprétation

• Trouver des pages d’administration :

inurl:admin OR inurl:login site:exemple.com

• Extraire des emails publics dans des fichiers Excel :

intext:@gmail.com filetype:xls

• Localiser des services sur un port particulier (résultat découplé du texte) :

inurl:8443 -intext:8443

Explication : la requête cherche “8443” dans l’URL mais exclut les pages où “8443” n’est présent que dans le corps du texte — utile pour repérer des URL contenant explicitement le port.

• Exemple trouvé dans des recherches historiques :

inurl:group_concat(username filetype:php intext:admin

Cette requête combine une signature de fuite SQL (group_concat) avec un type de fichier et un terme d’interface admin. Elle a été utilisée pour repérer des injections SQL non corrigées.

Comment les attaquants l’exploitent

1. Reconnaissance passive : cartographie du périmètre sans scanner actif.
2. Collecte d’identifiants et de fichiers sauvegardés exposés.
3. Localisation de pages d’administration ou de consoles IoT.
4. Construction de listes pour attaques par dictionnaire ou phishing.

Automatisation : l’usage d’APIs (lorsqu’elles sont disponibles), de scripts ou d’outils d’agrégation permet d’exécuter des dizaines voire des milliers de dorks et d’indexer les résultats.

Quand Google Dorking échoue (contre-exemples)

• Contenu non indexé : pages protégées par authentification ou bloquées par robots.txt ne remontent pas dans l’index public.
• Contenu dynamique non rendu côté serveur : si l’information n’existe qu’après exécution JavaScript côté client, Google peut ne pas l’indexer.
• Pages nouvellement créées : l’indexation prend du temps.
• Sites avec règles de sécurité (noindex, X-Robots-Tag) correctement appliquées.

Alternatives et compléments aux dorks

• Shodan : recherche d’appareils IoT et services exposés au niveau réseau.
• Censys : inventaire des certificats et services TLS/SSL.
• Outils de crawling publics et internes (OWASP ZAP, Burp Suite) pour tests actifs.
• Intelligence OSINT (recherche sur GitHub, pastebins, forums) pour récupérer des secrets exposés.

Chacun a ses limites. Les dorks restent complémentaires car ils exploitent l’index public et l’historique des pages.

Mini-méthodologie d’audit éthique avec Google Dorking

1. Définir la portée et obtenir une autorisation écrite (périmètre de domaines / IP concernés).
2. Lister les opérateurs pertinents pour la cible.
3. Effectuer des recherches manuelles et automatisées en respectant la fréquence pour éviter le throttling.
4. Valider chaque découverte via accès légitime ou tests contrôlés.
5. Documenter et rapporter : preuve, impact, recommandations.
6. Vérifier les corrections et re-scanner.

Checklist par rôle

Pentester / Red Team :

• Autorisation écrite pour la cible.
• Liste d’opérateurs et dorks pertinents.
• Environnement d’exécution (scripts, rate-limiting).
• Capture d’écran et export des résultats.
• Tests complémentaires non destructifs.

Administrateur / Blue Team :

• Scanner dorking contre vos domaines.
• Identification des fichiers listés par dorks (backups, exports, logs).
• Correction (authentification, suppression, noindex).
• Mise en place de surveillance (alertes SIEM sur accès anormaux).

Responsable conformité / RGPD :

• Vérifier s’il y a des données personnelles exposées.
• Évaluer l’impact et notifier si nécessaire.
• Conserver la preuve pour audit.

Mesures de protection et durcissement

• Supprimer les fichiers sensibles du webroot et des sauvegardes publiques.
• Mettre en place une authentification forte sur les consoles d’administration.
• Utiliser l’en-tête X-Robots-Tag: noindex ou meta noindex sur les pages sensibles.
• Restreindre l’accès par IP pour les interfaces d’administration quand c’est possible.
• Éviter d’inclure des informations sensibles dans les URLs (params, chemins, dumps).
• Configurer correctement robots.txt (note : robots.txt prévient les bons robots mais documente aussi ce que vous souhaitez cacher ; ne comptez pas uniquement dessus).
• Renforcer la journalisation et les alertes SIEM lorsqu’un index public révèle des éléments critiques.

Important : interdire l’accès public à un fichier n’est pas la même chose que l’empêcher d’être indexé. Supprimez ou protégez l’objet, puis retirez-le de l’index Google via un outil de suppression si besoin.

Runbook d’incident (détection via dorking)

1. Contenir : vérifier si l’objet reste accessible. Restreindre immédiatement l’accès si possible.
2. Collecter : capturer les URLs, les screenshots, les timestamps et les requêtes exactes.
3. Evaluer : déterminer le type de données exposées (identifiants, données personnelles, secrets).
4. Corriger : retirer le fichier, appliquer l’authentification, redéployer la ressource corrigée.
5. Nettoyer l’index : utiliser l’outil de suppression d’URL de Google et configurer noindex.
6. Communiquer : informer les parties prenantes, le RSSI et, si applicable, lancer la procédure RGPD.
7. Vérifier : relancer les dorks et confirmer la suppression dans l’index.

Critères d’acceptation après remédiation

• Les dorks précédemment trouvés ne renvoient plus de résultats exposés.
• Les pages sensibles renvoient un code 401/403 ou redirigent vers une page d’authentification.
• Le fichier retiré n’est plus accessible publiquement et a été supprimé de l’index Google.
• Les preuves d’exposition sont archivées et un rapport d’incident est disponible.

Matrice de risques (qualitative)

• Faible impact / basse probabilité : page informative indexée sans données sensibles.
• Impact moyen / probabilité moyenne : listes d’emails, logs non sensibles.
• Impact élevé / probabilité élevée : identifiants, sauvegardes, secrets, données personnelles.

Mitigation prioritaire : traiter d’abord les éléments d’impact élevé.

Considérations légales et RGPD

Exposer des données personnelles via des pages indexées peut constituer une violation du RGPD. Les organisations doivent :

• Identifier rapidement les fuites.
• Évaluer le caractère personnel et la portée.
• Notifier les autorités compétentes si la fuite constitue une violation de données (conformément aux délais légaux).

Conseil : impliquez le délégué à la protection des données (DPO) dès la découverte.

Bonnes pratiques de recherche responsable

• N’effectuez pas d’accès non autorisés.
• Ne tentez pas d’exploiter une vulnérabilité découverte sans autorisation.
• Respectez les conditions d’utilisation des services et les lois locales.

Outils et ressources complémentaires

• Shodan, Censys : pour la recherche d’appareils et certificats.
• Outils de crawling : OWASP ZAP, Burp Suite pour tests actifs contrôlés.
• Scripts maison : pour automatiser des dorks dans le respect des quotas.

Foire aux questions (FAQ court)

• Est-ce légal d’utiliser des dorks ? Oui pour la simple recherche d’information publique. Non si vous exploitez ou accédez sans autorisation à des systèmes protégés.

• Un dork peut-il trouver toutes les vulnérabilités ? Non. Il révèle uniquement ce qui est indexé et accessible publiquement.

Résumé

Google Dorking est un outil puissant pour la reconnaissance passive. Il aide aussi bien les attaquants que les défenseurs. Pour réduire le risque, corrigez les fuites, protégez vos interfaces, et surveillez l’index public de vos domaines. Intégrez le dorking dans vos audits éthiques et vos procédures de réponse aux incidents.

Notes :

• Important : gardez des preuves et suivez une procédure d’audit formelle avant toute action corrective.
• Point de vigilance : ne comptez pas uniquement sur robots.txt pour protéger des informations sensibles.