Uso de la suplantación de DNS de DHCP como arma: guía práctica
Introducción
En la primera parte de esta serie de blogs, hemos presentado un nuevo conjunto de ataques contra dominios de Active Directory que utilizan servidores del protocolo de configuración dinámica de host (DHCP) de Microsoft. Estos ataques permiten a los atacantes falsificar registros DNS en zonas del DNS integrado con Active Directory (ADIDNS) mediante el uso indebido de la función de actualizaciones dinámicas de DNS de DHCP. Exploramos el funcionamiento de la función y destacamos los errores de configuración que los atacantes podrían utilizar para falsificar registros DNS confidenciales.
En esta segunda entrada del blog, pretendemos profundizar en algunos de los detalles técnicos necesarios para explotar esta superficie de ataque. Detallaremos los métodos utilizados para recopilar toda la información necesaria para llevar a cabo los ataques, describiremos algunas limitaciones de los ataques y exploraremos cómo podemos falsificar varios registros DNS haciendo un uso indebido de un comportamiento interesante del servidor DHCP.
Por último, presentamos una nueva herramienta para añadirla a su caja de herramientas. Hemos combinado todo lo que hemos aprendido para crear DDSpoof , una herramienta Python que permite a los equipos de ataque y defensa llevar a cabo y estudiar ataques DNS DHCP. En una sección posterior de esta entrada del blog describiremos cómo se puede utilizar la herramienta en varios escenarios de ataque.
Exención de responsabilidad: DDSpoof puede ayudar a los equipos de seguridad a identificar los riesgos y, al mismo tiempo, concienciar sobre esta superficie de ataque. Sin embargo, la herramienta por sí sola no es suficiente para causar daños reales: requiere acceso a la red y una mayor explotación para hacer un uso indebido de la primitiva de suplantación de DNS.
Enumeración de DHCP
En nuestra publicación anterior, compartimos la teoría que hay detrás de la suplantación de DNS de DHCP. En la práctica, son necesarios diferentes datos para llevar a cabo los ataques descritos de una manera eficaz. Afortunadamente para los atacantes, la capacidad de detectar servidores DHCP y conocer su configuración forma parte del protocolo DHCP, que hace que el proceso de reconocimiento sea sencillo.
En las siguientes secciones, describiremos los diferentes métodos y trucos que los atacantes pueden utilizar desde un contexto no autenticado para recopilar estos diferentes datos.
Identificación de servidores DHCP
La parte más importante de un ataque DNS DHCP es el servidor DHCP objetivo, por lo que el primer paso sería identificar uno. La identificación de servidores DHCP activos en la red es muy sencilla. Un atacante puede enviar una transmisión DHCP Discover e inspeccionar las respuestas Offer de los servidores.
Para enviar mensajes DHCP, podemos ejecutar la utilidad de Linux dhclient , un cliente DHCP configurable que permite la interacción con servidores DHCP. Podemos configurar dhclient editando su archivo de configuración, que está ubicado en /etc/dhcp/dhclient.conf.
Cuando lo ejecutamos, dhclient solicitará la configuración de red del servidor DHCP y la aplicará a nuestra máquina, anulando nuestra dirección IP actual. Para evitarlo, podemos ejecutarlo en una interfaz virtual con la siguiente sintaxis:
dhclient <interface_name>:<virtual_interface_name>
Después de ejecutar este comando, podemos ver que nuestra dirección IP original (172.25.14.55) permanece sin cambios, mientras que nuestra interfaz virtual ha recibido una nueva dirección IP del servidor DHCP (Figura 1).
Fig. 1: Uso de dhclient en una interfaz virtual y mantenimiento de nuestra IP original
Si registramos el tráfico e inspeccionamos los mensajes DHCP Offer, podremos identificar todos los servidores DHCP activos (Figura 2).
Fig. 2: Envío de DHCP Discover para identificar los servidores DHCP activos en la red
Obtención de un dominio y un servidor DNS del servidor DHCP
Después de identificar los servidores DHCP de la red, necesitamos saber qué registros se pueden falsificar a través de cada servidor. Un servidor DHCP solo puede crear registros dentro de su zona ADI asociada; un servidor asociado al dominio "aka.test" solo podrá escribir registros DNS con el mismo sufijo: <nombre_de_host>.aka.test. Para entender qué registros podemos falsificar, debemos identificar este sufijo.
Además, nos gustaría saber qué servidor DNS alojará los nuevos registros, lo que nos permitiría consultarlos y verificar el éxito del ataque.
Una treta que los atacantes pueden utilizar para averiguar estos dos parámetros es la opción de lista de solicitudes de parámetros, que permite consultar al servidor DHCP ajustes específicos. Para nuestros propósitos, podemos consultar las opciones asociadas Domain Name y Domain Name Server.
Podemos volver a utilizar dhclient. Para agregar la opción de lista de solicitudes de parámetros a nuestro mensaje Discover, incluimos la siguiente línea en el archivo de configuración de dhclient:
request domain-name, domain-name-servers;
Cuando ejecutamos dhclient (como en el caso anterior, en una interfaz virtual) e inspeccionamos nuestro mensaje Discover, podemos ver que incluye la opción de lista de solicitudes de parámetros con los campos que hemos solicitado (Figura 3).
Fig. 3: Lista de solicitudes de parámetros dentro de un mensaje DHCP Discover
Un servidor Microsoft DHCP de escucha debe enviar una respuesta Offer a este mensaje Discover con los parámetros solicitados (Figura 4).
Fig. 4: Respuesta del servidor DHCP con los ajustes que hemos solicitado
Deducción del estado de la protección de nombres
Otro ajuste que es importante al intentar abusar de las actualizaciones dinámicas de DNS de DHCP es la protección de nombres, ya que esta determinará si son posiblesdeterminados ataques de sobrescritura . No podemos consultar el estado de la protección de nombres directamente, pero hay una forma sencilla de deducirlo en cuatro pasos.
Cree un registro DNS mediante una actualización dinámica de DNS de DHCP
Compruebe que se ha creado un registro A
Consulte el servidor DNS si hay un registro DHCID con el mismo nombre
Si hay un registro DHCID junto con el registro A, quiere decir que la protección de nombres está activada
Para invocar una actualización dinámica de DNS de DHCP mediante dhclient, añadimos las siguientes líneas al archivo de configuración:
send fqdn.fqdn = “kali.aka.test”;
send fqdn.server-update on;
send dhcp-server-identifier 172.25.14.123;
Las dos primeras líneas añaden la opción de FQDN con el indicador Server, que es necesario para que el servidor DHCP registre el registro DNS por nosotros. La tercera línea es opcional y nos permite añadir una opción Server Identifier de DHCP para atacar un servidor DHCP específico en los casos en los que haya varios.
Después de ejecutar dhclient, podemos utilizar nslookup para consultar el servidor DNS objetivo y buscar un registro DHCID (Figura 5).
Fig. 5: Comprobación del estado de protección de nombres con nslookup
En este caso, podemos ver que se ha creado un registro DHCID, lo que indica que la protección de nombres está activada.
Deducción de la configuración de las actualizaciones dinámicas de DNS de DHCP
Hay tres opciones que determinan en qué casos el servidor DHCP creará registros DNS para los clientes (Figura 6). Saber qué ajuste se está utilizando puede permitir a los atacantes rastrear las solicitudes DHCP e identificar las que conducen a la creación de un registro gestionado. De esta manera, los posibles objetivos para la sobrescritura de registros gestionados (falsificación de registros creados por el servidor DHCP) puede ser identificados.
Los tres ajustes posibles son:
Actualizar de forma dinámica solo si lo solicita el cliente. Esta es la opción predeterminada, que solo creará un registro DNS si hay una opción FQDN presente en la solicitud y se ha definido el indicador de servidor.
Actualizar siempre de forma dinámica. Se crea un registro DNS para cualquier solicitud DHCP con una opción FQDN, independientemente del valor del indicador de servidor.
Actualizar de forma dinámica para clientes que no solicitan actualizaciones. Cree un registro DNS para los clientes incluso cuando la opción FQDN no esté presente (el FQDN se basa en la opción de DHCP de nombre de host). El objetivo es admitir clientes DHCP antiguos que no utilizan la opción FQDN.
Fig. 6: Ajustes de actualización dinámica de DNS de DHCP
Podemos deducir este ajuste inspeccionando sus "efectos secundarios": Activaremos una actualización dinámica de DNS de DHCP en las diferentes condiciones y consultaremos al servidor DNS para comprobar si se ha creado un registro. Esto se puede llevar a cabo utilizando dhclient para arrendar una dirección IP y utilizar nslookup para consultar el servidor DNS.
La configuración de dhclient necesaria para probar cada uno de los ajustes posibles es la siguiente:
Crear registros para los clientes que no soliciten actualizaciones
# Only include the hostname option, without the FQDN option
send host-name = “test.aka.test”;
send dhcp-server-identifier 172.25.14.123;
Crear registros siempre (cuando la opción FQDN esté presente)
# Include the FQDN option, without the server update flag
send fqdn.fqdn = “test.aka.test”;
send dhcp-server-identifier 172.25.14.123;
Crear registros solo si lo solicita el cliente
# Include the FQDN option and the server update flag
send fqdn.fqdn = “test.aka.test”;
send fqdn.server-update on;
send dhcp-server-identifier 172.25.14.123;
Limitaciones en la dirección de los registros falsificados
Para que nuestro ataque sea eficaz, necesitamos que los registros de DNS falsificados apunten a nuestra máquina controlada. Con la suplantación de DNS de DHCP, confiamos en el servidor DHCP para crear estos registros DNS. Desafortunadamente, no podemos elegir ninguna dirección IP arbitraria: el servidor DHCP tiene un ámbito definido de direcciones IP internas y se negará a arrendar (y, por tanto, a crear un registro DNS para) cualquier dirección IP fuera de este ámbito.
Por este motivo, existen dos limitaciones en la dirección a la que redirigimos la comunicación:
La dirección no puede estar fuera de la red: No podemos arrendar una dirección IP externa desde el servidor DHCP y, por lo tanto, no podemos utilizar una al realizar la suplantación.
La dirección no puede ser de una máquina con una dirección IP estática: si una máquina tiene configurada una dirección IP estática, es poco probable que esta dirección esté en un grupo de arrendamiento de un servidor DHCP y, por lo tanto, no se puede utilizar al realizar la suplantación.
Dado que tenemos acceso a una máquina interna que puede utilizar una dirección IP dinámica, podemos utilizar cualquier dirección ofrecida por el servidor DHCP para nuestros registros falsificados.
Para asegurarnos de que utilizamos esta misma dirección al realizar acciones adicionales, podemos usar la opción de dirección IP solicitada . Podemos hacerlo añadiendo la siguiente línea a la configuración de dhclient:
send dhcp-requested-address 172.25.14.55;
Escritura de varios registros DNS
Al realizar la suplantación de DNS de DHCP, lo más probable es que deseemos falsificar varios registros DNS en lugar de uno solo, con el objetivo de redirigir el tráfico de tantas víctimas como sea posible. Sin embargo, cuando intentamos apuntar varios registros DNS a la misma IP de destino, nos encontramos un con problema.
Después de que un servidor DHCP haya arrendado una determinada dirección IP a un host, esta no la pueden arrendar otros clientes. Este comportamiento está pensado para evitar conflictos de IP entre diferentes clientes. Cuando se arrienda una dirección IP con un FQDN determinado para realizar un DDSpoof, esta dirección IP se elimina del grupo de direcciones del servidor. Si intentamos arrendar de nuevo la misma dirección IP con un FQDN diferente, el servidor ofrece una dirección diferente (Figura 7).
Fig. 7: Proceso de arrendamiento de DHCP cuando la dirección solicitada está tomada
No podemos resolver este problema liberando el arrendamiento anterior, ya que esto activaría una actualización dinámica de DNS por parte del servidor DHCP para eliminar el registro que se acaba de liberar, y de ese modo eliminaría nuestro registro previamente falsificado (Figura 8).
Fig. 8: La liberación de DHCP invoca la eliminación del registro DNS asociado
En otras palabras, nuestros objetivos son:
Liberar la dirección IP; es decir, eliminar su entrada de arrendamiento del servidor DHCP y devolverla al grupo de direcciones (para que podamos utilizarla para registrar un nuevo registro DNS)
Evitar la eliminación del registro DNS falsificado existente
Encontramos un comportamiento/error interesante que nos permite hacer exactamente eso.
Enviamos un paquete de solicitud DHCP al servidor DHCP que actualmente arrienda nuestra dirección IP con los siguientes parámetros:
La dirección MAC del cliente que se utilizó para solicitar el arrendamiento DHCP existente del servidor
El identificador de servidor de un servidor diferente de nuestro servidor objetivo
Al ver este mensaje de difusión, nuestro servidor DHCP objetivo "asumirá" que estamos solicitando una nueva dirección IP de otro servidor y, por lo tanto, que ya no necesitamos la existente (arrendada). A continuación, eliminará el arrendamiento de IP sin eliminar el registro DNS asociado (Figura 9). No nos queda claro por qué no se elimina el registro DNS; sospechamos que podría tratarse de un error de lógica.
Fig. 9: Eliminación de una entrada de arrendamiento sin eliminar su registro DNS asociado
Veamos esto en acción
Queremos crear dos registros DNS que apunten a la misma IP. Creamos el primer registro utilizando dhclient de la misma manera que hemos descrito anteriormente. Se crea nuestro registro y, si observamos la tabla de arrendamiento del servidor DHCP, podemos ver que el arrendamiento está presente en ella (Figura 10).
Fig. 10: Entrada de la tabla de arrendamiento de DHCP
A continuación, modificamos la opción dhcp-server-identifier dhclient en el archivo de configuración a cualquier otra IP, ejecutamos dhclient de nuevo y vemos que nuestro arrendamiento se ha eliminado.
Después, podemos simplemente ejecutar dhclient de nuevo con un FQDN diferente mientras solicitamos la misma dirección IP y creamos un segundo registro (Figura 11).
Fig. 11: Varios registros DNS de atacante apuntan a la misma dirección IP
Presentación de DDSpoof.py
Hemos combinado todas las capacidades y técnicas que hemos descrito en esta serie de blogs para crear DDSpoof, un kit de herramientas que permite llevar a cabo ataques DNS de DHCP. Esta herramienta Python realiza la enumeración de servidores DHCP, ejecuta comandos DNS de DHCP personalizados e identifica posibles objetivos de suplantación. La funcionalidad de DDSpoof se documenta en este repositorio.
En las siguientes secciones, examinaremos varios escenarios de ataque que se pueden realizar con DDSpoof.
Configuración de DDSpoof
Estamos ejecutando una máquina Kali Linux dentro de nuestra red objetivo sin credenciales de dominio. Primero ejecutaremos DDSpoof para explorar la red e identificar posibles objetivos (especificando qué interfaz usar para enviar y recibir paquetes; Figura 12).
Fig. 12: Enumeración inicial de DDSpoof
Podemos ver que DDSpoof realiza lo siguiente:
Identifica todos los servidores DHCP accesibles y sus configuraciones
Determina el estado de la protección de nombres
Verifica que nuestra dirección IP actual está disponible para su arrendamiento en nuestro servidor objetivo
En este ejemplo, nuestra dirección IP no está disponible para su arrendamiento en nuestro servidor objetivo, por lo que la modificamos manualmente para que sea la que ofrece el servidor (Figura 13).
Fig. 13: Modificación de nuestra dirección IP a una dirección disponible en el servidor DHCP
Ya estamos listos para iniciar la suplantación.
Suplantación de DNS de DHCP
Para realizar nuestra primera suplantación de DNS de DHCP, queremos identificar los intentos fallidos de resolución de nombres y crear registros DNS para ellos que apunten a nuestra máquina. Para ello, usaremos el comando de DDSpoof start-llmnr. Este comando inicia un rastreador LLMNR que nos notificará las consultas LLMNR de la red, lo que podría conducirnos hasta posibles objetivos de suplantación (Figura 14).
Fig. 14: Uso del rastreador LLMNR de DDSpoof para identificar objetivos de suplantación
Aquí podemos ver que el rastreador ha podido identificar el nombre files.aka.test. A continuación, podemos usar el comando write-record para intentar registrar este nombre DNS (Figura 15).
Fig. 15: Uso de DDSpoof para falsificar un registro DNS para el nombre de objetivo
Como podemos ver, DDSpoof crea correctamente este registro DNS, apuntando a nuestra dirección IP. Podemos verificarlo con nslookup (Figura 16).
Fig. 16: Uso de nslookup para confirmar que el registro se ha creado correctamente
La siguiente vez que un host de la red intente resolver el nombre files.aka.test, será dirigido a nuestra máquina controlada.
Cuando hayamos terminado nuestro ataque, podremos utilizar el comando delete-record para eliminar nuestro registro falsificado (Figura 17).
Fig. 17: Uso de DDSpoof para eliminar nuestro registro falsificado
Sobrescritura de DNS de DHCP
Otra opción que tenemos es la sobrescritura de DNS de DHCP. Si miramos de nuevo la Figura 12, podemos ver que nuestro servidor DHCP objetivo también es un servidor DNS. Esto sugiere que el servidor también puede ser un controlador de dominio (DC), ya que el servidor DNS se suele instalar en un DC en entornos de Active Directory. Podemos verificarlo mediante el siguiente comando nmap:
Nmap -p389 -sV 172.25.14.123
Fig. 18: Resultado de nmap que confirma que el servidor es un controlador de dominio
Si no se ha configurado una credencial de DNS, podemos sobrescribir cualquier registro en la zona ADI. Supongamos que identificamos un host denominado file-server.aka.test (Figura 19).
Fig. 19: Resultados de nslookup para file-server.aka.test
Podemos intentar sobrescribir su registro DNS mediante el comando de DDSpoof write-record . Si se ha configurado una credencial de DNS débil, esto debería fallar. Pero, en este caso, no se ha configurado una credencial de DNS débil, por lo que nuestra sobrescritura se realizó correctamente (Figura 20).
Fig. 20: Uso de DDSpoof para realizar una sobrescritura de DNS de DHCP del registro DNS del servidor de archivos
Fig. 21: Uso de nslookup para confirmar que la sobrescritura se ha realizado correctamente
Elusión de la protección de nombres
En otro escenario, ejecutamos el comando de DDSpoof start-dhcp , que rastrea el tráfico DHCP identificando los mensajes de solicitud DHCP (Figura 22).
Fig. 22: Uso del rastreador DHCP de DDSpoof para identificar posibles registros gestionados
En este ejemplo, identificamos una máquina denominada ubuntu-server.aka.test que envió una solicitud DHCP que contenía su FQDN. Esto podría provocar que el servidor DHCP creara un registro DNS para este, lo que ofrecería la oportunidad de una sobrescritura de registros gestionados (recuerde que se crea un registro administrado para hosts que no son de Windows, ya que estos no forman parte del dominio y, por lo tanto, no pueden comunicarse directamente con el servidor DNS).
Pero hay un problema. En esta ocasión, nuestro servidor DHCP objetivo ha activado la protección de nombres (Figura 23).
Fig. 23: DDSpoof enumera un servidor DHCP con la protección de nombres activada
Si consultamos todos los registros DNS de nuestro objetivo ubuntu-server.aka.test, vemos que efectivamente contiene un registro DHCID (Figura 24).
Fig. 24: Salida de nslookup que contiene un registro DHCID
Pero no hay que preocuparse porque, como ya sabemos, la protección de nombres se puede eludir fácilmente.
Para ello, solo tenemos que enviar una liberación de DHCP con un ID de cliente (CID) (básicamente, la dirección MAC del cliente) que coincida con el propietario del registro original. Esto hará que el servidor DHCP elimine el registro.
Para ello, podemos utilizar el comando set-cid . Lo suministramos con el CID de objetivo que hemos obtenido previamente, lo que hace que DDSpoof suplante al cliente DHCP original. Después, podemos ejecutar el comando delete-record para eliminar el registro de nuestro objetivo (Figura 25).
Fig. 25: Uso de DDSpoof para eliminar un registro DNS protegido con protección de nombres
A continuación, podemos simplemente registrar el nombre como propio utilizando el comando write-record (Figura 26).
Fig. 26: Uso de DDSpoof para crear un nuevo registro después de eliminar el original, omitiendo la protección de nombres
Resumen
En los escenarios de ataque que se examinan en esta publicación, mostramos cómo es posible falsificar varios registros DNS en dominios de Active Directory desde un contexto no autenticado. Esta capacidad es muy flexible y los atacantes podrían abusar de ella de diversas formas, entre las que se incluyen:
Atacar a equipos Windows e interceptar la autenticación NTLM o Kerberos, lo que hace posible posteriores ataques de retransmisión o de fuerza bruta
Atacar aplicaciones que ejecutan protocolos no seguros e interceptar datos confidenciales
Atacar registros DNS de servidores de seguridad internos, como antivirus o SIEM, y bloquear el acceso a ellos
Estos son solo unos pocos ejemplos de cómo los atacantes podrían abusar de esta capacidad, entre muchos otros.
Atención: equipos de seguridad
La superficie de ataque expuesta por las actualizaciones dinámicas de DNS de DHCP es muy potente, y puesto que Microsoft no planea abordarlo, es probable que esté aquí para quedarse. Animamos a los equipos de seguridad a utilizar las siguientes herramientas para identificar y mitigar los riesgos de la suplantación de DNS de DHCP (idealmente, antes de que los atacantes se pongan al día):
Invoke-DHCPCheckup: identifique las configuraciones DHCP y DNS en Active Directory
DDSpoof: destaque los riesgos y pruebe su resiliencia a la superficie de ataque de actualización dinámica de DNS de DHCP
