sirbuvladste/bind-9-cache-poisoning-poc---cve-2025-40778Proof of Concept für CVE-2025-40778: BIND 9 DNS Cache Poisoning durch unerwünschte Additional Section records
Diese Schwachstelle ermöglicht es einem Angreifer, den DNS-Cache eines BIND-Resolvers zu korrumpieren, sodass legitime Benutzer ohne ihr Wissen auf bösartige IP-Adressen umgeleitet werden.
Der Angriff nutzt das Ausnutzen von Vertrauen aus. Das Opfer vertraut dem Resolver, und der Resolver (BIND) vertraut den Antworten, die er von autoritativen Servern erhält. Der Fehler besteht darin, dass BIND unaufgeforderte Daten, die im ADDITIONAL-Abschnitt einer DNS-Antwort bereitgestellt werden, verarbeitet und zwischenspeichert, selbst wenn diese Daten zu einer völlig anderen, nicht angeforderten Domain gehören.
Die Vorbereitung: Der Angreifer kontrolliert einen bösartigen autoritativen DNS-Server für eine bestimmte Domain (z. B. poc.lab). Der Angreifer wartet darauf, dass der Ziel-Resolver (BIND) diese Domain abfragt.
Die Injektion: Wenn der Resolver den Server des Angreifers nach poc.lab abfragt, antwortet der Angreifer mit einer legitimen Antwort für poc.lab, fügt aber im ADDITIONAL-Abschnitt eine unaufgeforderte Antwort für eine andere Domain (in unserem Beispiel www.hacker.com, es könnte aber jede legitime Domain wie facebook.com sein) hinzu, die auf eine bösartige IP-Adresse verweist.
Die Vergiftung: Aufgrund der Schwachstelle akzeptiert der Resolver den unaufgeforderten „Additional“-Eintrag und speichert ihn in seinem Cache. Er überprüft nicht, ob der Angreifer Autorität über die unaufgeforderte Domain besitzt.
Die Abfrage des Opfers: Wenn das Opfer später den Resolver nach der unaufgeforderten Domain (www.hacker.com) fragt, gibt der Resolver den vergifteten Eintrag aus seinem Cache zurück und leitet das Opfer auf die bösartige IP-Adresse um, die der Angreifer kontrolliert.
[!IMPORTANT]
Wichtige Erkenntnisse für diesen PoC
Indirekter Angriff: Das Opfer kommuniziert nie direkt mit dem Angreifer.
Kompromittierung des Vertrauensankers: Der Rechner des Opfers funktioniert korrekt; es ist die Infrastruktur (DNS), die lügt.
Der Mechanismus: Der Exploit nutzt die Verarbeitung des Additional-Abschnitts aus, um Einträge zu injizieren, die nie angefordert wurden.
[!CAUTION]
Dieser PoC dient ausschließlich Bildungszwecken. Die unbefugte Nutzung dieser Informationen, um Systeme zu kompromittieren, ist illegal und unethisch. Holen Sie stets die Erlaubnis ein, bevor Sie Schwachstellen in einem Netzwerk oder System testen oder ausnutzen.
Die folgenden virtuellen Maschinen (VMs) werden in dieser Demonstration verwendet:
Die folgenden Befehle dienen der Einrichtung von BIND 9.21.12 auf einem Debian-basierten System, um die Schwachstelle CVE-2025-40778 zu demonstrieren.
[!NOTE] Diese Demonstration verwendet BIND 9.21.12, eine der von dieser Schwachstelle betroffenen Versionen.
Weitere bekannte Bereiche betroffener Versionen sind:
- 9.11.0 – 9.16.50
- 9.18.0 – 9.18.39
- 9.20.0 – 9.20.13
- 9.21.0 – 9.21.12
Die folgenden Befehle installieren die notwendigen Abhängigkeiten, laden den Quellcode von BIND 9.21.12 herunter, kompilieren ihn und installieren ihn auf Ihrem System.
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
Hier ist die erwartete Ausgabe des letzten Befehls:
> student@student:/usr/local/src/bind-9.21.12$ /usr/local/sbin/named -v
BIND 9.21.12 (Development Release) <id:9bafc35>
Bevor wir den BIND-Server starten, müssen wir einen dedizierten Benutzer und eine Gruppe für den Betrieb des named-Dienstes erstellen:
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
Da diese BIND-Installation keine Standardkonfigurationsdateien mitbringt, müssen wir die notwendigen Verzeichnisse manuell erstellen:
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
Der nächste Schritt besteht darin, die Hauptkonfigurationsdatei /etc/bind/named.conf mit folgendem Inhalt zu erstellen:
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.logging";
include "/etc/rndc.key";
Für die Optionskonfiguration erstellen Sie die Datei /etc/bind/named.conf.options mit folgendem Inhalt:
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;
// für manuellen Start
pid-file "/var/run/named/named.pid";
};
Um eine Forward-Zone für die Domain poc.lab einzurichten, die Anfragen an den DNS-Server des Angreifers unter 192.168.174.130 auf dem Standard-Port 53 weiterleitet, bearbeiten wir die Datei /etc/bind/named.conf.local wie folgt:
zone "poc.lab" {
type forward;
forward only;
forwarders { 192.168.174.130; };
};
Für die Logging-Konfiguration erstellen Sie die Datei /etc/bind/named.conf.logging mit folgendem Inhalt:
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; };
};
Abschließend müssen wir RNDC konfigurieren:
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
Zunächst müssen wir sicherstellen, dass der Port 53 nicht von einem anderen Dienst verwendet wird (in unserem Fall mussten wir systemd-resolved deaktivieren):
sudo systemctl disable --now systemd-resolved || true
sudo ss -lunp | grep ':53' || true # Um zu überprüfen, ob Port 53 frei ist
Schließlich können wir den BIND-Server mit folgendem Befehl starten:
sudo /usr/local/sbin/named -g -u named -c /etc/bind/named.conf
[!TIP]
Um zu überprüfen, ob BIND korrekt läuft, können wir den folgenden Befehl verwenden:
ss -lunpt | grep :53
Für die Opfermaschine müssen wir sie so einstellen, dass sie den BIND-Server als ihren DNS-Resolver verwendet. Außerdem müssen wir systemd-resolved deaktivieren, um Konflikte zu vermeiden:
sudo systemctl disable --now systemd-resolved
Dann können wir einen statischen DNS-Server mit den folgenden Befehlen einrichten:
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 # Überschreiben blockieren
Auf der Angreifermaschine müssen wir das im Repository bereitgestellte Skript (attacker.py) ausführen.
In unserem Szenario kontrolliert der Angreifer die Domain poc.lab. Wenn er nach dieser oder einer beliebigen Subdomain gefragt wird, fügt er einen unaufgeforderten Antwortdatensatz (www.hacker.com) hinzu, der auf seine IP-Adresse verweist.
Wenn das Opfer die Domain poc.lab abfragt, leitet der BIND-Server die Anfrage an den DNS-Server des Angreifers weiter. Der Angreifer antwortet mit einem unaufgeforderten Antwortdatensatz, der den Cache des BIND-Servers vergiftet. Wenn das Opfer später auf www.hacker.com zugreift, wird es auf die IP-Adresse des Angreifers umgeleitet, anstatt auf die legitime.
Hier ist eine Demonstration, wie das Opfer beide Domains abfragt:
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
Wie oben gezeigt, gibt die DNS-Abfrage des Opfers nach www.hacker.com die IP-Adresse des Angreifers (192.168.174.130) zurück.
[!NOTE]
Dieses Video ist eine Demonstration der erklärten Schwachstelle: https://drive.google.com/file/d/1PATD0tUqw8-BipfSf6TkQQfnJBvV110Z/view?usp=sharing