# DNS Source pour les schémas (DNS cache poisoning, kaminsky poisoning): http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html DNS : permet d'associer des noms de domaines à des adresses IP, mais aussi serveurs de mails, alias, ipv6, résolution des adresses inverses, champs libres comme TXT On est capable d'accéder à DNS dès qu'on a accès à l'adresse IP Recueil d’informations publiques sur l’entité Recueil d’informations “actives” (protocoles réseau) Cartographie du réseau - Découverte des membres - Découverte de la structure Evaluation Maintien de l’accès - **Couche Liaison** - Hôtes connectés sur le domaine de diffusion local - Adressage unique des machines (802.3, 802.11) - Protocoles spécifiques (Spanning Tree Protocol ⇒ permet de savoir les ports actifs sur un switch) - **Couche Réseau** - Routeurs interconnectés formant des réseaux - Adressage internet - Protocoles spécifiques (IGP, EGP, ICMP) - **Couche Transport** - Services transportés et disponibles - Adressage de services (ports) - Protocoles spécifiques (TCP, UDP) - **Couche Application** - Résolution de noms de domaines (DNS) - Résolution inverse d’adresse internet (DNS) - Consultation des données administratives d’allocation d’adresses / de noms de domaines Adressage IP - Chaque responsabilité administrative (ARIN, RIPE NCC, AFRINIC, APNIC, LACNIC, etc.) ont des réseaux en `/8` (et peuvents en avoir plusieurs consécutifs et donc avoir un `/5` - ICANN → IANA → RIR (Regional Internet Registers) [Webupdates](https://apps.db.ripe.net/db-web-ui/query) ```bash nc whois.afnic.fr 43 > enseeiht.fr telnet whois.afnic.fr 43 > enseeiht.fr ``` Problème : il faut avoir la connaissance de l’organisation qui gère le TLD, d’où la commande `whois [enseeiht.fr](http://enseeiht.fr)` qui va automatiquement être capable de trouver l’info 2 types de serveurs DNS : Serveurs DNS qui hébergent les informations Serveurs qui interrogent pour avoir les informations Enregistrement SOA c’est celui qui héberge les infos ```bash dig enseeiht.fr. SOA ``` `axfr` = “donne-moi tout” ```bash dig axfr @ns1.enseeiht.fr. enseeiht.fr ``` Je m’adresse au serveur `ns1.enseeiht.fr.` et je lui demande *tout* Si je veux connaître les nameservers pour le transfert de zone ```bash dig enseeiht.fr NS ``` Demander les nameservers, et on essaye le transfert de zone sur chacun des NS Bureau d’enregistrement DNS - va enregistrer à Afnic ou autre mon nom de domaine - configurer hébergement Transfert de zone - récupérer toutes les informations sur une zone (zone = tout ce qui se situe sous un nom de domaine, on peut aussi créer des sous zones avec la délégation) - ⚠️ les noms sont significatifs !!! si un truc s’appelle “mail” c’est probablement un serveur de mail Si on peut pas faire un transfert de zone il y a quand même plein de méthodes --- 2 protocoles où la sécurité a été rajoutée a posteriori, et l’adoption des méthodes de sécurité est très faible (parce que dans la plupart des cas ça suffit de s’appuyer sur la couche 4 pour sécuriser) Rappel DNS - base de données distribuée (match des enregistrement à des tags = adresses avec points) - Hiérarchie de droite à gauche - `[www.facebook.com](http://www.facebook.com)` est en réalité `www.facebook.com.` - `.` la racine - ensuite `.com` - ensuite `.facebook` - ensuite `www` - Un top-level domain name pour faire de la résolution de domaine - `[0.0.168.192.in-addr.arpa](http://0.0.168.192.in-addr.arpa)` ⇒ nous donne le nom de domaine associé à `192.168.0.0` - fait partie de la spécification DNS (pas un hack / détournement de son utilisation) - CNAME = alias, associe un nom de domaine à un autre nom de domaine - PTR ????? IANA (`.`) > NICs (plusieurs) (`fr, edu, me, etc.`) > Registrars / Bureaux d’enregistrement Nous on communique avec les registrars (Gandi, GoDaddy, etc.) TLD / Nom de domaine de premier niveau = extension (`com, fr, etc.`) | Types de serveurs - Hébergement (bind9, NSD) - “j’ai la base de donnée” - Résolution récursive de noms (unbound, knot) - “je consulte la base de données” | Types de clients - Stub resolvers (débiles, ils font des trucs simple) - dig (fait aussi du débugging) - host - nslookup Bind9 hyper compliqué, ça fait à la fois l’hébergement et la résolution, ils ont pris la RFC ils ont dit “on s’en bat les couilles” Langage rationel : |nom | TTL | classe | type | données| |--|--|--|--|--| |nom de domaine | temps de vie | IP ou autre | type d'enregistrement | données | Enregistrements (type) - `A` → IPv4 - `AAAA` → IPv6 - `NS` → délégation de zone - `MX` → adresse d’un échangeur de mails dans cette zone - `SOA` → adresse du DNS primaire de la zone et mail admin SOA : permet de répliquer Serveurs racines (`.`) il y en a de A à M, 64 par lettres Avoir une BDD centralisée impossible (garder à jour est impossible avec tous les noms de domaines, plus le serveur aurait trop de trafic, congestion réseau) donc → décentraliser, déléguer les zones Pour déléguer on va utiliser le type d’enregistrement `NS` - la racine peut dire “tout ce qui est `fr.`" je m’en occupe pas, je le délègue à ces serveurs DNS) - Ensuite on demande à aux serveurs “qui est responsable de `enseeiht.fr.`" et on récupère le serveur (le *nom de domaine du serveur*) **qui héberge cette zone** - Ensuite on lui demande les l’adresse de `[enseeiht.fr](http://enseeiht.fr)` ou de `albator.enseeiht.fr`, etc. Pour résoudre `[albator.enseeiht.fr](http://albator.enseeiht.fr)` je dois pouvoir résoudre `enseeiht.fr`, `fr` et `.`, je dois avoir leur IP pour les interroger - Première solution - Les serveurs racines (`.`) contiennent les enregistrement `A` de leurs trucs de résolution, et nous on garde ça en dur - À l’enseeiht si on veut se connecter au réseau wifi public mais qu’on a changé notre résolveur récursif local, on va pas pouvoir se connecter → L’enseeiht utilise le résolveur récursif pour MITM la requête et afficher la portail captif DNS → protocole UDP 53 (~2 secondes de timeout) Pas forcément un serveur DNS différent quand j’ai un point, le mec qui héberge [`enseeiht.fr`](http://enseeiht.fr) peut héberger `[albator.enseeiht.fr](http://albator.enseeiht.fr)` ou `[sivuca.leei.enseeiht.fr](http://sivuca.leei.enseeiht.fr)` Les glue records - éviter dépendances cycliques à tous les niveau - si je veux l’ip de `[enseeiht.fr](http://enseeiht.fr)`, je vais demander à l’IANA qui s’occupe de `fr`, puis à l’AFNIC qui a `enseeiht.fr` il va me dire `[ns1.enseeiht.fr](http://ns1.enseeiht.fr)` donc je dois demander à `ns1.enseeiht.fr` mais je connais pas son IP ni celle de `enseeiht.fr`, comment je fais ???? - glue records → l’afnic va se synchroniser périodiquement avec `[ns1.enseeiht.fr](http://ns1.enseeiht.fr)` pour mettre son IP en dur et l'envoyer en plus de la réponse de délégation: "J'ai délégué cette addresse à X et d'ailleurs voila son IP sinon tu vas galérer" ```bash dig albator.enseeiht.fr A +trace +additional +all ``` Cache directement associé au champ TTL, plus le niveau est haut moins on posera de question **Cache négatif :** - je mets en cache les réponses disant “non-existant” ou des trucs comme ça ### Attaques #### Attaque Homographique : on utilise un "A" au lieu d'un "A" ascii toutes les attaques MITM, etc. fonctionnent avec DNS, on va voir une attaque spécifique à DNS - Query ID (un résolveur récursif pose plein de questions, il identifie la réponse si le query ID match et il sait quelle question c’était) #### Empoisonnement du cache DNS: **Empoisonnement simple** :  A l’époque, on avait des port UDP fixe ou dans une petite plage. - le résolveur récursif utilisait le port 53 comme les hébergeurs de zones - logique d’un point de vue raison mais mal niveau sécu → ajd le résolveur récursif utilise un port random (mais tjr 53 pour les hébergeurs) Query ID : identifiant qui est incrémental, le but est de le connaitre pour pouvoir procédé à l’attaque. Pour faire ça, il doit écouter le serveur ns.badguy.com, attendre que l’utilisateur envoie une requete, récupérer le query id, et le prochain sera incrémenté de 1 **déroullé de l'attaque** : - créer un nom de domaine et le demander au solveur pour avoir l'ID actuel - on pose la question au solveur pour qu'il pose la même - gagner la race condition pour répondre au solveur **avant** la réponse légitime et spammer avec l'id actuel + 1,2,3 ... 40  **Empoisonnement à la Kaminsky** : - On va faire un empoisonnement de la délégation de zone (le glue record) en gagnant la race condition ==> protection : Matcher aussi sur le port UDP ### DNSSEC :::info Authenticité (réseau) = Inteǵrité (crypto) ::: On voulait de base se prémunir contre les empoisonnement et on va “accidentellement” se prémunir contre les attaques réseaux vu qu’on va mettre en place une sorte de signature. On va pas protéger la communication mais les données (les lignes dans la zone, c’est ça qui sera protégé) On va vérifier les enregistrement avec les clef publiques. On peut signer plusieurs types ensemble. **Maintenant quand on pose une question on a une signature qui permet de la vérifier.** Une zone va embarquer la clé publique utilisée pour vérifier les enregistrements contenus dans une zone fille (permet non seulement de sécuriser les enregistrements mais la délégation elle-même, créer la chaîne de confiance): ZSK : Zone signature key : signer tout sauf une clef -> la zone est très souvent mise à jour KSK : Key signature key : signer une autre clef Plus on signe, plus on va devoir changer la clé rapidement. Du coup la ZSK (qui signe les zones) va devoir etre regulierement renouveler, d'ou le fait d'utiliser une KSK separer pour signer les cle. ``` enseeiht.fr. NS nic.fr //info habituelle enseeiht.fr. RRSIG // signature avec ZSK fr. de la NS fr. DNSKEY <ZSK fr.> // cle ZSK fr. fr. RRSIG // signature de ZSK fr. avec KSK fr. enseeiht.fr. DS H(KSK enseeiht.fr.) // hash de KSK de la zone fille enseeiht.fr. RRSIG // signature du hash avec ZSK fr. ``` Quand on arrive sur un nouveau DNS, dont on trust la KSK (car fourni et signe par la zone du dessus), on va signer la ZSK avec la KSK pour trust la ZSK qui va etre utiliser dans la suite pour signer tout le reste. :::success Tout le monde a la clef de la racine hardcodée. ::: Ce qui est compliqué c’est comment on change la clé - être capable de dire au serveur au-dessus que la clé a changé - Protocoles de synchro pour ça - On verra détails de mécanisme de révocation de clé en cours de crypto avec Migliore Au lieu qu’une zone aie dans son registre DS un serveur délégué et la clé qu’il utilisera pour signer, on indique une clé qui sera utilisée pour signer la clé qu’il utilisera - Niveau d’indirection supplémentaire qui fait que la durée de vie de la clé de la zone parente n’est pas directement proportionnelle au débit de signature de la zone déléguée, mais de la fréquence de changement de clé de la zone déléguée ```bash dig www.internetsociety.org +dnssec dig +dnssec com. NS ``` DNS flags - AA Authoritative Answer - QR specifies whether this message is a query (0), or a **response** (1) - RD Recursion Desired - RA Recursion Available - AD (Authentic Data): indicates the resolver believes the **responses** to be authentic - that is, validated by DNSSEC Vérifications de protocoles - Proverif (automatique) - Tamarin (non automatique) [BGP](https://notes.ar-lacroix.fr/s/p-z65FX9H) Explication du dig [enseeiht.fr](http://enseeiht.fr) effectué par B. Morgan version Rootme : [https://www.root-me.org/fr/Documentation/Reseaux/Application/Faiblesse-des-serveurs-DNS-par-transfert-de-zone](https://www.root-me.org/fr/Documentation/Reseaux/Application/Faiblesse-des-serveurs-DNS-par-transfert-de-zone)