INYECCIÓN DE REGISTROS DNS FALSOS UTILIZANDO DHCP

Durante una Prueba de Penetración Interna o Simulación de Ataque Adversario (RedTeam), se desplegará un dispositivo de red falso basado en Linux en la red de un cliente. Estos dispositivos a veces obtendrán una dirección IP a través de DHCP y establecerán una conexión de salida en la que podemos realizar nuestras pruebas.

Cada red de cliente es diferente, pero hemos notado que una configuración común es inyectar automáticamente un registro DNS basado en el nombre de host del host que solicitó una concesión de DHCP. Si bien la configuración más común que hemos encontrado es el servicio DHCP de Windows combinado con el DNS de Windows, estos servicios pueden ser administrados por soluciones de otros proveedores, incluidos Cisco, Juniper, SonicWALL, etc. Como no tengo acceso al equipo anterior, utilizaremos Windows con fines de demostración. Para mi configuración, estoy ejecutando Windows Server 2016 con el servicio DHCP y DNS en el mismo host. Todo está conectado a través de un switch ESXi virtual.

En Microsoft Windows, la siguiente configuración se utiliza para vincular los registros DHCP a los registros DNS para cada nueva concesión de DHCP.

Figura 1 - Configuración de actualización de DNS dinámico

Figura 2: Solicitud de arrendamiento DHCP (DHCP lease) y verificación de un nuevo registro DNS

Figura 3 - Registros DNS generados dinámicamente

Esto me hizo preguntarme, ¿qué pasaría si cambiamos el nombre de host de nuestro dispositivo de red no autorizado a algo malicioso como "wpad" o "*"? Efectivamente, al cambiar el nombre de host de nuestro dispositivo malicioso y esperar el vencimiento/renovación del arrendamiento (DHCP Lease) (a veces con la ayuda de cambiar la dirección MAC de la interfaz), ¡podríamos registrar nuestro registro DNS malicioso! Sin embargo, esto solo funciona si la red del cliente aún no tiene un registro DNS y DHCP con la misma asociación de dirección IP de nombre.

Sin embargo, cuando realizamos este ataque, lo hacemos todo a través de una sesión remota al dispositivo malicioso, por lo que siempre existe la posibilidad de que nos salgamos de la caja accidentalmente si este proceso falla. Tiene que haber una mejor manera.

Figura 4 - Tiene que haber una mejor manera

¿Qué pasaría si pudiéramos transmitir una solicitud DHCP gratuita desde nuestro dispositivo malicioso que incluye un nombre de host falso? ¿Tendría el mismo efecto? ¿Podríamos inyectar un registro DNS malicioso de esta manera sin interrumpir nuestra conexión / arrendamiento actual? (ALERTA SPOILER ¡Si podemos!)

Para comprender cómo funciona este ataque, primero debemos comprender cómo funciona DHCP.

Figura 5 - Protocolo de enlace DHCP

Nuestro cliente (Kali) residirá en una red con solo una dirección MAC y sin una dirección IP aprovisionada. A continuación, al iniciar el cliente, se enviará un paquete DHCP DISCOVER desde la dirección IP de origen 0.0.0.0 y una dirección IP de destino 255.255.255.255. Este paquete incluirá información como la dirección MAC de origen y el nombre de host del dispositivo solicitante.

Figura 6 - Paquete DHCP DISCOVER desde el cliente

A continuación, el servidor DHCP responderá al solicitante con una dirección IP propuesta. Este paquete DHCP OFFER se envía de regreso como una transmisión de Capa 2, pero contiene la dirección MAC del cliente en el cuerpo del paquete. (Curiosamente, durante la prueba, probé diferentes servidores DHCP y descubrí que, si bien el DHCP de Windows responderá usando las direcciones de transmisión de Capa 2, el servidor DHCP de PFSense responderá usando la dirección MAC y la dirección IP propuesta).

Figura 7 - Paquete DHCP OFFER desde el servidor DHCP de Windows

A continuación, el cliente enviará un paquete de solicitud DHCP (DHCP REQUEST), pero esta vez solicitando usar la dirección IP que se le acaba de informar que debe usar.

Figura 8 - Solicitud DHCP (DHCP REQUEST) del cliente

Y si el servidor está de acuerdo con esta solicitud, enviará un paquete DHCP ACK que le indicará al cliente que es bueno usar la dirección IP, así como información adicional como el tiempo de arrendamiento.

Figura 9 - Paquete DHCP ACK del servidor DHCP de Windows

Y eso es. Así es como se solicita y asigna una concesión DHCP típica.

Entonces, lo que debemos hacer es enviar una DHCP DISCOVER/DHCP OFFER desde una dirección MAC falsificada. Usaremos dhtest (https://github.com/saravana815/dhtest). Esta herramienta es como netcat pero para paquetes DNS. Con él, podemos solicitar toda la conversación DHCP mientras falsificamos la dirección MAC.

Figura 10: Envío de una solicitud DHCP falsificada

Figura 11 - Registros de arrendamiento de DHCP de Windows

¡Voilà! Entonces, según el servidor DHCP, tenemos la siguiente asociación. Y mirando nuestro servidor DNS, vemos lo siguiente.

Figura 12 - Registros DNS de Windows

Esto es genial, pero todavía no estamos fuera de peligro. El switch de red al que estamos conectados cree que hay un host con la dirección MAC conectada al mismo puerto que nuestro dispositivo malicioso (o en mi caso, es el servidor DHCP/DNS). Si tuviéramos que enviar un ping a nuestra dirección IP o nombre de host recién asignados, el paquete no se entregará:

Figura 13 - Haciendo ping desde el servidor DHCP/DNS

Figura 14 - Solicitudes ARP sin respuesta

Entonces, lo que podemos hacer en cambio es instalar una interfaz virtual con la misma dirección IP que se nos asignó a través de DHCP. Hacer esto obliga a las tablas ARP y CAM en el switch y otros dispositivos en la red local a actualizar sus tablas para que ahora haya una asociación correcta de dirección MAC a IP.

Figura 15 - Agregando interfaz virtual a Kali

Figura 16 - Actualizaciones de ARP

Figura 17 - Ping exitoso a dispositivo no autorizado

Descaradamente, hemos inyectado con éxito un registro DNS deshonesto que apunta a nuestro dispositivo de red falso sin interrumpir nuestro comando de salida inicial y control. Cabe señalar que este registro será temporal (¡no es necesario desecharlo!). Una vez que la concesión DHCP expire en el servidor, se eliminará junto con el registro DNS correspondiente. Sin embargo, nada lo detiene por enviar un paquete de renovación de DHCP falsificado de vez en cuando.

Espero que la información haya sido de utilidad y en un siguiente post explicaré como bloquear este tipo de ataques.

Para pedirme las imágenes de los laboratorios utilizados, escribirme a:

AyudameEcuador@republik.ec