El uso del protocolo UDP (User Datagram Protocol) para el envío de consultas DNS posibilita el utilizar este servicio para realizar ataques distribuidos de denegación de servicio (DDoS) hacia otros servidores en Internet. Uno de los ataques principales, basado en DNS, es el ataque de Amplificación de DNS o DNS Amplification utilizando consultas de tipo root falsificando la dirección IP de origen, es decir, haciendo un IP Spoofing en el paquete de DNS Request.  

Figura 1: Cómo funcionan los ataques de DDoS usando "Amplificación DNS" con consultas tipo Root sobre UDP y cómo fortificar el servicio

Este tipo de ataques se conocen hace tiempo, y los hemos visto migrados a otras plataformas como LDAP, donde se pueden dar los Ataques DOS con CLDAP (Connectioless LDAP) Amplification, que funciona de forma muy similar. Esto hace que tanto los pentesters y auditores que buscan vulnerabilidades, como los administradores que buscan fortificar los servicios, deban tener en cuenta este tipo de ataques. En FOCA, una de las cosas que miramos es la seguridad de los servidores DNS, ya implementamos hace tiempo otras técnicas como DNS Cache Snooping son también muy útiles en ataques contra infraestructuras empresariales.

La principal debilidad en el servicio DNS frente a este tipo de ataques de amplificación tiene su causa en el uso principal del protocolo UDP (User Datagram Protocol) para realizar las consultas DNS. UDP es un protocolo a nivel de transporte donde prima la velocidad de la transmisión y sobre el cual se envía y recibe la información sin que se haya establecido previamente una conexión y sin confirmación ni control de entrega/recepción. 

Esto posibilita la suplantación de direcciones IP (IP spoofing) y la suplantación de mensajes de consulta/respuesta. Aunque DNS soporta el uso de TCP para el envío de mensajes, en las especificaciones de implementación se recomienda, por motivos de rendimiento, usar UDP en las consultas. Se sugiere limitar el uso de TCP para realizar transferencias de zona o para aquellas consultas que superan el tamaño máximo, establecido en 512 bytes en mensajes sobre UDP.

Búsqueda de servidores DNS vulnerables: Primera aproximación

Buscar un servidor de nombres vulnerable a ataques de amplificación de DNS es sencillo: sólo hay que comprobar si la cantidad de bytes de la respuesta del servidor de nombres es mayor al tamaño de la consulta y obligar a que el protocolo para el intercambio de datos sea UDP.

Figura 4: Petición de transferencia de zona utilizando DIG

Una primera aproximación sería utilizar servidores de nombres vulnerables a transferencia de zona para realizar Ataques de Amplificación de DNS que pudieran desembocar en un DDoS: el tamaño en bytes devuelto por el servidor de nombres al conceder la transferencia de zona (1994 bytes en este ejemplo) es superior al tamaño en bytes de la petición de transferencia de zona (112 bytes en este ejemplo).

Figura 5: Transferencia de zona concedida por el servidor DNS vulnerable

Como contrapartida, el protocolo que se utiliza durante la petición y envío de la transferencia de zona es TCP (Protocolo de Control de Transmisión), lo que dificulta en gran media spoofear la dirección IP de origen al ser un protocolo orientado a la conexión y con ello poder amplificar el tamaño de la respuesta del servidor de nombres sobre una víctima.

Figura 6: Protocolo TCP utilizado en el proceso de transferencia de zona

Además, el número de servidores de nombres vulnerables a transferencia de zona seguramente sea menor que el número de servidores vulnerables a la técnica que veremos en la segunda aproximación: consultas de tipo root sobre UDP y los registros de recursos NS (Name Server).

Búsqueda de servidores DNS vulnerables: Segunda aproximación

Parece evidente la necesidad de utilizar el protocolo UDP (no hay un establecimiento previo de la conexión) para poder spoofear las direcciones IP de origen de las peticiones DNS por la dirección de la víctima, y a la par, utilizar un servidor de nombres con capacidad de amplificar el tamaño de las respuestas frente al tamaño de las consultas DNS. Si se dan todas las condicionantes, entonces se podrían utilizar estos servidores para realizar ataques DDoS amplificando el ancho de banda del atacante para tumbar un servidor de red.

La idea es sencilla: ¿cómo responderá un servidor DNS cuando se realice una consulta de la raíz (“.”) sobre los registros de recursos NS utilizando el protocolo UDP? Si el servidor de nombres no está bien configurado y es vulnerable a consultas de tipo root sobre los registros de recursos NS utilizando el protocolo UDP responderá con el FQDN (nombre de dominio totalmente cualificado) de los 13 servidores DNS de nombres globales.

Figura 8: Respuesta de un servidor DNS vulnerable a técnicas de amplificación

Se puede observar que el tamaño de la consulta de tipo root son 59 bytes frente al tamaño de la respuesta, 270 bytes, lo que demuestra que el servidor de nombres es vulnerable a técnicas de Amplificación de DNS y podría ser utilizado en un ataque coordinado de DDoS.

Figura 9: Características de la respuesta a la consulta de tipo root

Por el contrario, si el servidor DNS no es vulnerable a esta técnica, la respuesta que devolverá al intentar resolver la consulta “.” sobre los registros de recursos name servers será la siguiente:

Figura 10: Tiempo de espera agotado para la petición de resolución de la consulta de tipo root sobre los registros NS

Cómo proteger el servidor de nombres

El problema de denegación de servicio (DoS) utilizando Amplificación DNS se debe a la enorme cantidad de servidores DNS presentes en Internet y configurados como Open Resolvers para ofrecer su servicio sin ningún tipo de restricción a cualquier solicitante de Internet. Por eso, es necesario que cada vez que se instale un servidor DNS expuesto a Internet, ya sea sobre plataformas GNU/Linux o Windows Server, deben ser fortificados.

Si nuestra organización cuenta con servidores de nombres propios con información de las máquinas que tiene desplegadas en Internet, como primera aproximación basta deshabilitar las peticiones recursivas de los reenviadores a los 13 servidores globales que se encuentran en Internet.

Figura 12: Configuración en Windows Server para no utilizar reenviadores ni los 13 servidores DNS globales de Internet. (También hay que hacerlo con los ataques de CLDAP Amplification )

Si un cliente envía una consulta DNS a los servidores de la organización con un FQDN que no se encuentre en su base de datos, el servidor no utilizará los reenviadores para tratar de resolver la petición y la respuesta del servidor será “Se agotó el tiempo de espera de la solicitud a ns.lacomarca.local”. Esta es una comprobación que tanto los equipos Blue Team como Red Team de una empresa deben controlar, y en las distribuciones Kali vienen todas las herramientas necesarias para auditar los servidores DNS de la organización.

En el caso de que el servidor fuera bind9, dado que las resoluciones recursivas requieren el uso de las sugerencias de los servidores raíz, bastaría con añadir la primitiva “recursion no;” en el fichero “named.conf” e impedir las peticiones de transferencias para cada una de las zonas del fichero de nombres.

Figura 14: Limitación de recursión y zonas

Un administrador podría pensar en eliminar el contenido del fichero db.root en bind9 que contiene los registros de recursos A y AAAA de los servidores DNS raíz y eliminar la referencia a la zona “.” en el fichero global named.conf.

Figura 15: contenido del fichero db.root

Si la zona “.” no estuviera, BIND sigue funcionando al ser compilado con una lista de servidores raíz, por lo que como último recurso siempre dispondrá de una lista interna de servidores raíz, el único inconveniente es que la lista es fija, pero los servidores raíz no suelen cambiar. 

Esta comprobación vista hoy es algo que los pentesters, los clientes zombies de las botnets, y los administradores de open resolvers DNS deben buscar y cuidar.  Se deben administrar los servidores para que no sean utilizados en ataques de denegación de servicio. Entre las tareas que deben contemplarse, están las medidas anti-spoofing, filtrado de tráfico y, técnicas como Rate Response Limit y proporcionar una configuración correcta de consultas recursivas.