Skip to content

Honey Dorks ou la détection des recherches via les Google Dorks

Lors de la préparation d’une attaque ou lors de l’étude de la surface d’attaque et des vulnérabilités d’une cible par un attaquant, celui-ci peut utiliser les Google Dorks, aussi appelés Google Hacking, pour récolter des informations sensibles qui peuvent être déterminantes. L’utilisation de moteurs de recherche pose alors des difficultés aux entreprises qui aimeraient bien savoir que l’on s’intéresse à elles et qu’une attaque se prépare.

Nous allons ici voir comment il est possible d’utiliser les recherches Google Dorks  pour trahir les intentions d’un attaquant préparant une éventuelle attaque.

Les Google Dorks, ou Le Google hacking

Les Google Dorks, aussi appelés Google Hacking, sont un ensemble d’opérateurs et de mots-clés utilisés lors de la recherche sur un moteur de recherches comme Google. Le plus souvent, les Google Dorks sont utilisés afin de rechercher des données sensibles qui ne devraient pas être référencées sur un moteur de recherches, pour la simple raison qu’elles donnent des informations qui peuvent s’avérer dangereuses. Cela peut aller de la simple version d’un plugin WordPress, d’une version d’un service web quelconque à l’indexation de fichiers de logs malencontreusement et/ou maladroitement positionnés sur le serveur web, et qui finissent par être référencés (c’est à dire trouvables dans des moteurs de recherche, si on utilise les bonnes requêtes). L’utilisation de Google Dorks se caractérise par l’utilisation d’opérateurs spécifiquement fournis par les moteurs de recherche tel que Google afin d’avoir une plus grande précision dans la recherche. Parmi ces opérateurs, on notera par exemple « filetype: » qui permet de rechercher tous les fichiers d’un format spécifique (pdf par exemple), ou encore « site: » qui permet d’avoir les résultats venant exclusivement d’un domaine ou sous-domaine précis. La liste complète des opérateurs Google pouvant être utilisés (en tout légitimité d’ailleurs) serait trop longue et pourrait faire l’objet d’un livre entier, il existe notamment de très bonnes documentations en ligne sur ceux-ci.  (http://www.googleguide.com/google-guide-overview.html).

Le plus souvent, un attaquant va utiliser les moteurs de recherche lors de sa phase de découverte, dite « information gathering » . Il va alors chercher à se renseigner sur sa cible, localisation, nombre d’employés, noms des employés et fonctions, profils sur les réseaux sociaux et informations personnelles qui s’y trouvent, les sous-domaines actifs, etc. Cependant l’utilisation des Google Dorks intervient également lors des phases de « scanning » et de recherche de vulnérabilité. En effet, on va pouvoir, par exemple, rechercher la version vulnérable d’un service web sur les sous-domaines de la cible via le Google Dorks suivant par exemple :

intitle : « Zimbra Web Client Log In »

ou encore :

intext : "Wordpress SEO plugin v1.7.1"

La sortie va ici nous ressortir toutes les versions « v1.7.1 » du plugin WordPress « WordPress SEO plugin » . Il faut également noter que les Google Dorks sont parfois également utilisés de façon massive sur Internet pour trouver des fichiers contenant des informations sensibles comme des fichiers de logs, des fichiers de mots de passe, d’utilisateurs ou alors des répertoires qui n’ont normalement rien à faire sur internet comme des accès ouvert phpmyadmin, etc.

Un autre exemple, il est courant de vouloir cacher les messages d’erreur php lorsque l’on met un serveur web et un site web en place, cela pour la simple raison qu’ils permettent de voir des chemins absolus pouvant révéler des informations sensibles sur le serveur. On peut alors partir à la recherche de chaines de caractères propres aux erreurs PHP qui se sont faites indexées et alors retrouver des répertoires sur un serveur donné via une requête comme :

filetype:php intext:"failed to open stream: No such file or directory"

Cela est alors intéressant pour l’attaquant car l’utilisation des moteurs de recherches lui permettent d’avoir une anonymisation dans un certains cadre. En effet, l’entreprise ne sait pas encore, à ce stade, que l’on s’intéresse à elle.  La détection des intrusions informatiques est un problème réel. Il arrive que des intrusions ne soient détectées seulement des mois après qu’elles se soient passées. Réfléchissons donc à une manière d’amener un peu plus de vision aux RSSI, sysadmins et autres défenseurs du système d’information qui seront, j’en suis sûr, toujours pour une façon supplémentaire de détecter d’éventuelles attaques.

Utilisation des Google Dorks dans la défense du SI

Il est néanmoins possible d’utiliser les Google Dorks pour essayer de détecter qu’un pirate s’intéresse à nous, le tout en reprenant le principe des pots de miel. Voyons cela !

Le principe est assez simple et part du fonctionnement normal des moteurs de recherche, des services web et de l’utilisation que l’on en fait généralement.

Lors de la préparation d’une attaque, un attaquant ayant le souci du détail est susceptible d’utiliser les Google Dorks. On peut alors en profiter pour lancer une alerte comme quoi certaines personnes cherchent des données sensibles à propos de notre société.

La première étape de cette détection va être de créer un faux fichier sensible, contenant par exemple des mots de passe ou des informations qui paraîtront sensibles (mais fausses bien évidemment). Cela à l’image d’un pot de miel dans lequel on cherche à attirer le pirate qui s’intéresse à nous d’un peu trop près. On va ensuite positionner ces fichiers et ces informations sur un site web, un honey pot si vous en avez (ce qui est de loin le plus judicieux). Le but va être de faire référencer ces fichiers pour qu’ils soient facilement trouvables via des Google Dorks. Différents tests que j’ai effectué portaient par exemple sur un fichier ayant la structure et le contenu d’un fichier /etc/passwd sous Linux et notamment la chaîne de caractères suivante :

root:x:0:0:root:/root:/bin/bash

celle-ci  peut être retrouvée via la requête Google Dorks suivante :

intext : "root:x:0:0:root:/root:/bin/bash"

En spécifiant le nom de domaine d’un société ciblée, on va pouvoir restreindre de manière drastique les résultats Google affichés et n’obtenir que ce qui concerne la cible de l’attaquant :

intext : "root:x:0:0:root:/root:/bin/bash" site:societe-xy.tld

Le but est de faire en sorte qu’un attaquant utilisant les Google Dorks en vue d’avoir des informations sur notre société puisse « facilement » trouver ce fichier. Et encore mieux, le visiter !

Une fois que notre pirate en herbe aura visité ce fichier faussement sensible, tout sera fait. Cela parce qu’il aura généré une requête HTTP dans nos logs et que c’est le signe qu’une personne aura ouvert ce fichier sensible. Tout le système de détection se basera en effet sur le fait qu’une ligne de log indiquant qu’une requête HTTP a touché le fichier « piégé » . On pourra en effet utiliser ce que l’on appelle des « log-based intrusion detection system » , log-based IDS (ou système de détection d’intrusion basé sur les journaux d’événement, en bon français) pour lancer l’alerte. Ces systèmes, dont Fail2ban est le plus simple d’accès à mon avis, se basent en effet sur la lecture presque en direct des journaux d’événements de différents systèmes sur lesquels des filtres sont appliqués. Pour résumé les événements :
honeydroks01
Plus clairement, lorsque le pirate souhaitera visiter notre fichier sensible, il générera un événement dans les journaux de notre système, événement dont on pourra se servir pour présumer qu’une attaque est en préparation. Nous verrons par la suite que quelques filtrages logiques devront être appliqués avant de présumer une attaque. Le principe étant celui-ci, il est au final assez simple de mettre en place techniquement la surveillance des logs, c’est ce que nous allons voir par la suite.
Le fichier de log généré ici sera audible car peu nombreux seront les visiteurs légitimes se rendant sur votre faux fichier /etc/passwd.

Mise en application : Diffusion de faux fichiers sensibles

La première chose à faire lorsque l’on souhaite mettre en place techniquement ce système de surveillance, c’est la création de nos faux fichiers sensibles. Pour cela, il faut se renseigner sur les Google Dorks les plus souvent saisis, cela dans le but d’être le plus facilement trouvé par l’attaquant souhaitant nous cibler. Il ne faut pas bien sûr que cela semble trop gros, on reprend pour rappel le même principe de piège que les HoneyPot (SSH par exemple). Différents tests que j’ai effectué portaient sur un fichier /etc/passwd. Nous pouvons nous baser là dessus. On va alors créer un fichier nommé «passwd» et contenant la même structure qu’un fichier /etc/passwd standard, à savoir cette ligne par exemple :

root:x:0:0:root:/root:/bin/bash

Notons que beaucoup de fichiers peuvent rapidement sembler sensibles, un excel avec de faux noms d’utilisateurs, un fichier Changelog indiquant une version vulnérable d’un service quelconque, etc.

Une fois le fichier positionné sur votre serveur web, cela peut être un serveur avec un sous-domaine uniquement dédié à ce piège, il serait peu recommandable de mettre cela sur un serveur en production et à destination des clients/visiteurs/ Nous devons ensuite le faire référencer, je n’entrerais pas ici dans les engrenages du référencement, sachez simplement que le plus simple est d’ajouter une ligne dans le fichier «sitemap.xml» dont tout bon site web est muni. Ce fichier sitemap.xml est régulièrement parcouru par les robots des moteurs de recherche qui sont alors plus rapidement avertis de ce qu’il a de nouveau  à visiter  et à indexer sur un site donné.

Quelque jours après mise en place et référencement, il suffira pour le retrouver d’effectuer nous même un Google Dorks sur la chaîne de caractères sensible mise en ligne pour notre piège. Dans le cas exposé précédemment, cela sera donc :

intext : "root:x:0:0:root:/root:/bin/bash"

On peut forcer la chance, comme le ferait un attaquant, en spécifiant notre domaine avec l’opérateur « site: » :

intext : "root:x:0:0:root:/root:/bin/bash"  site:societe-xy.tld

Passons maintenant à la mise en place du système qui va nous permettre d’être alerté quand un requête HTTP visera notre fichier piégé.

Mise en application : Installation du système de détection

Nous passons à présent à l’installation de notre log-based IDS, le système de détection d’intrusion qui va nous permettre, en regardant les logs avec des filtres définis, de capter la présence d’une requête HTTP ayant visé notre fichier piégé. Nous allons ici utiliser Fail2ban sous Debian 7.

On procède tout d’abord à son installation :

apt-get update
apt-get install fail2ban

On pourra trouver les fichiers de configuration de fail2ban dans « /etc/fail2ban » :

honeydorks-01
Pour détailler un peu cet outil :

  • action.d : contient l’ensemble des actions et alertes qui pourront être utilisées à la suite de la détection d’événements correspondant aux filtres configurés
  • fail2ban.conf : fichier de configuration standard de fail2ban
  • filterd.d : contient l’ensemble des filtres qu’il va être possible d’utiliser dans nos «jails»
  • jail.conf : configuration des «jails» , les prisons que fail2ban peut mettre en place.

Après avoir identifié le fichier de log dans lequel seront inscrits les événements relatifs aux requêtes HTTP visant notre ficher piégé ainsi que la structure de ladite ligne de log, nous pouvons passer à la construction de notre filtre personnalisé. Dans notre cas, les logs seront mis par défaut dans /var/log/apache2/access.log et une ligne d’accès basique au fichier sensible mis en ligne sera :

192.168.10.1 - - [04/Dec/2014:22:33:15 +0100] "GET /passwd HTTP/1.1" 200 1773 "-" "Mozilla/5.0 (Windows NT 6.3; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0"

Étant donné que nous travaillons ici sur des noms de fichier et des contenus différents selon les cas d’utilisation, il est obligatoire de passer par une règle de détection d’événement personnalisée. On créé donc un nouveau fichier dans /etc/fail2ban/filter.d/, par exemple « googledorks_detect.conf  » . Voici son contenu :

[Definition]
#
# Option: failregex
# Note : regex qui match avec des fichiers sensibles volontairement
#  mis en ligne.
# Values: TEXT
#
failregex = <HOST> - - .* "GET /passwd.*
ignoreregex =

Pour rappel, le principe d’un log-based IDS comme Fail2ban est de surveiller les logs à l’aide de filtre paramétré pour trouver des expressions régulières particulières pour ensuite lancer des actions d’avertissement ou de prévention/protection. Nous allons créer une nouvelle prison, ou « jail »  dans le fichier « jail.conf » :

[honeydorks]
enabled         = true
port            = http,https
filter          = apache-sensitive-file
logpath         = /var/log/apache2/access.log
maxretry        = 1
banaction       = mail

Pour expliquer un peu cette configuration, on nomme donc notre jail «honeydorks» , puis on y applique notre nouvelle règle de filtrage «apache-sensitive-file» . On indique ensuite le fichier de logs dans lequel Fail2ban sera susceptible de trouver les événements qui nous intéressent. On paramètre le maxretry à 1 car on devra lancer un mail dès que la ligne sera détectée et ne pas attendre qu’il en trouve plusieurs pour commencer à envoyer des mails. Enfin, on demande à lancer l’action «mail» qui permet d’envoyer des mails lorsque l’expression qui nous intéresse est détectée dans les logs.

Quelques limites, soyez au courant !

  • J’ai détecté une IP/un accès à mon fichier piégé, oui, et alors ? Il est vrai que la mise en place de ce petit piège peut paraître bien veine, la simple détection du fait que le fichier ai été visité n’empêchera sûrement pas les attaques, et elle n’aidera probablement pas à détecter un attaquant. Néanmoins cela peut servir à prouver que l’on s’intéresse à vous de différentes façons, le principe est alors le même que pour les HoneyPot qui permettent d’occuper les attaquants avec de faux services et d’amasser quelques informations pour pouvoir les faire corréler avec d’autres.
  • Les GoogleBots et autres spiders généreront forcément des faux positifs dans les alertes. On peut alors s’attendre à un effet « le garçon qui criait au loup » , souvent vu dans la supervision et les alertes : on ne regarde plus les alertes, car on en a trop souvent pour pas grand-chose.
    Pour palier à ce problème, on peut envisager l’exclusion des  lignes de logs contenant les signatures USER-AGENT des spiders connus («GoogleBot» par exemple), cela est prévu dans les trames de filtres Fail2ban. Cependant, un pirate ayant falsifié son propre USER-AGENT pour mettre celui d’un spider passera alors inaperçu.
  • Techniquement, il existe des façons de contourner la génération d’une ligne d’événement dans les journaux des serveurs web.  Avec les moteur de recherches tel que Google, on peut accéder à la version en cache d’une page web ou d’un fichier. Cela est d’ailleurs prévu dans les opérateurs Google dont nous parlions plus haut via l’opérateur «cache:». N’est alors affiché uniquement ce qui est dans le cache Google.

Il peut également être intéressant de croiser les outils, on peut par exemple tenter de fournir de faux identifiants dans le fichier fournis dans notre HoneyDorks et ensuite utilisé un HoneyPot/HoneyWords. Attention cependant à ne pas passer dans un mode où vous attirerez les curieux.

Partager :
Published inArticles

Be First to Comment

Laisser un commentaire

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