Skip to content
KitploitKITPLOIT
HerramientasExploitsBlog
Log in
Enviar
HerramientasExploitsBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
BIND-9-Cache-Poisoning-PoC---CVE-2025-40778 — Prueba de concepto para CVE-2025-40778: Envenenamiento de caché DNS en BIND 9 mediante registros de sección adicional no solicitados. | Kitploit
Herramientas/GitHubGitHub/sirbuvladste/bind-9-cache-poisoning-poc---cve-2025-40778
Análisis de VulnerabilidadesExplotaciónSeguridad de RedesAprendizaje y EducaciónAnálisis de DNSLabs y Práctica
GitHubsirbuvladste/bind-9-cache-poisoning-poc---cve-2025-40778

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

Prueba de concepto para CVE-2025-40778: Envenenamiento de caché DNS en BIND 9 mediante registros de sección adicional no solicitados.

Ver Repositorio
16hace 8 mesesAún no revisado

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir

PoC de Envenenamiento de Caché de BIND 9 - CVE-2025-40778

Resumen Conceptual

Esta vulnerabilidad permite a un atacante corromper la caché DNS de un Resolver BIND, obligando a los usuarios legítimos a ser redirigidos a direcciones IP maliciosas sin su conocimiento.

La lógica central del ataque:

El ataque se basa en explotar la confianza. La Víctima confía en el Resolver, y el Resolver (BIND) confía en las respuestas que recibe de los Servidores Autoritativos. La falla existe porque BIND procesa y almacena en caché datos no solicitados proporcionados en la sección ADDITIONAL de una respuesta DNS, incluso si esos datos pertenecen a un dominio completamente diferente y no solicitado.

Pasos del Ataque:

  1. La configuración: El Atacante controla un servidor DNS Autoritativo malicioso para un dominio específico (por ejemplo, poc.lab). El Atacante espera a que el Resolver objetivo (BIND) consulte este dominio.

  2. La inyección: Cuando el Resolver consulta el servidor del Atacante por poc.lab, el Atacante responde con una respuesta legítima para poc.lab pero incluye una respuesta no solicitada en la sección ADDITIONAL para un dominio diferente (en nuestro ejemplo es www.hacker.com, pero podría ser cualquier dominio legítimo, como facebook.com) apuntando a una dirección IP maliciosa.

  3. El envenenamiento: Debido a la vulnerabilidad, el Resolver acepta el registro "Additional" no solicitado y lo almacena en su caché. No verifica que el Atacante no tenga autoridad sobre el dominio no solicitado.

  4. La consulta de la Víctima: Cuando la Víctima consulta posteriormente al Resolver por el dominio no solicitado (www.hacker.com), el Resolver devuelve el registro envenenado de su caché, redirigiendo a la Víctima a la dirección IP maliciosa controlada por el Atacante.

[!IMPORTANT]

Conclusiones clave para este PoC

Ataque Indirecto: La Víctima nunca se comunica directamente con el Atacante.

Compromiso del Ancla de Confianza: La máquina de la Víctima funciona correctamente; es la infraestructura (DNS) la que miente.

El Mecanismo: El exploit aprovecha el procesamiento de la Sección Adicional para inyectar registros que nunca fueron solicitados.

[!CAUTION]

Este PoC es solo con fines educativos. El uso no autorizado de esta información para comprometer sistemas es ilegal y poco ético. Siempre obtenga permiso antes de probar o explotar vulnerabilidades en cualquier red o sistema.

Configuración de la Infraestructura para esta demostración

Las siguientes máquinas virtuales (VMs) se utilizan en esta demostración:

  • VM Ubuntu 24.0.4 - BIND 9 - 192.168.174.131
  • VM Ubuntu 24.0.4 - Victim - 192.168.174.128
  • VM Kali 2024.2 - Attacker - 192.168.174.130

Descargar y compilar BIND 9.21.12

Los siguientes comandos son para la configuración de BIND 9.21.12 en un sistema basado en Debian para demostrar la vulnerabilidad CVE-2025-40778.

[!NOTE] Esta demostración utiliza BIND 9.21.12, que es una de las versiones afectadas por esta vulnerabilidad.

Otros rangos conocidos de versiones afectadas incluyen:

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

Los siguientes comandos instalarán las dependencias necesarias, descargarán el código fuente de BIND 9.21.12, lo compilarán y lo instalarán en nuestro 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

Aquí está la salida esperada del último comando:

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

Usuario y Grupo + Archivos de Configuración

Antes de iniciar el servidor BIND, necesitamos crear un usuario y grupo dedicados para ejecutar el servicio 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

Dado que esta instalación de BIND no viene con archivos de configuración predeterminados, necesitamos crear los directorios necesarios manualmente:

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

El siguiente paso es crear el archivo de configuración principal /etc/bind/named.conf con el siguiente contenido:

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

Para la configuración de opciones, cree el archivo /etc/bind/named.conf.options con el siguiente contenido:

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

Para configurar una zona de reenvío para el dominio poc.lab y reenviar las consultas al servidor DNS del atacante en 192.168.174.130 en el puerto estándar 53, necesitamos editar el archivo /etc/bind/named.conf.local de la siguiente manera:

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

Para la configuración de registro, cree el archivo /etc/bind/named.conf.logging que contenga:

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

Finalmente, necesitamos configurar 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

Iniciando el Servidor BIND

Primero, debemos asegurarnos de que el puerto 53 no esté siendo utilizado por ningún otro servicio (en nuestro caso tuvimos que deshabilitar systemd-resolved):

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

Finalmente, podemos iniciar el servidor BIND usando el siguiente comando:

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

[!TIP]

Para verificar que BIND se está ejecutando correctamente, podemos usar el siguiente comando:

ss -lunpt | grep :53

Configurando la Víctima

Para la máquina víctima, debemos configurarla para que use el servidor BIND como su resolvedor DNS. Además, tenemos que desactivar systemd-resolved para evitar conflictos:

sudo systemctl disable --now systemd-resolved

Luego podemos configurar un servidor DNS estático usando los comandos:

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

Configurando el Atacante

En la máquina atacante, necesitamos ejecutar el script proporcionado en el repositorio (attacker.py).

Descargar herramienta