↓ Aller au contenu
Ixonae on Security
  1. Articles/

OSINT à partir des noms de domaine en utilisant le DNS - Une introduction

·9 mins
Ixonae
OSINT Forensique Vie privée
Ixonae
Auteur
Ixonae
Sommaire

Avertissement : Cet article a été traduit de l’anglais par un LLM. La précision n’est pas garantie. Vous pouvez lire l’article original en anglais.

Les serveurs DNS sont l’un des piliers d’Internet. Entre autres choses, ils permettent à nos ordinateurs de convertir les noms de domaine en adresses IP, nous permettant de nous connecter facilement aux services sans avoir à connaître leur adresse IP.

À quoi d’autre les serveurs DNS et les noms de domaine sont-ils utiles ? L’OSINT. À travers divers mécanismes, nous pouvons obtenir une variété d’informations utiles à partir d’eux. Cet article présentera certaines façons d’obtenir ces informations et ce que nous pouvons en faire. D’abord, nous verrons comment tirer parti du protocole WHOIS, puis comment utiliser la commande dig pour obtenir des informations à partir des entrées DNS. Enfin, nous discuterons des données historiques et listerons quelques services utiles pour les obtenir.

Cet article ne prétend pas être totalement exhaustif, et nous avons fait le choix de ne parler que de certaines fonctionnalités et types d’informations fondamentaux. D’autres choses liées aux noms de domaine, comme l’obtention d’informations à partir de certificats SSL, de sous-domaines ou de sitemaps, pourraient être développées dans de futurs articles.

WHOIS et informations sur le propriétaire
#

La chose la plus connue pour obtenir des informations sur un nom de domaine est probablement le WHOIS, qui est un protocole permettant d’interroger des bases de données contenant les informations des propriétaires de sites web. WHOIS peut être utilisé en ligne de commande (par exemple whois domain.tld), mais il existe aussi de multiples utilitaires en ligne tels que viewdns.info (qui dispose de nombreux outils) ou who.is qui permettent de faire des requêtes via des pages web.

Le résultat de la commande whois est généralement assez verbeux. L’exemple suivant, un extrait du whois de Facebook, montre certaines des données pertinentes retournées.

Domain Name: FACEBOOK.COM
Registry Domain ID: 2320948_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.registrarsafe.com
Registrar URL: https://www.registrarsafe.com
Updated Date: 2020-03-10T18:53:59Z
Creation Date: 1997-03-29T05:00:00Z
Registrar Registration Expiration Date: 2028-03-30T04:00:00Z
Registrar: RegistrarSafe, LLC
Registrar IANA ID: 3237
Registrar Abuse Contact Email: abusecomplaints@registrarsafe.com
Registrar Abuse Contact Phone: +1.6503087004
Domain Status: clientTransferProhibited https://www.icann.org/epp#clientTransferProhibited
Registry Registrant ID:
Registrant Name: Domain Admin
Registrant Organization: Facebook, Inc.
Registrant Street: 1601 Willow Rd
Registrant City: Menlo Park
Registrant State/Province: CA
Registrant Postal Code: 94025
Registrant Country: US
Registrant Phone: +1.6505434800
Registrant Phone Ext:
Registrant Fax: +1.6505434800
Registrant Fax Ext:
Registrant Email: domain@fb.com
Registry Admin ID:
[...]
Registry Tech ID:
[...]
Name Server: C.NS.FACEBOOK.COM
Name Server: B.NS.FACEBOOK.COM
DNSSEC: unsigned
URL of the ICANN WHOIS Data Problem Reporting System: http://wdprs.internic.net/
>>> Last update of WHOIS database: 2021-09-22T01:23:51Z <<<

Si nous enquêtions sur le domaine facebook.com, nous pourrions tirer parti des informations suivantes :

  • Nous savons que le nom de domaine est enregistré chez registrarsafe.com. Nous pourrions utiliser les informations de contact fournies pour nous plaindre au registraire si nous avions des raisons de vouloir faire retirer des choses liées à ce domaine.
  • Nous savons quand le domaine a été créé, quand il expirera, et quand il a été mis à jour pour la dernière fois. Il existe aussi de multiples usages pour ces informations. Par exemple, si nous essayons de déterminer si une adresse email est légitime (c’est-à-dire non utilisée pour du spam), nous pourrions argumenter qu’un email appartenant à un nom de domaine enregistré il y a dix ans est moins susceptible d’être du spam comparé à un email appartenant à un domaine enregistré il y a dix heures.
  • Nous savons qui est le déclarant et comment le contacter. Ce champ est cependant à traiter avec prudence. Les registraires de domaines n’effectuent généralement aucune vérification de l’identité du déclarant, donc quelque chose de totalement incorrect pourrait être enregistré. De plus, il existe un certain nombre de registraires qui permettent aux clients de masquer leurs informations dans le registre.
  • Nous savons quels serveurs hébergent les zones DNS (c’est-à-dire les serveurs qui stockeront les différentes entrées DNS pour ce domaine).

Un autre usage naïf de ces informations pourrait aussi être d’essayer de prouver que deux domaines sont exploités par la même entité : avoir les mêmes informations dans le whois est un élément qui aiderait à soutenir cette hypothèse.

Utilisation des requêtes DNS
#

Les requêtes WHOIS sont intéressantes car elles peuvent nous donner des informations générales sur le propriétaire du domaine et où/quand il a enregistré le domaine, mais il est possible d’obtenir plus d’informations en examinant les entrées DNS.

Sur Linux/macOS, nous pouvons utiliser la commande dig pour nous aider à recueillir des informations. La syntaxe est assez simple :

  • dig MX domain.tld montrera quel(s) serveur(s) sont configurés pour recevoir les emails pour ce domaine.
  • dig MX sub.domain.com @1.1.1.1 fera la même chose que l’exemple précédent, mais demandera spécifiquement cette information au serveur DNS 1.1.1.1.

Sans entrer dans les spécificités du DNS (Cloudflare a une excellente documentation si vous voulez en savoir plus), il existe plusieurs types d’entrées DNS qui peuvent être configurées pour divers cas d’usage. Parmi les plus courants (cette page montre une liste plus exhaustive de tous les types existants) :

  • A : pour obtenir l’adresse IPv4 associée au domaine
  • AAAA : identique à A mais pour IPv6
  • CNAME : pour définir des alias. Par exemple, si nous avons un domain.tld avec une entrée DNS A pointant vers 123.123.123.123, nous pourrions créer une entrée CNAME pour dire que www.domain.tld devrait pointer vers domain.tld. De cette façon, si nous voulons changer le serveur utilisé pour notre service, nous ne devons modifier que l’entrée de domain.tld.
  • NS : pour définir les serveurs de noms en charge du stockage de la configuration DNS du domaine
  • MX : pour obtenir l’adresse du serveur de messagerie
  • TXT : pour partager du texte descriptif

Les quatre premiers éléments de cette liste peuvent être utiles, mais les types les plus intéressants sont MX et TXT.

Entrées DNS de type MX
#

Une requête MX via la commande dig retournera quelque chose ressemblant à l’exemple suivant (où j’ai exécuté un dig MX mozilla.com).

;; ANSWER SECTION:
mozilla.com.		60	IN	MX	5 alt1.aspmx.l.google.com.
mozilla.com.		60	IN	MX	5 alt2.aspmx.l.google.com.
mozilla.com.		60	IN	MX	10 aspmx3.googlemail.com.
mozilla.com.		60	IN	MX	1 aspmx.l.google.com.

Il n’y a pas beaucoup d’informations, mais nous pouvons en extraire que Mozilla a plusieurs serveurs capables de recevoir des emails.

  • aspmx.l.google.com, qui a une valeur de priorité de 1
  • alt1.aspmx.l.google.com et alt2.aspmx.l.google.com, qui ont une priorité de 5
  • aspmx3.googlemail.com, qui a une valeur de priorité de 10

La priorité est utilisée pour déterminer à quel serveur les emails doivent être envoyés. Plus le nombre de priorité est bas, plus la priorité est élevée. En pratique, cela signifie que si vous essayez d’envoyer un email à Mozilla, le fournisseur de messagerie essaiera d’abord de contacter aspmx.l.google.com, si ça ne fonctionne pas alt1.aspmx.l.google.com, et si ça ne fonctionne toujours pas aspmx3.googlemail.com.

Le point important ici est que ce champ nous permet d’obtenir plus d’informations sur notre cible. Spécifiquement, quel service elle utilise pour recevoir les emails. Dans notre exemple, nous pouvons voir que Mozilla utilise Google Mail. Parfois, les domaines ont des configurations plus imaginatives (par exemple, utilisant plusieurs fournisseurs), ce qui peut aider à lier des noms de domaine entre eux.

Entrées DNS de type TXT
#

De manière similaire aux entrées de type MX, les entrées TXT sont utiles car nous pouvons obtenir plus d’informations sur les services utilisés par notre cible, puisqu’elles sont souvent utilisées pour prouver la propriété d’un nom de domaine à des services tiers.

Par exemple, si nous interrogeons les entrées TXT pour google.com, twitter.com et apple.com, nous pouvons voir que les lignes suivantes font partie des réponses (tronquées pour améliorer la lisibilité)

;; ANSWER SECTION:
google.com.		3600	IN	TXT	"docusign=[code]"
google.com.		3600	IN	TXT	"facebook-domain-verification=[code]"
google.com.		3600	IN	TXT	"google-site-verification=[code]"
google.com.		3600	IN	TXT	"apple-domain-verification=[code]"

;; ANSWER SECTION:
twitter.com.		3600	IN	TXT	"google-site-verification=[code]"
twitter.com.		3600	IN	TXT	"adobe-idp-site-verification=[code]"
twitter.com.		3600	IN	TXT	"atlassian-domain-verification=[code]"

;; ANSWER SECTION:
apple.com.		3600	IN	TXT	"adobe-idp-site-verification=[code]"
apple.com.		3600	IN	TXT	"webexdomainverification.8GVC5=[code]"
apple.com.		3600	IN	TXT	"cisco-ci-domain-verification=[code]"

Cela nous permet d’apprendre que Google utilise probablement Docusign pour signer des contrats, que Twitter utilise Atlassian (peut-être pour stocker du code ou de la documentation), que Twitter et Apple utilisent Adobe Enterprise, et enfin, qu’Apple fait des visioconférences en utilisant Cisco Webex.

Tous ces éléments nous aident à mieux comprendre ce qu’utilise notre cible, et où nous pourrions creuser pour essayer de trouver plus d’informations (ou des services à tenter d’exploiter si nous avons l’intention de faire du test d’intrusion).

Informations historiques
#

Nous savons maintenant comment obtenir des informations pour un domaine dans son état actuel, mais il existe un outil supplémentaire qui peut être utile lors d’une enquête : les données historiques. Certains des avantages sont :

  • Même si les informations de contact du WHOIS sont masquées maintenant, il est possible que le propriétaire ne l’ait pas activé lors de la création du domaine.
  • Si nous enquêtons sur plusieurs noms de domaine et essayons d’établir un lien, alors regarder les données historiques pour tous et voir que des données similaires ont changé en même temps peut être un bon indicateur.
  • Cela nous permet d’avoir une idée de l’usage du domaine à un instant t.

Les données historiques étant assez précieuses, la plupart des bons services nécessitent un paiement (et ils ne sont généralement pas bon marché). Quelques options gratuites sont :

  • spyse.com : historique assez complet des entrées DNS et des sous-domaines utilisés
  • whoisrequest.com : ne montre que le changement de serveurs de noms au fil du temps
  • securitytrails.com : données historiques des enregistrements DNS et sous-domaines
  • osint.sh : données historiques WHOIS. Héberge aussi quelques outils utiles
  • viewdns.info : boîte à outils pratique mais peu de données historiques (dans une certaine mesure, le Reverse Whois lookup qui permet de rechercher des domaines par nom de propriétaire)
  • whoxy.com : historique WHOIS gratuit, avec certaines limites de débit
  • whoisology.com : un peu d’historique WHOIS gratuit pour les membres inscrits
  • whoisxmlapi.com : possibilité d’obtenir un peu d’historique WHOIS avec la démo

De plus, il est possible de tirer parti de la WayBack Machine et de services similaires pour interroger des boîtes à outils DNS. Par exemple, le lien suivant permet de voir le WHOIS de Facebook tel qu’il était en 2013. Un inconvénient de cette méthode est que les noms de domaine qui n’appartiennent pas à des services largement utilisés sont moins susceptibles d’être archivés.

Crédits :
#