Skip to content
KitploitKITPLOIT
StrumentiExploitsBlog
Log in
Invia
StrumentiExploitsBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
BIND-9-Cache-Poisoning-PoC---CVE-2025-40778 — Prova di concetto per CVE-2025-40778: avvelenamento della cache DNS di BIND 9 tramite record non richiesti della sezione Additional. | Kitploit
Strumenti/GitHubGitHub/sirbuvladste/bind-9-cache-poisoning-poc---cve-2025-40778
Analisi delle VulnerabilitàExploitSicurezza di ReteApprendimento e FormazioneAnalisi DNSLab e Pratica
GitHubsirbuvladste/bind-9-cache-poisoning-poc---cve-2025-40778

BIND-9-Cache-Poisoning-PoC---CVE-2025-40778

Prova di concetto per CVE-2025-40778: avvelenamento della cache DNS di BIND 9 tramite record non richiesti della sezione Additional.

Vedi Repository
168 mesi faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

PoC dell'avvelenamento della cache di BIND 9 - CVE-2025-40778

Panoramica concettuale

Questa vulnerabilità consente a un attaccante di corrompere la cache DNS di un resolver BIND, costringendo gli utenti legittimi a essere reindirizzati verso indirizzi IP dannosi a loro insaputa.

La logica principale dell'attacco:

L'attacco sfrutta la fiducia. La Vittima si fida del resolver, e il resolver (BIND) si fida delle risposte ricevute dai server autoritativi. Il difetto esiste perché BIND elabora e memorizza nella cache dati non richiesti forniti nella sezione ADDITIONAL di una risposta DNS, anche se quei dati appartengono a un dominio completamente diverso e non richiesto.

Passaggi dell'attacco:

  1. Il setup: L'Attaccante controlla un server DNS autoritativo dannoso per un dominio specifico (ad es. poc.lab). L'Attaccante attende che il resolver target (BIND) interroghi questo dominio.

  2. L'iniezione: Quando il resolver interroga il server dell'Attaccante per poc.lab, l'Attaccante risponde con una risposta legittima per poc.lab ma include una risposta non richiesta nella sezione ADDITIONAL per un dominio diverso (nel nostro esempio è www.hacker.com, ma potrebbe essere qualsiasi dominio legittimo, come facebook.com) che punta a un indirizzo IP dannoso.

  3. L'avvelenamento: A causa della vulnerabilità, il resolver accetta il record "Additional" non richiesto e lo memorizza nella sua cache. Non verifica che l'Attaccante non abbia autorità sul dominio non richiesto.

  4. La query della Vittima: Quando la Vittima successivamente interroga il resolver per il dominio non richiesto (www.hacker.com), il resolver restituisce il record avvelenato dalla sua cache, reindirizzando la Vittima all'indirizzo IP dannoso controllato dall'Attaccante.

[!IMPORTANT]

Punti chiave per questo PoC

Attacco indiretto: La Vittima non comunica mai direttamente con l'Attaccante.

Compromissione dell'ancora di fiducia: La macchina della Vittima funziona correttamente; è l'infrastruttura (DNS) a mentire.

Il meccanismo: L'exploit sfrutta l'elaborazione della sezione Additional per iniettare record mai richiesti.

[!CAUTION]

Questo PoC ha solo scopo educativo. L'uso non autorizzato di queste informazioni per compromettere sistemi è illegale e non etico. Ottenere sempre il permesso prima di testare o sfruttare vulnerabilità su qualsiasi rete o sistema.

Configurazione dell'infrastruttura per questa dimostrazione

Per questa dimostrazione vengono utilizzate le seguenti macchine virtuali (VM):

  • VM Ubuntu 24.0.4 - BIND 9 - 192.168.174.131
  • VM Ubuntu 24.0.4 - Vittima - 192.168.174.128
  • VM Kali 2024.2 - Attaccante - 192.168.174.130

Scaricare e compilare BIND 9.21.12

I comandi seguenti servono per configurare BIND 9.21.12 su un sistema basato su Debian per dimostrare la vulnerabilità CVE-2025-40778.

[!NOTE] Questa dimostrazione usa BIND 9.21.12, una delle versioni affette da questa vulnerabilità.

Altre gamme note di versioni affette includono:

  • 9.11.0 – 9.16.50
  • 9.18.0 – 9.18.39
  • 9.20.0 – 9.20.13
  • 9.21.0 – 9.21.12

I comandi seguenti installeranno le dipendenze necessarie, scaricheranno il codice sorgente di BIND 9.21.12, lo compileranno e lo installeranno sul nostro sistema.

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

Ecco l'output atteso dell'ultimo comando:

> student@student:/usr/local/src/bind-9.21.12$ /usr/local/sbin/named -v
BIND 9.21.12 (Development Release) <id:9bafc35>

Utente e Gruppo + File di Configurazione

Prima di avviare il server BIND, dobbiamo creare un utente e un gruppo dedicati per eseguire il servizio 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

Poiché questa installazione di BIND non include i file di configurazione predefiniti, dobbiamo creare manualmente le directory necessarie:

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

Il passo successivo è creare il file di configurazione principale /etc/bind/named.conf con il contenuto seguente:

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.logging";
include "/etc/rndc.key";

Per la configurazione delle opzioni, creare il file /etc/bind/named.conf.options con il seguente contenuto:

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";
};

Per configurare una zona forward per il dominio poc.lab in modo da inoltrare le query al server DNS dell'attaccante su 192.168.174.130 sulla porta standard 53, dobbiamo modificare il file /etc/bind/named.conf.local come segue:

zone "poc.lab" {
  type forward;
  forward only;
  forwarders { 192.168.174.130; };
};

Per la configurazione del logging, creare il file /etc/bind/named.conf.logging contenente:

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; };
};

Infine, dobbiamo configurare 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

Avvio del server BIND

Per prima cosa, dobbiamo assicurarci che la porta 53 non sia utilizzata da nessun altro servizio (nel nostro caso abbiamo dovuto disattivare systemd-resolved):

sudo systemctl disable --now systemd-resolved || true
sudo ss -lunp | grep ':53' || true  # To verify that port 53 is free

Infine, possiamo avviare il server BIND usando il seguente comando:

sudo /usr/local/sbin/named -g -u named -c /etc/bind/named.conf

[!TIP]

Per verificare che BIND sia in esecuzione correttamente, possiamo usare il seguente comando:

ss -lunpt | grep :53

Configurazione della Vittima

Per la macchina vittima, dobbiamo impostarla affinché usi il server BIND come resolver DNS. Inoltre, dobbiamo disattivare systemd-resolved per evitare conflitti:

sudo systemctl disable --now systemd-resolved

Poi possiamo impostare un server DNS statico usando i comandi:

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

Configurazione dell'Attaccante

Sulla macchina attaccante, dobbiamo eseguire lo script fornito nel repository (attacker.py).

Scarica lo strumento