Falsificación de registros de DNS al explotar actualizaciones dinámicas de DNS de DHCP
Resumen ejecutivo
Los investigadores de Akamai han descubierto un nuevo tipo de ataques contra dominios de Active Directory que utilizan servidores de protocolo de configuración dinámica de host (DHCP) de Microsoft.
Estos ataques podrían permitir que los atacantes falsificaran registros confidenciales del sistema de nombres de dominio (DNS), lo que podría tener diferentes consecuencias, desde el robo de credenciales hasta el riesgo total del dominio de Active Directory. Los ataques no requieren credenciales y funcionan con la configuración predeterminada del servidor de DHCP de Microsoft.
El número de organizaciones afectadas puede ser significativo. El servidor de DHCP de Microsoft es muy popular: se ha observado que se usa en el 40 % de las redes que supervisa Akamai.
Informamos de nuestros hallazgos a Microsoft, pero no se ha previsto ninguna solución.
En esta entrada del blog, detallamos las prácticas recomendadas para configurar el servidor de DHCP de Microsoft de una forma que mitigue estos ataques, y damos a conocer una herramienta para que los administradores de sistemas y los equipos azules detecten configuraciones que supongan riesgos.
En una futura entrada del blog, daremos detalles técnicos sobre la implementación de estos ataques desde el punto de vista del atacante.
Introducción
La capacidad de falsificar registros de DNS resulta muy atractiva para los atacantes, ya que puede tener consecuencias devastadoras, como la exposición de datos confidenciales, el robo de credenciales e incluso la ejecución remota de código.
En esta entrada del blog, examinaremos una superficie de ataque del DNS que se ha investigado muy poco y que se ve expuesta debido a una función de DHCP aparentemente inocua. Al utilizarla, hemos descubierto que los atacantes podrían falsificar registros de DNS en servidores de DHCP de Microsoft de varias maneras; por ejemplo, mediante la sobrescritura no autenticada de registros de DNS arbitrarios.
Además de los flujos de ataque, también describimos en detalle el funcionamiento interno de un servidor de DHCP de Microsoft, su interacción con el DNS y Active Directory, y cómo proteger correctamente estas interfaces. Aunque hay muchos recursos online dispersos (e inexactos) sobre DHCP, creemos que esta entrada de blog es un recurso fiable y exhaustivo sobre este tema que reúne toda la información vital para los encargados de la defensa frente a ataques.
DNS y Active Directory
Todo comienza con Active Directory (AD). El funcionamiento de AD depende en gran medida del DNS. Cada dominio necesita un servidor de DNS que aloje una zona de DNS especial, denominada zona de DNS integrada en Active Directory (ADIDNS) (figura 1). Esta zona se utiliza para alojar registros de DNS de todos los equipos del dominio y los diferentes servicios de AD.
Fig. 1: ADIDNS predeterminado
Los registros de las zonas ADI se gestionan mediante una función de DNS denominada Actualizaciones dinámicas. Esta función permite que cada cliente sea responsable de su propio registro: cuando necesita crear o modificar su registro de DNS, envía una solicitud de DNS especial que incluye los datos que se deben modificar en el servidor (figura 2). Cuando el servidor de DNS recibe esta solicitud, modifica los registros del cliente en consonancia.
Fig. 2: Ejemplo del contenido de una actualización de DNS
Una de las funciones importantes de las actualizaciones dinámicas de DNS es Actualizaciones seguras, diseñada para controlar quién puede modificar cada registro de DNS de la zona. Sin actualizaciones seguras, el servidor de DNS obedece ciegamente cualquier solicitud de actualización, lo que permite a los atacantes sobrescribir con facilidad los registros existentes. Con esta función, de forma predeterminada, el servidor de DNS solo acepta las actualizaciones seguras de las zonas ADI (figura 3).
Fig. 3: Configuración predeterminada de las actualizaciones dinámicas de DNS
Cuando se utiliza la función Actualizaciones seguras, todas las solicitudes de actualización que recibe el servidor se autentican y autorizan en las zonas ADI. Para ello, se utiliza Kerberos. Cuando se envía una actualización al servidor, esta incluye un vale de Kerberos que se usa para autenticar al usuario (figura 4). Para obtener más información sobre el proceso de autenticación de Kerberos a través de DNS, consulte el estudio de Dirk-Jan Mollema sobre la retransmisión de Kerberos a través de DNS.
Fig. 4: Vale de Kerberos dentro de una actualización de DNS
Cada registro de DNS está protegido por una lista de control de acceso (ACL) que determina los derechos de acceso de cada principal. Estos derechos de acceso se definen al crear el registro: cuando un cliente crea un registro de DNS mediante el envío de una actualización dinámica de DNS, a la cuenta del equipo que creó el registro de DNS se le asigna automáticamente la propiedad del registro y se le otorgan permisos sobre este. Normalmente, todos los clientes de DNS usan su propio vale de cuenta de equipo para realizar actualizaciones de DNS. Para autorizar una solicitud de actualización, el servidor de DNS verifica la ACL del registro con respecto al principal autenticado.
En la figura 5 se muestra la ACL del registro de DNS del host "PC.aka.test". La cuenta de equipo creó dicho registro, así que tiene permisos para modificarlo.
Fig. 5: ACL de registro de DNS predeterminada
Otros principales (excepto algunos grupos fuertes incorporados) no deberían tener permisos sobre el registro. Cuando un principal diferente intenta modificar un registro de DNS del que no es propietario o sobre el que no tiene permisos, el servidor rechaza la actualización.
Las zonas ADIDNS pueden ser muy interesantes para los atacantes. En un estudio de Kevin Robertson , de NETSPI, se destacaron algunos ataques interesantes en estas zonas DNS. Queríamos conocer mejor esta superficie de ataque, por lo que empezamos a profundizar en otras funciones relacionadas. Así identificamos una interesante: Actualizaciones dinámicas de DNS de DHCP.
Actualizaciones dinámicas de DNS de DHCP
DHCP es un protocolo de gestión de la red que se usa para asignar automáticamente direcciones IP y otras opciones de red a los clientes. Cuando un cliente se incorpora a una nueva red, intentará acceder a un servidor de DHCP enviando un mensaje de difusión que solicite configuraciones de red. Cuando un servidor de DHCP recibe la solicitud, responde al cliente con una dirección IP asignada.
DHCP es un protocolo muy común que se utiliza en la mayoría de las redes corporativas, y el servidor de DHCP de Microsoft, en particular, es una opción muy popular: observamos que utiliza en el 40 % de las redes de centros de datos que supervisamos.
Aunque los clientes de Windows modernos (Windows 2000 y versiones posteriores) suelen crear sus propios registros enviando actualizaciones dinámicas de DNS, no siempre es así. Los registros de DNS también se pueden crear mediante una función de DHCP denominada Actualizaciones dinámicas de DNS de DHCP. El propósito de esta función es permitir que un servidor de DHCP inscriba registros de DNS en nombre de sus clientes. Cada vez que el servidor de DHCP asigna una dirección IP a un cliente, este puede ponerse en contacto con el servidor de DNS y actualizar el registro de DNS del cliente. Para realizar estas actualizaciones, el servidor de DHCP utiliza (¡sorpresa!) actualizaciones dinámicas de DNS.
La similitud de los nombres puede resultar bastante confusa, así que vamos a aclarar los conceptos:
Función |
Protocolo |
Finalidad |
|---|---|---|
Actualizaciones dinámicas de DNS |
DNS |
Permitir que los clientes de DNS creen o modifiquen registros de DNS en el servidor de DNS. |
Actualizaciones dinámicas de DNS de DHCP |
DHCP |
Permitir que el servidor de DHCP cree o modifique registros de DNS en nombre de sus clientes (los cambios se realizan mediante actualizaciones dinámicas de DNS). |
El proceso de actualización dinámica de DNS de DHCP se muestra en la figura 6.
Fig. 6: Proceso de actualización dinámica de DNS de DHCP
El cliente de DHCP obtiene una dirección IP del servidor de DHCP y le informa de su nombre de dominio completo (FQDN).
El servidor de DHCP envía una solicitud de actualización dinámica al servidor de DNS.
El servidor de DNS valida la solicitud, crea un registro relevante e informa al servidor de DHCP del resultado en una respuesta de actualización dinámica.
Tenga en cuenta que, incluso cuando la función Actualizaciones dinámicas de DNS de DHCP está habilitada, la configuración predeterminada requiere que el cliente especifique explícitamente que se debe crear un registro de DNS en su nombre (figura 7).
Fig. 7: Configuración predeterminada de las actualizaciones dinámicas de DNS de DHCP
Para especificarlo, el cliente debe enviar una opción de DHCP específica. Las opciones de DHCP (figura 8) son campos adicionales que se pueden añadir a un paquete de DHCP y que el cliente y el servidor utilizan para intercambiar información.
Fig. 8: Ejemplo de opciones de DHCP
En nuestro caso, el cliente envía la opción de FQDN, especificada en RFC 4702. Esta opción permite al cliente de DHCP informar al servidor de su FQDN y especificar si debe inscribir un registro de DNS en nombre del cliente. Para ello, el cliente puede utilizar el indicador de servidor, que forma parte de la opción de FQDN. Si se le asigna el valor 1, se indica al servidor que debe crear un registro basado en el FQDN proporcionado (figura 9).
Fig. 9: Solicitud de DHCP con la opción de FQDN
Después de recibir esta solicitud, el servidor de DHCP envía una actualización dinámica de DNS y crea el registro solicitado (figura 10).
Fig. 10: Zona ADI de DNS con el nuevo registro
Esta función es útil, pero actualmente no se suele usar (como se ha indicado, la mayoría de los clientes de Windows modernos simplemente crean sus propios registros). A pesar de ello, los servidores de DHCP de Microsoft tienen esta función habilitada de forma predeterminada, lo que significa que el servidor de DHCP inscribirá un registro de DNS de cualquier cliente que lo solicite.
Tenga en cuenta que las actualizaciones dinámicas de DNS de DHCP no requieren autenticación del cliente de DHCP: cualquier usuario de la red puede arrendar una IP de un servidor de DHCP, por lo que, básicamente, un atacante puede utilizar el servidor de DHCP para autenticarse en el servidor de DNS en su propio nombre. Esto otorga al atacante acceso a la zona ADIDNS sin necesidad de tener credenciales.
Microsoft parece ser consciente de los posibles riesgos que esta función plantea y reconoce algunos de ellos, pero la mayoría de los atacantes y los encargados de la defensa desconocen esta superficie de ataque.
En las secciones siguientes se detallan los ataques que podrían realizarse explotando las actualizaciones dinámicas de DNS de DHCP.
Suplantación de DNS de DHCP
Existen ataques de suplantación de ADIDNS descritos anteriormente que se han aprovechado del ADIDNS para mejorar los ataques clásicos de suplantación de resolución de nombres de multidifusión de vínculo local (LLMNR) o reflexión de servidor de nombres NetBIOS (NBNS) . Después de identificar intentos fallidos de resolución de nombres ("hosts inactivos"), un atacante podría registrar el nombre en la zona ADI para que los futuros intentos de resolución de nombres apuntaran al equipo del atacante.
Este ataque tendría un gran impacto, pero tiene un requisito previo importante: contar con credenciales de dominio válidas. Al utilizar el servidor de DHCP, podemos omitir este requisito y operar sin credenciales. Simplemente, se puede enviar una actualización dinámica de DNS de DHCP de cualquier FQDN que no exista ya en la zona ADI, y el servidor de DHCP la creará. A esta variación del ataque la llamamos suplantación de DNS de DHCP. Esta técnica también se describe en una entrada de blog escrita por Hans Lakhan, de TrustedSec.
¿Qué nombres de DNS podríamos utilizar para este ataque? De nuevo, según el estudio de Robertson, vemos que algunos candidatos obvios no funcionarían.
El nombre de host del famoso protocolo de detección automática de proxy web (WPAD) se vería bloqueado por la lista de bloqueo de consulta global (GQBL) en el servidor de DNS.
El registro comodín ("*") no se puede crear mediante actualizaciones de DNS dinámicas, por lo que no se puede explotar en este caso.
Sin estos dos candidatos, la opción que queda es identificar los hosts inactivos que son específicos de la red. Podemos identificarlos analizando la red para detectar emisiones de resolución de nombres a través de LLMNR o NBNS. Después de identificar un posible host inactivo, podemos crear un registro de DNS coincidente enviando una actualización dinámica de DNS de DHCP (figura 11).
Fig. 11: Uso de la actualización dinámica de DNS de DHCP para suplantar nombres de hosts inactivos
Un host de la red intenta resolver el nombre "PC.aka.test" y envía una consulta al servidor de DNS.
El servidor de DNS desconoce "PC.aka.test", por lo que responde que ese nombre no existe ("No such name").
A continuación, el host envía una multidifusión LLMNR para intentar localizar "PC.aka.test" en su red de área local (LAN).
El atacante identifica este intento y solicita el arrendamiento de una IP del servidor de DHCP con "PC.aka.test" como FQDN.
El servidor envía una solicitud de actualización dinámica al servidor de DNS y se crea el registro.
Ahora, la próxima vez que un host de la red intente resolver "PC.aka.test", se le redirigirá al atacante. Todo lo que el atacante tiene que hacer ahora es poner en marcha ntlmrelayx.py y esperar a que le lleguen intentos de autenticación.
Este enfoque es mejor que el método de suplantación de LLMNR o NBNS estándar y que la variación de suplantación de identidad de ADIDNS.
La suplantación clásica de LLMNR o NBNS no requiere autenticación, pero se limita a posibles víctimas de una misma LAN (ya que LLMNR o NBNS se basan en transmisiones).
La suplantación de ADIDNS nos permitió atacar a víctimas de fuera de la LAN (ya que DNS funciona en todas las subredes), pero requirió un usuario autenticado.
Las actualizaciones dinámicas de DNS de DHCP ofrecen lo mejor de cada método: el ataque funciona con víctimas de fuera de la LAN y no requiere ninguna autenticación.
Todo esto es fantástico, pero aún se puede mejorar.
Sobrescritura de registros existentes
La creación de registros de DNS inexistentes es muy interesante, pero nos llevó a pensar en otra opción: ¿y si intentamos crear un registro de un nombre de host que ya existe? ¿podríamos sobrescribirlo de alguna manera? Idealmente, no debería ser posible, ¿verdad? Pues…
Hemos identificado casos en los que un atacante no autenticado podría sobrescribir registros existentes. A esta técnica la llamamos sobrescritura de DNS de DHCP. Antes de abordar estos casos, vamos a analizar algunos detalles más sobre el proceso de actualizaciones dinámicas de DHCP.
Tipos de registros de DNS y sus propietarios
En el contexto de los ataques al DNS de DHCP, hay que hacer una distinción importante entre dos tipos de registros de DNS (figura 12). A partir de ahora, utilizaremos los siguientes términos:
Registros de clientes: registros creados directamente por clientes de Windows.
Registros gestionados: registros creados por el servidor de DHCP en nombre de los clientes.
Fig. 12: Tipos de registros de DNS
La diferencia crucial entre estos clientes es su propietario. Como hemos descrito anteriormente en esta publicación, cuando se realiza una actualización de DNS, se crea un registro de cliente y se asigna como propietario del registro al principal que envió la solicitud de actualización. En el caso de los clientes de Windows normales, este principal es la cuenta de equipo del cliente.
Cabría esperar que los registros gestionados también fueran propiedad del cliente solicitante, pero no es así. Cuando el servidor de DHCP envía actualizaciones de DNS en nombre de los clientes, también se autentica mediante su propia cuenta de equipo, que se convierte en la propietaria del registro.
Podemos ver esta diferencia en la figura 12. PC2 es un registro de cliente propiedad del cliente y PC1 es un registro gestionado propiedad del servidor de DHCP.
Las ACL limitan las sobrescrituras de DNS de DHCP
Cuando intentamos realizar una actualización dinámica de DNS de DHCP en un registro existente, en este caso, el registro "PC.aka.test", no lo conseguimos. Se observa un comportamiento interesante: el servidor de DHCP sí envía una actualización de DNS con el FQDN que hemos proporcionado, pero el servidor la rechaza (figura 13).
Fig. 13: Actualización de DNS de DHCP rechazada por el servidor
Esto sucede porque el servidor de DHCP no está autorizado para modificar el registro.
"PC.aka.test" es un registro de cliente , propiedad del principal PC$ . Cuando el servidor de DHCP envía la actualización de DNS, se autentica usando su propia cuenta de equipo: DHCP$. Dado que esta cuenta no tiene permisos sobre el registro, la actualización se rechaza (figura 14).
Fig. 14: Sobrescritura de registro de DNS rechazada
En resumen, los atacantes pueden usar el servidor de DHCP para enviar actualizaciones de DNS arbitrarias, pero los registros de DNS deberían estar a salvo de sobrescrituras debido a sus ACL.
Ahora que conocemos el mecanismo que se supone que evita las sobrescrituras, veamos cómo se pueden realizar de todos modos.
Sobrescritura de registros gestionados
Aunque las sobrescrituras de registros de cliente existentes no funcionan debido a las restricciones de sus ACL, las sobrescrituras de registros gestionados (los creados por DHCP) sí funcionan, ya que el equipo autenticador también es el propietario del registro (figura 15).
Esto es posible porque los servidores de DHCP no comprueban la propiedad del registro de DNS y envían las actualizaciones de DNS de cualquier FQDN solicitado.
Fig. 15: Sobrescritura de registros de DNS de DHCP propiedad del servidor de DHCP
Como podemos ver, el servidor de DHCP realiza una actualización utilizando la misma cuenta propietaria del registro (que es suyo), así que la actualización se lleva a cabo.
Veamos un ejemplo. Iniciamos un servidor Ubuntu que no es parte del dominio y que, por lo tanto, no puede inscribir su propio registro de DNS. En su lugar, pide al servidor de DHCP que lo haga en su nombre (figura 16).
Fig. 16: El servidor de DHCP inscribe un registro de DNS en nombre del servidor Ubuntu
Este registro es propiedad de la cuenta de equipo del servidor de DHCP. Ahora, desde el equipo atacante, solicitamos el mismo FQDN desde servidor de DHCP en el proceso de arrendamiento. Al comprobar la zona de DNS, vemos que la sobrescritura se ha realizado correctamente y que el registro ahora apunta a la IP que se nos ha arrendado (figura 17).
Fig. 17: Registro de DNS sobrescrito del servidor Ubuntu
Este ataque está bien, pero su impacto es bastante limitado, ya que solo afecta a los registros gestionados. Como hemos mencionado antes, estos registros son mucho menos comunes que los registros de cliente, que no se ven afectados por este ataque. A pesar de ello, los registros gestionados se pueden encontrar en algunos casos en los que el cliente no puede inscribir su propio registro. Por ejemplo, en:
Clientes ajenos a Windows
Clientes de Windows heredados
Clientes de Windows en los que se han deshabilitado las actualizaciones de DNS de cliente
Autosobrescritura de DHCP
Para aumentar el potencial de impacto, queremos sobrescribir los registros presentes en cualquier zona ADI: los registros de cliente. El problema es que estos registros son propiedad de los equipos que los crearon y solo podemos realizar la autenticación usando la cuenta de equipo del servidor de DHCP.
Sin embargo, ¿y el registro de DNS del servidor de DHCP? Cuando el servidor de DHCP crea su propio registro de DNS, su cuenta de equipo se convierte en la propietaria del registro. Resulta que podemos hacer que el servidor de DHCP realice la sobrescritura de DNS de DHCP sobre sí mismo. Si proporcionamos el nombre del servidor de DHCP como FQDN, el servidor de DHCP enviará una actualización de DNS para su propio registro de cliente y la sobrescritura se podrá llevar a cabo.
La figura 18 muestra este flujo de ataque.
Fig. 18: Sobrescritura de DNS de DHCP del registro de DNS del servidor de DHCP
Este ataque es más fiable: si hay un servidor de DHCP de Microsoft presente en la red, seguro que habrá un registro de cliente coincidente para él, mientras que los registros gestionados (necesarios con el método de sobrescritura anterior) son menos habituales.
En cuanto al impacto, los atacantes podrían interceptar cualquier comunicación destinada al servidor de DHCP. La gravedad dependería de la naturaleza de este tráfico. En la mayoría de los casos, se podría explotar la capacidad de interceptar la comunicación destinada al servidor de DHCP para obtener credenciales y retransmitirlas, o bien para capturar tráfico confidencial de otros servicios que podrían estar instalados en el servidor.
Hablando de servicios importantes: ¿y si el servidor de DHCP está instalado en un controlador de dominio (DC)? ¿se podría sobrescribir el registro de DC? Pues resulta que sí.
Sobrescritura arbitraria en el DC de DHCP
Si el servidor de DHCP está instalado en un DC, podemos realizar una sobrescritura de DNS de DHCP en el propio registro del DC (debido a las razones descritas anteriormente en esta publicación). Eso puede ser muy útil, pero podemos hacer mucho más.
Como ya sabemos, si el servidor de DHCP está instalado en un DC, la cuenta de equipo del DC se utilizará al enviar actualizaciones de DNS. Curiosamente, si inspeccionamos la ACL predeterminada de un registro de DNS arbitrario, veremos que el principal ENTERPRISE DOMAIN CONTROLLERS tiene permiso de escritura sobre todos los registros de DNS de la zona, independientemente de quién los haya creado (figura 19).
Fig. 19: ACL predeterminada de todos los registros de dominio que contienen el grupo ENTERPRISE DOMAIN CONTROLLERS
Esto tiene un impacto enorme. Cuando el servidor de DHCP es un DC, tiene permisos sobre todos los registros de la zona, y los atacantes podrían utilizarlo para sobrescribir cualquier registro A de DNS que se encuentre en la zona ADI ¡sin tener que pasar por ninguna autenticación de usuario! Este ataque se ilustra en la figura 20.
Fig. 20: Sobrescritura de DNS de DHCP arbitraria cuando el servidor de DHCP es un DC
Según nuestros datos, esta peligrosa configuración es bastante común: de las redes que hemos observado que utilizan el servidor de DHCP de Microsoft, el 57 % tiene un servidor de DHCP instalado en un DC. Todos estos dominios son vulnerables de forma predeterminada.
Aunque Microsoft reconoce este riesgo en su documentación, creemos que el posible peligro que representa esta carencia de configuración es mucho mayor que el conocimiento que se tiene de ella.
Mitigaciones de los ataques al DNS de DHCP y cómo eludirlas
Todos los ataques descritos hasta ahora se pueden realizar con la configuración predeterminada de los servidores de DHCP de Microsoft. Sin embargo, hay dos ajustes que podrían ayudar a mitigar algunos de ellos. Vamos a explicar cuáles son y cómo se pueden eludir también.
Protección de nombres de DHCP
Como ya sabemos, cuando un servidor de DHCP crea un registro de DNS, no hay nada que impida que otros clientes soliciten el mismo FQDN y obliguen al servidor a sobrescribirlo. Protección de nombres es una función diseñada para evitar que esto ocurra.
La protección de nombres se implementa mediante un tipo de registro de DNS especial: el identificador de cliente de DHCP (DHCID). Al tener habilitada la protección de nombres, cada vez que un servidor de DHCP inscribe un registro en nombre de un cliente, se crea un registro de DHCID adicional (figura 21).
Fig. 21: Registro de DHCID creado por un servidor de DHCP con la protección de nombres habilitada
Como se puede ver, el valor del registro de DHCID es un fragmento de datos codificados en Base64. Este valor (que analizaremos más adelante en esta publicación) es una firma única destinada a identificar el cliente de DHCP que solicitó la creación o actualización del registro.
Cuando se solicita al servidor de DHCP que modifique un registro de DNS, este calcula el valor DHCID del cliente y envía una actualización de DNS que incluye los datos actualizados junto con ese valor DHCID.
Si el registro no existe todavía en el servidor de DNS, simplemente crea el registro y el registro de DHCID correspondiente. Sin embargo, si existen registros de Host (A) y DHCID, el valor DHCID existente se compara con el enviado por el servidor de DHCP. La actualización solo se realiza si los valores coinciden.
Por lo tanto, básicamente, el registro de DHCID asocia un registro de DNS con el cliente que lo creó. Una vez creada esta asociación, solo el cliente originario podrá realizar modificaciones en el registro.
Elusión de la protección de nombres
Hemos encontrado una forma de eludir la protección de nombres mediante un mensaje de liberación de DHCP, un tipo de mensaje que envían los clientes de DHCP para informar al servidor cuando ya no necesitan la dirección IP arrendada. Para realizar un seguimiento de las direcciones que ha arrendado, el servidor de DHCP mantiene una tabla que almacena las diferentes direcciones, las fechas en las que caducan y el identificador único del cliente que las ha arrendado (figura 22).
Fig. 22: Entrada de la tabla de arrendamiento del servidor de DHCP
El identificador único es simplemente la dirección MAC del cliente. Al recibir un mensaje de liberación de un cliente, el servidor de DHCP busca una entrada existente con una dirección e ID coincidentes y, si la encuentra, la elimina. Cuando las actualizaciones dinámicas de DNS de DHCP están habilitadas, además de liberar la dirección IP, el servidor de DHCP también envía una actualización dinámica de DNS para eliminar el registro de DNS asociado del cliente.
Si podemos enviar un mensaje de liberación de DHCP con un ID único (dirección MAC) que coincida con el ID de nuestro objetivo, el servidor de DHCP eliminará el registro, lo que nos permitirá inscribirlo por nosotros mismos: el único requisito para eludir la protección de nombres es contar con la dirección MAC de la víctima (tenga en cuenta que no es necesario cambiar nuestra dirección MAC real, pues el valor se toma del encabezado DHCP).
Si estamos en la misma LAN que el objetivo, identificar su MAC es bastante sencillo; por ejemplo, podemos encontrarlo enviando una solicitud de protocolo de resolución de direcciones (ARP). Pero ¿y si no estamos en la misma LAN? Tenemos otra opción.
Elusión forzada de la protección de nombres por parte de los registros de DHCID
Los registros de DHCID se definen en RFC 4701, y su algoritmo es bastante simple:
Se concatenan los siguientes valores:
DHCP HTYPE (tipo de hardware). El valor que corresponde a Ethernet es 01.
Opción de ID de cliente de DHCP
FQDN del registro (en formato físico de DNS)
Se cifra el resultado con SHA256
Se añaden bits de datos de DHCID (en la implementación de Windows, este valor es constante)
Se codifica el resultado en Base64
La figura 23 muestra un ejemplo de cálculo de DHCID.
Fig. 23: Ejemplo de cálculo de DHCID
Puesto que sabemos que el FQDN y los bits de datos son constantes, la única variable es el ID de cliente, que vuelve a ser la dirección MAC del cliente.
Los registros de DHCID son registros de DNS normales, por lo que cualquier cliente puede consultar su valor al servidor de DNS. Dado que conocemos el algoritmo para calcular un registro de DHCID, podemos iterar todas las direcciones MAC posibles, calcular su valor DHCID y comparar cada resultado con nuestro registro objetivo. Cuando se obtenga una coincidencia, sabremos que hemos encontrado la dirección MAC correcta. Esto permite a los atacantes obtener la dirección MAC por la fuerza en un tiempo razonable: un equipo moderno y dedicado podría descifrar 248 posibles direcciones MAC en tan solo unos días. Podemos reducir este plazo drásticamente si solo utilizamos ID de proveedores comunes. En la figura 24 se puede ver un ejemplo de este proceso.
Fig. 24: Eliminación de un registro de DNS protegido por Protección de nombres
El código al que se hace referencia se puede utilizar para calcular el valor DHCID en función de los parámetros especificados.
Mitigaciones derivadas de la protección de nombres
La protección de nombres de DHCP está destinada a los registros gestionados. Básicamente, el servidor de DHCP protege los registros que creó para que un cliente aleatorio no pueda modificarlos. La protección de nombres no tiene nada que ver con los registros de clientes.
A pesar de ello, en algunos casos, la protección de nombres puede mitigar los ataques contra los registros de clientes.
Al actualizar registros de DNS con la protección de nombres habilitada, el servidor de DHCP requiere la presencia de un registro de DHCID. Dado que los clientes de DNS normales no crean registros de DHCID, no acompañan a los registros de los clientes. Por tanto, los intentos de actualizar un registro de cliente desde un servidor de DHCP fracasarán (figura 25).
Fig. 25: Rechazo de la actualización de DNS cuando no existe un registro de DHCID
Esto sucede debido a la forma en que se implementa la protección de nombres. Cuando un servidor de DHCP con la protección de nombres habilitada envía una actualización de DNS, se añade el campo de requisitos ("Prerequisites") a la solicitud. Este campo especifica las condiciones que deben cumplirse en el servidor de DNS para que se aplique la actualización de DNS. En la figura 26, podemos ver que la actualización de DNS enviada por el servidor de DHCP incluye un requisito para el valor DHCID.
Fig. 26: Requisitos de actualización de DNS
Esto significa que la actualización no se aplicará si no existe un valor coincidente. Puesto que los registros de cliente nunca deben tener un registro de DHCID, si la protección de nombres está habilitada, los registros de cliente deberían contar con una protección frente a las sobrescrituras de DNS de DHCP imposible de eludir. Deberían.
En realidad, esto no forma parte de la protección de nombres en sí (es más bien una consecuencia de dicha función), ya que, por definición, el objetivo de Protección de nombres es proteger únicamente los registros gestionados. Sin embargo, debido a la lógica que acabamos de describir, también puede proteger los registros de los clientes. No obstante, incluso esta defensa accidental se puede eludir.
¿Ámbitos de DHCP al rescate?
En los servidores de DHCP se pueden definir varios ámbitos. Un ámbito es un conjunto definido de direcciones IP de una subred específica que el DHCP puede arrendar (figura 27).
Fig. 27: Ejemplo de ámbitos de DHCP
La división en ámbitos permite gestionar mejor la distribución de direcciones y aplicar diferentes políticas a las distintas subredes. La protección de nombres es una de estas políticas y está habilitada en el nivel de ámbito, lo que significa que los distintos ámbitos pueden tener configuraciones diferentes.
Como mencionamos anteriormente en esta publicación, cuando intentamos sobrescribir un registro de cliente de DNS de DHCP, la solicitud se rechazó porque el arrendamiento procedía de un ámbito de DHCP con protección de nombres. No obstante, es importante tener claro lo siguiente: el concepto de ámbito se corresponde a DHCP. Los registros de clientes no reconocen ni están asociados a ningún ámbito.
Por ello, si obtenemos un arrendamiento de otro ámbito que tenga la protección de nombres deshabilitada, podremos eludir esta mitigación. En esta publicación no se aborda cómo obtener un arrendamiento de otro ámbito que tenga la protección de nombres deshabilitada, pero puede consultar este artículo sobre la opción de retransmisión de DHCP.
Esto significa que, incluso si solo un ámbito del servidor tiene deshabilitada la protección de nombres, debería ser suficiente para que un atacante sobrescriba los registros del cliente (si se da una de las carencias de configuración descritas anteriormente).
Credenciales de DNS
Otro ajuste que se puede configurar en el servidor de DHCP es Credenciales de DNS. Este ajuste nos permite proporcionar las credenciales de un usuario del dominio y que el servidor de DHCP las utilice en lugar de la cuenta de equipo al crear y actualizar registros (figura 28).
Fig. 28: Configuración de credenciales de DNS de DHCP
Volvamos al ejemplo del servidor de DHCP instalado en un DC. Al actualizar los registros de DNS, se utilizó la cuenta de equipo de DC, una cuenta que tiene permisos sobre cualquier registro de la zona. Con credenciales de DNS configuradas, se podría utilizar una cuenta débil en su lugar y el ataque dejaría de surtir efecto.
Configurar credenciales de DNS es muy importante, ya que permite reducir la superficie de ataque que expone el servidor de DHCP. Debería poder mitigar los ataques más graves descritos anteriormente.
Sin embargo, hay dos detalles que debe tener en cuenta al utilizar esta función:
las credenciales configuradas deben ser de un usuario débil. Si usamos las de un administrador de dominio, por ejemplo, el servidor de DHCP podría sobrescribir registros arbitrarios.
Los registros de DNS creados por el servidor de DHCP seguirían siendo propiedad de las mismas credenciales y siendo vulnerables a la sobrescritura de DNS de DHCP.
Grupo DNSUpdateProxy
Durante nuestra investigación del DHCP de Microsoft y su interacción con DNS, descubrimos otra función que se puede explotar: el grupo DNSUpdateProxy . Este grupo está diseñado para resolver dos problemas relacionados con los permisos de los registros gestionados: el problema del cliente actualizado y el problema del servidor de DHCP múltiple.
Problema de cliente actualizado
Analicemos primero el problema del cliente actualizado: un cliente heredado utiliza inicialmente el servidor de DHCP para inscribir un registro de DNS, pero luego se actualiza a un sistema operativo más reciente que admite actualizaciones dinámicas de DNS. El cliente no puede modificar su registro directamente, ya que dicho registro es propiedad del servidor de DHCP que lo creó.
Para resolver este problema, el servidor de DHCP se puede añadir al grupo DNSUpdateProxy.
Este grupo tiene dos efectos. En primer lugar, cuando sus miembros crean un registro de DNS, la ACL del registro es diferente de los registros gestionados normales: el grupo Authenticated Users recibe el permiso de escritura sobre el registro. Esto significa que cualquier cliente del dominio puede modificarlo (figura 29).
Fig. 29: ACL de registro de DNSUpdateProxy
El segundo efecto es una función de "toma de control de registros": el primer cliente que modifica un registro creado por un miembro de DNSUpdateProxy pasa ser su propietario y puede eliminar el permiso de escritura de los usuarios autenticados. Esto resuelve el problema del cliente actualizado al permitir a los clientes modificar y tomar el control de su propio registro cuando tengan que hacerlo.
Problema de varios servidores de DHCP
El segundo problema surge cuando se necesita que varios servidores de DHCP funcionen conjuntamente. En este ejemplo tenemos dos servidores de DHCP: DHCP1 y DHCP2, y el cliente PC1, que inscribe un registro de DNS a través de DHCP1.
Ahora, imaginemos que DHCP1 se desconecta por algún motivo y que DHCP2 entra en acción. El arrendamiento del cliente caduca, por lo que se pone en contacto con DHCP2 para obtener uno nuevo. Cuando DHCP2 arrienda la nueva IP e intenta modificar el registro de DNS del cliente, la operación falla porque el registro es propiedad de DHCP1 (figura 30).
Fig. 30: Ejemplo de configuración de varios servidores de DHCP
Este problema se puede resolver de nuevo utilizando DNSUpdateProxy gracias a una función adicional de este grupo. Si un miembro de DNSUpdateProxy trata de modificar un registro que es propiedad de otro miembro, la actualización se aplica correctamente debido a la ACL, pero esta vez la ACL y la propiedad no cambian. Esto permite que varios servidores sean "copropietarios" del registro.
Un riesgo de seguridad y un error
A estas alturas, probablemente comprenda que el grupo DNSUpdateProxy supone un riesgo de seguridad: un usuario autenticado podría "robar" cualquier registro creado por miembros de dicho grupo. No se trata de una vulnerabilidad, sino de un uso indebido del diseño de la función. Microsoft reconoce este riesgo.
Además de este problema, hemos identificado otro que deriva de lo que parece ser un error en la implementación de la función de DNSUpdateProxy. Cuando un miembro del grupo crea su propio registro de DNS, se crea con la misma ACL vulnerable, sobre la que los usuarios autenticados tienen permisos de escritura.
La figura 31 muestra un ejemplo. El registro de servidor de DHCP dhcp1.aka.test tiene inicialmente una ACL segura.
Fig. 31: ACL inicial del servidor de DHCP
Podemos ver que la cuenta de equipo tiene permisos sobre ella y que el grupo Authenticated Users no aparece. Ahora, añadimos el servidor al grupo DNSUpdateProxy y activamos una recreación del registro de DNS. Esto puede suceder por varias razones; por ejemplo, si se cambia el nombre del servidor. Una vez que se vuelve a crear el registro de DNS, inspeccionamos su nueva ACL (figura 32).
Fig. 32: ACL vulnerable del servidor de DHCP
Vemos que los usuarios del dominio pueden escribir en el nuevo registro de DNS. Obviamente, esto no es una consecuencia prevista de la función: el objetivo es que los registros gestionados creados por el servidor tengan una ACL modificada, pero el propio registro de cliente del servidor no debería verse afectado.
Mitigación de ataques al DNS de DHCP
Existen muchos riesgos relacionados con las actualizaciones dinámicas de DNS de DHCP. Vamos a resumir todas las configuraciones de servidor posibles y a aprender a mitigar los ataques que acabamos de describir.
Haremos referencia a los dos tipos de registros: los gestionados que crea el servidor de DHCP y los de cliente que crean directamente los clientes de Windows.
Este sería el resumen:
Deshabilite las actualizaciones dinámicas de DNS de DHCP si no las necesita.
Los registros de cliente deberían estar protegidos si configura un usuario débil como credenciales de DNS.
Los registros gestionados no se pueden proteger contra la suplantación con ninguna configuración. Use registros de DNS estáticos para hosts con datos confidenciales que no sean de Windows, si es posible.
No utilice DNSUpdateProxy; use las mismas credenciales de DNS en todos los servidores de DHCP.
Credenciales de DNS
Esta es la mejor manera de mitigar las sobrescrituras de DNS de DHCP en los registros de los clientes. Configure un usuario débil con una contraseña segura específicamente para este fin. Si ejecuta un servidor de DHCP en el DC, esto es vital. Esta configuración no evitará las sobrescrituras de DNS de DHCP en los registros gestionados.
Protección de nombres
En teoría, la protección de nombres debería proteger los registros gestionados; pero, en la práctica, los atacantes pueden eludirla con bastante facilidad. Aun así, debe estar habilitada para dificultar los ataques de sobrescritura.
Aunque la protección de nombres no está pensada para proteger los registros de los clientes, si está habilitada en todos los ámbitos del servidor, mitigaría los ataques de sobrescritura.
Al configurar la protección de nombres en un servidor de DHCP de Microsoft, hay dos formas de aplicarla: en el nivel de servidor o en el nivel de ámbito. Se podría pensar que habilitar la protección de nombres en el nivel de servidor la habilitaría también en los ámbitos existentes, ¿verdad? Pues no es así. Habilitar la protección de nombres en el nivel de servidor solo garantiza que los ámbitos nuevos del servidor se creen con esta función habilitada, pero no se habilita en ámbitos existentes. Es importante comprobar que la protección de nombres esté habilitada en el nivel de ámbito de cada uno de los ámbitos del servidor.
DNSUpdateProxy
No debe utilizar este grupo. Supone un riesgo para la seguridad porque todos los registros creados por sus miembros son susceptibles de sobrescritura.
Si tiene varios servidores de DHCP y desea que funcionen de forma conjunta, debe utilizar las credenciales de DNS en su lugar. Solo tiene que configurar las mismas credenciales de DNS en cada uno de los servidores de DHCP, lo que les permitirá editar los registros del resto.
DNSUpdateProxy solo resulta útil si tiene clientes de Windows NT 4.0 (o versiones anteriores) que planee actualizar pronto. Y, si dispone de algo tan antiguo, probablemente tenga problemas peores que los que plantea DNSUpdateProxy.
Si, por alguna razón, debe utilizar DNSUpdateProxy a toda costa, le recomendamos que cree un registro de DNS estático para cada uno de los miembros del grupo. Un registro estático sería propiedad de la cuenta que lo ha creado, que debería ser diferente de las cuentas de equipo de los distintos servidores. Esto evitaría que los servidores crearan sus propios registros con permisos no seguros.
Suplantación de DNS de DHCP
No hay forma de impedir que los atacantes no autenticados creen registros de DNS no existentes. La única forma de hacerlo sería deshabilitar las actualizaciones dinámicas de DNS de DHCP en todos los servidores de DHCP. En general, si en su entorno no es necesario tener la función Actualizaciones dinámicas de DNS de DHCP habilitada, quizás lo mejor sea deshabilitarla. Así, se evitarán ciertos riesgos y la superficie de ataque se reducirá.
Detección de carencias de configuración con Invoke-DHCPCheckup
Para ayudarle enfrentarse a las complicaciones de las posibles configuraciones de DHCP, lanzamos una herramienta de PowerShell llamada Invoke-DHCPCheckup para identificar los riesgos relacionados con las actualizaciones dinámicas de DNS de DHCP (figura 33).
Fig. 33: Ejemplo de resultado de Invoke-DHCPCheckup
Esta herramienta identifica las siguientes carencias de configuración:
Credenciales de DNS
Las credenciales de DNS no están configuradas.
Las credenciales de DNS configuradas son de un usuario fuerte.
Protección de nombres
La protección de nombres no está habilitada en un ámbito.
La protección de nombres no está habilitada de forma predeterminada en ámbitos nuevos.
DNSUpdateProxy
Mostrar miembros del grupo.
Especificar si los miembros son servidores de DHCP.
ACL de registros débiles
Mostrar los registros que son propiedad de los servidores de DHCP (registros gestionados).
Mostrar los registros que los usuarios autenticados podrían sobrescribir.
Esta herramienta se basa en la API de gestión de servidores de DHCP y su ejecución requiere un usuario fuerte, por lo que la herramienta está destinada principalmente a equipos azules.
Resumen
Informamos de todos nuestros hallazgos a Microsoft, que respondió que todos los problemas mencionados anteriormente son de diseño o no son lo suficientemente graves como para buscarles una solución.
No obstante, discrepamos. El impacto de los ataques que hemos señalado puede ser más que considerable: la capacidad de sobrescribir registros de DNS sin autenticación permite que los atacantes adopten una posición de equipo intermediario en los hosts de dominio. Esto podría exponer con facilidad credenciales e información confidencial, y también posibilitar los ataques de retransmisión, lo que permitiría a los atacantes vulnerar los dominios de AD y hacerse con más privilegios. Las estadísticas que compartimos en esta publicación demuestran lo graves que son las amenazas para muchas redes de centros de datos.
Dado que no se ha planificado ninguna solución para estos problemas, instamos a los encargados de la defensa a analizar sus entornos utilizando Invoke-DHCPCheckup para tratar de localizar las peligrosas carencias de configuración que hemos destacado. Alerta de spoiler: Si aún no ha cambiado la configuración predeterminada, es vulnerable.
No se lo pierda
En una próxima entrada del blog, lanzaremos DDSpoof (DNS DHCP Spoof), una herramienta que implementa todos los ataques que describimos en este artículo. Mostraremos la forma en que los atacantes no autenticados pueden obtener los datos necesarios de los servidores de DHCP; identificar y sobrescribir los registros de DNS vulnerables; y aprovechar esa capacidad para poner en peligro los dominios de AD.
