sirbuvladste/bind-9-cache-poisoning-poc---cve-2025-40778Preuve de concept pour CVE-2025-40778 : empoisonnement du cache DNS de BIND 9 via des enregistrements de section Additionnelle non sollicités.
Cette vulnérabilité permet à un attaquant de corrompre le cache DNS d'un résolveur BIND, forçant les utilisateurs légitimes à être redirigés vers des adresses IP malveillantes à leur insu.
L'attaque repose sur l'exploitation de la confiance. La victime fait confiance au résolveur, et le résolveur (BIND) fait confiance aux réponses qu'il reçoit des serveurs faisant autorité. La faille existe parce que BIND traite et met en cache les données non sollicitées fournies dans la section Additionnelle d'une réponse DNS, même si ces données appartiennent à un domaine complètement différent et non demandé.
La mise en place : L'attaquant contrôle un serveur DNS faisant autorité et malveillant pour un domaine spécifique (par exemple poc.lab). L'attaquant attend que le résolveur cible (BIND) interroge ce domaine.
L'injection : Lorsque le résolveur interroge le serveur de l'attaquant pour poc.lab, l'attaquant répond avec une réponse légitime pour poc.lab mais inclut une réponse non sollicitée dans la section Additionnelle pour un domaine différent (dans notre exemple, il s'agit de www.hacker.com, mais cela pourrait être n'importe quel domaine légitime, comme facebook.com) pointant vers une adresse IP malveillante.
L'empoisonnement : En raison de la vulnérabilité, le résolveur accepte l'enregistrement « Additionnel » non sollicité et le stocke dans son cache. Il ne vérifie pas que l'attaquant n'a aucune autorité sur le domaine non sollicité.
La requête de la victime : Lorsque la victime interroge ensuite le résolveur pour le domaine non sollicité (www.hacker.com), le résolveur renvoie l'enregistrement empoisonné depuis son cache, redirigeant la victime vers l'adresse IP malveillante contrôlée par l'attaquant.
[!IMPORTANT]
Points clés à retenir de ce PoC
Attaque indirecte : La victime ne communique jamais directement avec l'attaquant.
Compromission de l'ancre de confiance : La machine de la victime fonctionne correctement ; c'est l'infrastructure (DNS) qui ment.
Le mécanisme : L'exploit tire parti du traitement de la section Additionnelle pour injecter des enregistrements qui n'ont jamais été demandés.
[!CAUTION]
Ce PoC est à but éducatif uniquement. Toute utilisation non autorisée de ces informations pour compromettre des systèmes est illégale et contraire à l'éthique. Obtenez toujours une autorisation avant de tester ou d'exploiter des vulnérabilités sur un réseau ou un système.
Les machines virtuelles (VM) suivantes sont utilisées dans cette démonstration :
Les commandes suivantes servent à installer BIND 9.21.12 sur un système basé sur Debian afin de démontrer la vulnérabilité CVE-2025-40778.
[!NOTE] Cette démonstration utilise BIND 9.21.12, qui est l'une des versions affectées par cette vulnérabilité.
Les autres plages de versions affectées connues incluent :
- 9.11.0 – 9.16.50
- 9.18.0 – 9.18.39
- 9.20.0 – 9.20.13
- 9.21.0 – 9.21.12
Les commandes suivantes installeront les dépendances nécessaires, téléchargeront le code source de BIND 9.21.12, le compileront et l'installeront sur notre système.
sudo apt install -y build-essential pkg-config perl meson ninja-build libssl-dev libuv1-dev liburcu-dev libcap-dev liblmdb-dev libnghttp2-dev
cd /usr/local/src
sudo wget -O bind-9.21.12.tar.xz https://isc.mirrorservice.org/bind/9.21.12/bind-9.21.12.tar.xz
sudo tar -xf bind-9.21.12.tar.xz
cd bind-9.21.12
sudo meson setup build --prefix=/usr/local --sysconfdir=/etc --localstatedir=/var
sudo ninja -C build
sudo ninja -C build install
echo /usr/local/lib/x86_64-linux-gnu | sudo tee /etc/ld.so.conf.d/bind9-local.conf
sudo ldconfig
ldconfig -p | grep 'libdns-9.21.12' || true
/usr/local/sbin/named -v
Voici la sortie attendue de la dernière commande :
> student@student:/usr/local/src/bind-9.21.12$ /usr/local/sbin/named -v
BIND 9.21.12 (Development Release) <id:9bafc35>
Avant de démarrer le serveur BIND, nous devons créer un utilisateur et un groupe dédiés pour exécuter le service named :
sudo groupadd --system named 2>/dev/null || true
sudo useradd --system --no-create-home --home /nonexistent --shell /usr/sbin/nologin --gid named named 2>/dev/null || true
Cette installation de BIND n'incluant pas de fichiers de configuration par défaut, nous devons créer manuellement les répertoires nécessaires :
sudo mkdir -p /etc/bind
sudo mkdir -p /var/cache/bind
sudo mkdir -p /var/log/named
sudo mkdir -p /var/run/named
sudo chown -R named:named /var/cache/bind /var/log/named /var/run/named
sudo chmod 750 /var/cache/bind /var/log/named /var/run/named
L'étape suivante consiste à créer le fichier de configuration principal /etc/bind/named.conf avec le contenu ci-dessous :
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.logging";
include "/etc/rndc.key";
Pour la configuration des options, créez le fichier /etc/bind/named.conf.options avec le contenu suivant :
options {
directory "/var/cache/bind";
recursion yes;
allow-recursion { 192.168.174.0/24; };
allow-query { 192.168.174.0/24; };
listen-on { 192.168.174.131; 127.0.0.1; };
listen-on-v6 { none; };
dnssec-validation no;
forwarders {
1.1.1.1;
8.8.8.8;
};
minimal-responses no;
// for manual start
pid-file "/var/run/named/named.pid";
};
Afin de configurer une zone de redirection pour le domaine poc.lab qui transmet les requêtes au serveur DNS de l'attaquant à l'adresse 192.168.174.130 sur le port standard 53, nous devons modifier le fichier /etc/bind/named.conf.local comme suit :
zone "poc.lab" {
type forward;
forward only;
forwarders { 192.168.174.130; };
};
Pour la configuration de la journalisation, créez le fichier /etc/bind/named.conf.logging contenant :
logging {
channel queries_file {
file "/var/log/named/queries.log" versions 3 size 20m;
severity info;
print-time yes;
print-category yes;
};
channel default_stderr {
stderr;
severity info;
print-time yes;
print-category yes;
};
category queries { queries_file; };
category default { default_stderr; };
};
Enfin, nous devons configurer RNDC :
sudo /usr/local/sbin/rndc-confgen -a -c /etc/bind/rndc.key
sudo chown root:named /etc/bind/rndc.key
sudo chmod 640 /etc/bind/rndc.key
Tout d'abord, nous devons nous assurer que le port 53 n'est pas utilisé par un autre service (dans notre cas, nous avons dû désactiver systemd-resolved) :
sudo systemctl disable --now systemd-resolved || true
sudo ss -lunp | grep ':53' || true # To verify that port 53 is free
Enfin, nous pouvons démarrer le serveur BIND à l'aide de la commande suivante :
sudo /usr/local/sbin/named -g -u named -c /etc/bind/named.conf
[!TIP]
Pour vérifier que BIND fonctionne correctement, nous pouvons utiliser la commande suivante :
ss -lunpt | grep :53
Pour la machine victime, nous devons la configurer pour utiliser le serveur BIND comme résolveur DNS. De plus, nous devons désactiver systemd-resolved pour éviter les conflits :
sudo systemctl disable --now systemd-resolved
Ensuite, nous pouvons définir un serveur DNS statique à l'aide des commandes :
sudo rm -f /etc/resolv.conf
sudo nano /etc/resolv.conf
> nameserver 192.168.174.129
> options timeout:1 attempts:1
sudo chattr +i /etc/resolv.conf #block overwrites
Sur la machine de l'attaquant, nous devons exécuter le script fourni dans le dépôt (attacker.py).
Dans notre scénario, l'attaquant contrôle le domaine poc.lab. Lorsqu'on lui demande ce domaine ou l'un de ses sous-domaines, il ajoute un enregistrement de réponse non sollicité (www.hacker.com) pointant vers son adresse IP.
Lorsque la victime interroge le domaine poc.lab, le serveur BIND transmet la requête au serveur DNS de l'attaquant. L'attaquant répond avec un enregistrement de réponse non sollicité qui empoisonne le cache du serveur BIND. Lorsque la victime accédera à www.hacker.com, elle sera redirigée vers l'adresse IP de l'attaquant au lieu de l'adresse légitime.
Voici une démonstration de la victime interrogeant les deux domaines :
student@student:~/Desktop$ dig www.poc.lab +noall +answer
www.poc.lab. 60 IN A 192.168.174.99
student@student:~/Desktop$ dig www.hacker.com +noall +answer
www.hacker.com. 60 IN A 192.168.174.130
Comme indiqué ci-dessus, la requête DNS de la victime pour www.hacker.com renvoie l'adresse IP de l'attaquant (192.168.174.130).
[!NOTE]
Cette vidéo est une démonstration de la vulnérabilité expliquée : https://drive.google.com/file/d/1PATD0tUqw8-BipfSf6TkQQfnJBvV110Z/view?usp=sharing