Privilège:
[RÉPONDRE]
DNS est un système de nommage pour les ordinateurs qui traduit les noms de domaine lisibles par l'homme tels que (infosecinstitute.com) en adresses IP lisibles par ordinateur. Cependant, certaines vulnérabilités existent en raison de serveurs de noms DNS mal configurés qui peuvent conduire à la divulgation d'informations de domaine. Il s'agit d'une étape importante de la phase de collecte d'informations lors d'un test d'intrusion ou d'une évaluation de la vulnérabilité. Dans cet article, nous examinerons les domaines suivants.
- Bases du DNS
- Enregistrements de ressources et fichier de zone
- Recherches DNS et recherches DNS inversées
- Compréhension en tapant des jokers
- Transfert de zone DNS
- Force brute DNS
1) Les bases du piratage DNS
Le DNS traduit les noms de domaine humains en adresses IP. En effet, les noms de domaine sont beaucoup plus faciles à retenir que les adresses IP. Ce processus peut s'effectuer via un cache local ou via un fichier de zone présent sur le serveur. Un fichier de zone est un fichier sur le serveur qui contient des entrées pour divers enregistrements de ressources (RR). Ces enregistrements peuvent nous donner beaucoup d'informations sur le domaine. Dans la section suivante, nous examinerons davantage les enregistrements de ressources et le fichier de zone.
Comprenons donc comment fonctionne la résolution DNS. Supposons qu'un utilisateur ouvre un navigateur et tape infosecinstitute.com. Il incombe désormais au résolveur DNS du système d'exploitation de l'utilisateur d'obtenir une adresse IP. Il vérifie d'abord son cache local pour voir s'il peut trouver une entrée pour le nom de domaine interrogé. Le cache contient généralement des mappages d'adresses IP vers des noms d'hôte qui sont enregistrés lors de recherches récentes, de sorte que le résolveur n'ait pas à récupérer l'adresse IP encore et encore. S'il ne trouve pas d'adresse IP dans son cache, il interroge le serveur DNS pour voir s'il a un enregistrement pour celle-ci. Un serveur DNS vous est généralement fourni par votre FAI, ou vous pouvez configurer un serveur DNS manuellement. S'il ne trouve toujours pas d'adresse IP, il passe par un processus ou une requête DNS récursive où il interroge différents serveurs de noms pour obtenir l'adresse IP du domaine.
Faisons une démo rapide. Pour cette démo, nous utiliserons l'outil "nslookup". Entrez simplement les commandes comme indiqué dans l'image ci-dessous.
Introduction à Nslookup
- a) Dans la deuxième ligne, nous définissons type = a. Cela signifie que nous interrogeons les enregistrements A, qui renverront l'adresse IP en échange du domaine que nous interrogeons. Nous examinerons davantage les enregistrements dans la section suivante.
- b) Une fois que nous sommes entrés dans google.com, nous obtenons une sortie indiquant le serveur et l'adresse IP#port. Ce serveur est essentiellement le serveur DNS actuel qui servira notre demande. Dans ce cas, il s'agit de 10.0.1.1 et le numéro de port est 53. En effet, DNS utilise le port UDP 53 pour traiter ses requêtes. Nous pouvons également définir le serveur DNS actuel à l'aide de la commande "adresse IP du serveur"
- c) La troisième ligne de la sortie indique "Réponse ne faisant pas autorité". Cela signifie essentiellement que notre serveur DNS a demandé à un serveur DNS externe d'obtenir une adresse IP. Ci-dessous, nous voyons toutes les adresses IP associées à google.com. C'est généralement le cas des grandes organisations. Ils utilisent plusieurs serveurs pour traiter la demande car un serveur est généralement incapable de gérer toutes les demandes.
2) Enregistrements de ressources et fichier de zone
Un fichier de zone est essentiellement un fichier texte présent sur le serveur hébergeant le domaine qui contient des entrées pour divers enregistrements de ressources. Chaque ligne est représentée par un enregistrement différent. Dans certains cas, ces enregistrements peuvent dépasser une ligne et doivent donc être mis entre parenthèses. Chaque fichier de zone doit commencer par un enregistrement Start of Authority (SOA) contenant le serveur de noms faisant autorité pour le domaine (par exemple, ns1.google.com pour google.com ) et l'adresse e-mail de la personne responsable de la gestion du serveur de noms. Vous trouverez ci-dessous un exemple de fichier de zone.
- $ORIGIN infosecinstitute.com.;Ceci marque le début du fichier
- 86 400 $ TTL ; TTL est de 24 heures, il peut aussi être de 1j ou 1h
- infosecinstitute.com IN SOA ns1.infosecinstitute.com. webmaster.infosecinstitute.com. (
- 2002026801 ; le numéro de série de ce fichier de zone
- 2d ; temps de rafraîchissement pour l'esclave
- 5h ; temps de répétition pour l'esclave
- 2w ; délai d'expiration pour l'esclave
- 1h; temps de cache maximum)
- N.-É. ns1.infosecinstitute.com. ; ns1 est le serveur de noms pour infosecinstitute.com
- N.-É. ns2.infosecinstitute.com. ; ns2 est le serveur de noms de secours pour infosecinstitute.com
- MX 10 mail.infosecinstitute.com. ; serveur de courrier
- ns1A 192.168.1.1 ; Adresse IPv4 pour ns1.infosecinstitute.com
- www CNAME infosecinstitute.com ; http://www.infosecinstitute.com est un alias pour infosecinstitute.com
- ftp EN CNAME http://www.infosecinstitute.com . ; CNAME pour ftp
- courrier A 192.0.3.2 ; Adresse IPv4 pour mail.infosecinstitute.com
b) Nous pouvons également voir les différents enregistrements qui sont présents dans le fichier de zone. La manière générale d'écrire un enregistrement de ressource consiste à écrire le nom de domaine, la classe d'enregistrement, le type d'enregistrement, puis d'autres informations.
Il existe différents types d'enregistrements de ressources dans un fichier de zone. Cependant, nous en aborderons quelques-uns importants
Entrées – Associe une adresse IP à un nom d'hôte. Par exemple 74.125.236.80 pour google.com.
NS Records-délègue la zone donnée pour utiliser le serveur de noms faisant autorité donné. Par exemple, ns1.google.com est le serveur de noms faisant autorité pour google.com.
Les enregistrements MX nous indiquent essentiellement quel serveur est responsable de la réception des e-mails envoyés à ce nom de domaine.
Enregistrements TXT - consistent en un texte librement lisible dans l'enregistrement.
Enregistrements CNAME - Attribue un alias d'un nom à un autre.
Faisons une démo pour clarifier les choses. J'ai intentionnellement ajouté quelques entrées pour cet article sur mon site search-eye.com afin qu'elles ne soient pas disponibles lorsque vous faites cela, mais vous pouvez essayer le même exercice sur d'autres domaines, entrez les commandes comme indiqué dans l'image ci-dessous.
Nslookup détail
a) Dans la première commande de nslookup, j'ai défini le type sur A, ce qui signifie que je veux l'adresse IP d'un domaine spécifique. Comme deuxième commande, j'entre le nom de domaine et j'obtiens l'adresse IP correspondante.b) Dans la troisième commande, j'ai défini le type sur NS car je souhaite trouver les serveurs de noms pour search-eye.com. Entrez le nom de domaine comme quatrième commande et nous obtenons les serveurs de noms correspondants pour le domaine search-eye.com. Veuillez noter que la recherche de serveurs de noms peut nous fournir des informations sur le fournisseur d'hébergement de domaine. Certaines grandes organisations utilisent leurs propres serveurs de noms, par exemple ns2.google.com.
c) Maintenant, je vais définir le serveur actuel sur l'un des serveurs de noms car je souhaite trouver les dernières informations sur le domaine. Veuillez noter que l'interrogation de votre propre serveur DNS peut ne pas toujours vous donner des informations précises. Je règle le type sur MX et saisis à nouveau le nom de domaine. Nous recevrons une liste des serveurs de messagerie responsables du traitement des e-mails envoyés à ce domaine. Le nombre devant eux indique la priorité avec laquelle les messages doivent être chargés. Plus le nombre est faible, plus la priorité est élevée.
d) Ensuite, je mets le type sur CNAME et j'écris le sous-domaine, j'obtiens un nom canonique comme infosecinstitute.com. Cela signifie que toute demande adressée au domaine interrogé (dans ce cas, prateek.searching-eye.com) sera redirigée vers infosecinstitute.com.
Je vais profiter de ce moment pour présenter DIG, qui est un petit outil astucieux, nous pouvons également faire les mêmes requêtes avec DIG. Recherchons les inscrits MX dans le même domaine. Je vous suggère d'essayer de rechercher vous-même d'autres domaines.
3) Recherche DNS et recherche DNS inversée
Recherche DNS
Nous ferons nous-mêmes une recherche DNS pour infosecinstitute.com. Pour ce faire, nous parcourons toute la hiérarchie DNS, des serveurs racine au domaine de premier niveau. Ouvrez un terminal dans Backtrack (vous pouvez utiliser votre propre distribution préférée) et tapez "dig". Vous devez choisir quelque chose comme indiqué dans l'image ci-dessous.
Nous obtenons une liste de serveurs racine DNS. Utilisons ce serveur racine DNS pour interroger infosecinstitute.com. Nous le faisons comme indiqué dans l'image ci-dessous
Faites la 1ère requête
Nous obtenons une liste de serveurs de noms faisant autorité pour le domaine com. Notez le point (.) à la fin, cela en fait un nom de domaine complet ( FQDN ). Utilisons ces serveurs de noms pour interroger à nouveau.Faites la 2ème requête
Nous obtenons maintenant la liste des serveurs de noms faisant autorité pour infosecinstitute.com (qui est ns1.pairnic.com et ns2.pairnic.com). Nous devons maintenant interroger ces serveurs de noms pour obtenir l'adresse IP de Infosecinstitute.comFaites la 3ème requête
Et maintenant, dans la section de réponse, nous pouvons voir que l'adresse IP de infosecinstitute.com est 216.92.251.5. SUCCÈS !Recherche DNS inversée
L'exécution d'une recherche DNS inversée convertit une adresse IP en son nom d'hôte. Pour ce faire, nous devons écrire l'adresse IP dans l'ordre inverse (par exemple, 192.168.1.1 sera 1.1.168.192) puis ajouter ".in-addr.arpa". repentir. Ensuite, nous devons créer une requête d'enregistrement PTR à l'aide de DIG. Faisons une requête DNS PTR pour 216.92.251.5, la commande ici sera "dig 5.251.92.216.in-addr.arpa PTR"
4) Comprendre la saisie générique
Carte générique
Un caractère générique est utilisé pour fournir des réponses pour les sous-domaines qui n'existent pas. Par exemple, disons que nous avons le domaine example.com. Si nous définissons un caractère générique pour *.example.com et lui attribuons la valeur example.com , les requêtes pour tous les sous-domaines inexistants de example.com (par exemple abcd.example , blah.example.com ) pointeront vers example .com . Dans la phase de collecte d'informations d'un test de pénétration de site Web, il est important d'identifier les sous-domaines et leurs adresses IP correspondantes. L'introduction de la fonction de caractère générique limite cela dans une faible mesure.
Ignorer les entrées génériques
Si des caractères génériques sont définis sur un domaine particulier, ils peuvent être contournés pour divulguer des informations sur ses sous-domaines. Cela se fait en forçant brutalement les sous-domaines. Nous avons une liste de mots qui les noms des sous-domaines avec lesquels nous voulons tester le domaine. Nous cinglons ensuite tous ces sous-domaines, si ces domaines se traduisent par une adresse IP autre que l'adresse IP de l'hôte, nous pouvons alors affirmer avec certitude que ce sous-domaine existe réellement. Cependant, il serait préférable de vérifier si les entrées génériques sont autorisées ou non avant la force brute. Pour cela, nous pouvons envoyer un ping à certains sous-domaines aléatoires comme 434234.example.com et voir si son adresse IP est la même que l'adresse IP de l'hôte (example.com dans ce cas). Si tel est le cas pour certains sous-domaines aléatoires, nous pouvons clairement dire que les caractères génériques sont autorisés pour ce domaine. Nous ferons une démo dans la prochaine section.
5) Transfert de zone DNS
Dans les exercices précédents, nous avons vu que chaque domaine est associé à des serveurs de noms faisant autorité. Par exemple, dans le cas de google.com, les serveurs de noms étaient ns1.google.com à ns4.google.com. Ces serveurs de noms sont utilisés pour gérer les demandes liées au domaine google.com. Disons que nous avons un domaine example.com et qu'il a ses deux serveurs de noms comme ns1.example.com et ns2.example.com. Une grande organisation aura généralement plus d'un serveur de noms, de sorte que si l'un tombe en panne pendant un certain temps, l'autre est prêt à le sauvegarder et à gérer les demandes. Typiquement, l'un de ces serveurs sera le serveur maître et l'autre sera le serveur esclave. Ainsi, pour rester synchronisés les uns avec les autres, le serveur esclave doit interroger le serveur maître et récupérer les derniers enregistrés après un certain laps de temps. Le serveur maître fournit au serveur esclave toutes les informations dont il dispose. C'est essentiellement ce qu'on appelle un "transfert de zone". C'est comme demander à un serveur de noms "Donnez-moi tout ce que vous avez". Un serveur de noms correctement configuré ne devrait être autorisé qu'à traiter les demandes de transfert de zone provenant d'autres serveurs de noms du même domaine. Cependant, si le serveur n'est pas configuré correctement, il servira à toutes les demandes de transfert de zone qui lui sont faites sans vérifier le client demandeur. Cela conduit à la fuite d'informations précieuses. Le transfert de zone DNS est parfois désigné par le mnémonique AXFR. Cependant, si le serveur n'est pas configuré correctement, il servira à toutes les demandes de transfert de zone qui lui sont faites sans vérifier le client demandeur. Cela conduit à la fuite d'informations précieuses. Le transfert de zone DNS est parfois désigné par le mnémonique AXFR. Cependant, si le serveur n'est pas configuré correctement, il servira à toutes les demandes de transfert de zone qui lui sont faites sans vérifier le client demandeur. Cela conduit à la fuite d'informations précieuses. Le transfert de zone DNS est parfois désigné par le mnémonique AXFR. Le transfert de zone DNS est parfois désigné par le mnémonique AXFR. Cependant, si le serveur n'est pas configuré correctement, il servira à toutes les demandes de transfert de zone qui lui sont faites sans vérifier le client demandeur. Cela conduit à la fuite d'informations précieuses. Le transfert de zone DNS est parfois désigné par le mnémonique AXFR. Le transfert de zone DNS est parfois désigné par le mnémonique AXFR. Cependant, si le serveur n'est pas configuré correctement, il servira à toutes les demandes de transfert de zone qui lui sont faites sans vérifier le client demandeur. Cela conduit à la fuite d'informations précieuses. Le transfert de zone DNS est parfois désigné par le mnémonique AXFR.
Regardons un exemple de conversion de zone. Nous utiliserons l'outil Fierce qui est présent dans Backtrack par défaut. Fierce est l'un des meilleurs outils d'analyse DNS disponibles. Entrez la commande suivante "perl fierce.pl -dns search-eye.com". Nous obtenons quelque chose qui est montré dans l'image ci-dessous.
Le plus étrange, c'est qu'il découvre d'abord les serveurs de noms de domaine. Il convient ensuite s'ils autorisent les transferts de zone. Parce que l'un des serveurs de noms n'est pas configuré correctement, il permet le transfert de la zone et ce que nous voyons est un dump de toutes les informations (enregistrements, sous-domaines, etc.).
Pourquoi le transfert de zone est-il un problème de sécurité ?
La conversion d'une zone révèle beaucoup d'informations sur un domaine. Cela constitue une partie très importante de la phase de « collecte d'informations » lors d'un test d'intrusion, d'une évaluation de la vulnérabilité, etc. Il y a beaucoup de choses que nous pouvons découvrir en regardant un vidage. Par exemple, nous pouvons trouver différents sous-domaines. Certains d'entre eux peuvent s'exécuter sur différents serveurs. Ce serveur peut ne pas être entièrement corrigé et peut donc être vulnérable. À partir de ce moment, nous pouvons commencer à penser à Metasploit, Nessus, Nmap, etc. et faire une évaluation complète de la vulnérabilité du domaine. Par conséquent, ce type d'informations augmente notre vecteur d'attaque d'une quantité décente qui ne peut être ignorée.
Pour protéger vos serveurs de noms contre la fuite d'informations précieuses, vous devez autoriser le transfert de zone uniquement vers d'autres serveurs de noms du même domaine. Par exemple, ns1.example.com, il ne doit autoriser le transfert de zone que vers ns2.example.com et supprimer toutes les autres demandes.
6) force brute DNS
Les transferts de zone DNS peuvent ne pas toujours fonctionner. En fait, la plupart du temps, cela ne fonctionnera pas. La plupart des serveurs DNS sont correctement configurés et n'autorisent pas les transferts de zone vers chaque client. Bon, qu'est-ce qu'on fait alors ? Réponse simple, la même chose que nous faisons quand rien ne fonctionne, FORCE BRUTE ! Fondamentalement, nous avons une liste de mots contenant une énorme liste d'hôtes. Nous vérifions d'abord les entrées génériques en vérifiant qu'un sous-domaine aléatoire pour, par exemple, 132qdssac.example.com résout la même adresse IP que example.com. Si tel est le cas, nous savons que des caractères génériques sont définis. Nous interrogeons ensuite le domaine en utilisant chaque mot de notre liste de mots. Par exemple, si l' un des éléments du fichier contenant la liste de mots est "annonces", nous créons une requête pour ads.example.com. S'il se traduit par une autre adresse IP, nous sommes sûrs que ce sous-domaine existe réellement. Nous avons donc maintenant des informations sur le nom du sous-domaine et son adresse IP. Si aucun caractère générique n'est défini, nous férons de même et verrons si nous obtenons une réponse du sous-domaine que nous interrogeons. Si nous obtenons une réponse, nous pouvons être sûrs que le sous-domaine existe réellement. Enfin, nous obtenons beaucoup d'informations sur le domaine. Nous avons donc maintenant des informations sur le nom du sous-domaine et son adresse IP. Si aucun caractère générique n'est défini, nous férons de même et verrons si nous obtenons une réponse du sous-domaine que nous interrogeons. Si nous obtenons une réponse, nous pouvons être sûrs que le sous-domaine existe réellement. Enfin, nous obtenons beaucoup d'informations sur le domaine. Nous avons donc maintenant des informations sur le nom du sous-domaine et son adresse IP. Si aucun caractère générique n'est défini, nous férons de même et verrons si nous obtenons une réponse du sous-domaine que nous interrogeons. Si nous obtenons une réponse, nous pouvons être sûrs que le sous-domaine existe réellement. Enfin, nous obtenons beaucoup d'informations sur le domaine.
Voyons cela à travers une démo. Nous utiliserons à nouveau l'outil "Fierce". Fierce est un outil d'analyse DNS très utile et quelque chose que tout le monde devrait avoir dans son arsenal. Fierce vérifiera d'abord si les transferts de zone sont activés ou non, si les transferts de zone sont activés, il affichera toutes les informations et sortira avec plaisir, sinon il utilisera la force brute. Nous devons fournir à Fierce une liste de mots contenant une liste de tous les noms de sous-domaines possibles (par exemple, hôtes, annonces, contrats). Fierce est livré avec un fichier de liste de mots intégrés "hosts.txt" et nous utiliserons le même pour notre démo.
[/RÉPONDRE]
