- Inicie sesión para enviar comentarios
ATAQUE DE AMPLIFICACIÓN
DE
SERVIDOR DE NOMBRE DE DOMINIO (DNS) RECURSIVO
{Andre Mitsutake; Profesional de Evaluacion de Seguridad}
{Colaboracion: Amilcar Zeballos Teran; Egresado Ing. Sistemas }
I. INTRODUCCIÓN
El presente documento presenta los aspectos mas relevantes que se tienen en un ataque de amplificación con servidores de nombres de dominio (DNS), que a consecuencia de esta vulnerabilidad genera una denegación de servicio distribuida (DDoS) lo que puede afectar a otros sistemas.
II. DESCRIPCIÓN
Un ataque de amplificación de Servidor de nombre de dominio (DNS) es una forma popular de Denegación de Servicio Distribuida (DDoS), en la que los atacantes usan servidores DNS que se encuentran abiertos y accesibles para inundar un sistema de destino con tráfico de respuesta DNS.
La técnica empleada utilizada frecuentemente consiste en:
• Enviar solicitudes de búsqueda de nombre DNS a un servidor DNS abierto con recursion abierta, con la dirección de origen falsificada apuntando así a la victima.
• Cuando el servidor DNS envía la respuesta de registro DNS, se envía a la dirección suplantada.
Por lo general, los atacantes envían una solicitud que provea grandes cantidades de información para maximizar el efecto de amplificación. En la mayoría de los ataques de este tipo, realizan consultas falsificadas de tipo "ANY", que devuelve toda la información conocida sobre una zona DNS en una sola solicitud.
Debido a que el tamaño de la respuesta es considerablemente mayor que la solicitud, el atacante puede aumentar la cantidad de tráfico dirigido a la víctima.
También se puede aprovechar una botnet para producir una gran cantidad de consultas DNS falsificadas, un atacante puede crear una inmensa cantidad de tráfico con poco esfuerzo. Además, como las respuestas son datos legítimos provenientes de servidores válidos, es extremadamente difícil evitar este tipo de ataques.
III. TERMINOLOGÍAS
[*] Zone
Es el dominio predominante de la entidad la cual puede estar comprendida por varias IP publicas dependiendo de la cantidad de subdominios que pueda tener.
Ej.: prueba.gob.bo, hola.prueba.gob.bo, como.prueba.gob.bo
Donde la zona (dominio) seria “prueba.gob.bo”.
[*] NameServer
Es el software que se usa para responder la petición de “URL a IP” o viceversa, softwares tales como Bind, PowerDNS, djbdns, etc..
[*] Authoritative NameServer
Para cualquier zona, debe existir alguien que mantenga el URL y la dirección IP del dominio. El servidor maestro o varios (si se tiene varios dominios) el cual representa el dominio con el correspondiente IP.
[*] Resolver
Es la configuración del cliente encargada de determinar cuales son los servidores DNS donde se solicitaran las peticiones para la resolución de los dominios. En Linux se encuentra en “/etc/resolv.conf”
[*] Recursive NameServer
Son las peticiones de zonas no autoritativas, dado que un servidor DNS no puede contener toda la información de las distintas zonas (bien en cache o en su DB). No todos los servidores DNS están configurados para permitir recursion, estas solo deberían estar configuradas con los servidores de confianza como con los servidores de los ISP(Internet Service Provider).
[*] Resource Record
La información cargada en el servidor DNS, los registros de los dominios y a que dirección IP apunta. Esto esta representado por la letra “A” en la base de datos del servidor.
[*] Delegation
Cuando el servidor DNS no tienen la información que se requiere, pero sabe quien podría tener la información requerida.
IV. FLUJO DE PETICIÓN DNS
A continuación en la Figura 1 se muestra flujo de las peticiones DNS, el cual es un comportamiento de una petición de un cliente y su servidor DNS no consta de este registro en la base de datos de su cache, ni en su base local.
Figura 1: Flujo de las Peticiones DNS
Fuente: Elaboración Propia
V. DESCRIPCIÓN DE INFRAESTRUCTURA
Para realizar la demostración de una suplantación de IP, para un ataque amplificado de DNS recursivos, se implemento cuatro maquinas virtuales (Debian GNU/Linux 9.4 (stretch)). Los servidores DNS se encuentran para la prueba funcionando con software Bind9.
[-] Distribución de Direcciones IP.
Figura 2: Diagrama de Pruebas
Fuente: Elaboración Propia
En la Figura 2 se muestra el diagrama el cual fue usado para las pruebas pertinentes.
Tabla 1: HOST e IP de las Pruebas
Fuente: Elaboración Propia
Considere que ningún dispositivo pertenece a la misma red, por consiguiente cada segmento puede representar un a organización.
[-] Configuraciones DNS-Bind9
ns.recursion.bo~$ cat /etc/bind/named.conf.options
| options { directory "/var/cache/bind"; recursion yes; #Habilita la recursion allow-query { any;}; #Cualquier tipo de peticion allow-recursion { any;}; #Recursion habilitada para cualquier direccion IP listen-on {172.16.10.100;}; #Direccion IP del servidor DNS allow-transfer {none;}; #Habilita Transferencia de Zona auth-nxdomain no; #Respecto a RFC1035 listen-on-v6 { none; }; #Resolucion de dominios en IPv6 forwarders { 100.100.100.100;}; #Direcciones IP del proveedor de Servicio - ISP }; |
ns.recursion.bo~$ cat /etc/bind/named.conf.local
| zone "recursion.bo" { type master; file "/etc/bind/zones/db.recursion.bo"; allow-transfer { none;}; }; zone "10.16.172.in-addr.arpa" { type master; file "/etc/bind/zones/db.172.16.10"; allow-transfer { none;}; }; |
ns.ispdnds~$ cat /etc/bind/named.conf.options
| options { directory "/var/cache/bind"; recursion yes; #Habilita la recursion allow-query { any;}; #Cualquier tipo de peticion allow-recursion { any;}; #Recursion habilitada para cualquier direccion IP listen-on {100.100.100.100;}; #Direccion IP del servidor DNS allow-transfer {none;}; #Habilita Transferencia de Zona auth-nxdomain no; #Respecto a RFC1035 listen-on-v6 { none; }; #Resolucion de dominios en IPv6 }; |
ns.ispdns.bo~$ cat /etc/bind/named.conf.local
| zone "ispdns.bo" { type master; file "/etc/bind/zones/db.ispdns.bo"; allow-transfer { none;}; }; zone "100.100.100.in-addr.arpa" { type master; file "/etc/bind/zones/db.100.100.100"; allow-transfer { none;}; }; |
NOTA: Tomar en cuenta que la configuración de Transferencia de Zona debe ser considerada por cada usuario, dado que las organizaciones pueden tener mas de un servidor DNS por ende los otros DNS secundarios deberían poder realizar transferencia de zona del DNS master.
[-] Estructura de la trama
Figura 3: Estructura de Paquetes DNS
Fuente: Elaboración Propia
La Figura 3 muestra la estructura de un paquete DNS, a continuación se describirá los campos mas utilizados:
[*] Query ID
Este es un identificador de consulta único creado en el paquete, este queda intacto por el servidor que envía la respuesta: permite que el servidor que realiza la solicitud asocie la respuesta a la pregunta.
[*] QR
0 cuando el cliente esta enviando y se coloca en 1 por la respuesta del servidores
[*] AA
Respuesta autoritativa 1, si no 0
[*] RD
El cliente establece esto: en 1 si desea que el servidor realice la búsqueda completa del nombre recursivamente o 0 si solo quiere la mejor información que tiene el servidor y el cliente continuará con la consulta iterativa por sí mismo. Los servidores raíz, por ejemplo, nunca realizarán consultas recursivas.
[*] RA
1 soporta recursion y 0 no soporta recursion
VI. DESARROLLO
[-] Simple petición de dominio
Con unos pocos términos clave definidos, revisaremos cómo funciona una simple consulta recursiva en ausencia de errores o engaños; esto mostrara en fondo el funcionamiento donde los exploits pueden aplicarse dado que no solo existe ataques de amplificación también existen envenenamientos de los caches de los servidores DNS.
Aunque el paquete DNS en sí tiene muchos campos (cada uno de los cuales es importante), estamos omitiendo ese detalle por el momento para comprender el flujo de alto nivel de una consulta completa, de arriba a abajo. Visualizar cómo la delegación hace rebotar las solicitudes de un servidor a otro es vital para comprender que la vulnerabilidad se explotará más adelante.
No es importante saber por qué se busca el nombre, solo para saber cómo funciona.
Figura 4: Flujo de petición DNS sin Victima (Lab)
Fuente: Elaboración Propia
[1]
El cliente (denominado "Atacante") realiza una solicitud de www.ispdns.bo y se enruta al servidor de nombres de una entidad (denominado “ns.recursion.bo”). Solicita el registro A, que representa una dirección IP.
El servidor “ns.recursion.bo – 172.16.10.100” sabe que no es autorizado para ispdns.bo, por lo que no puede buscarlo en su base de datos de la zona local. Tampoco encuentra el nombre en su caché de datos vistos recientemente, por lo que sabe que tiene que derivar a otro servidor para resolver la petición.
Figura 5: Solicitud de URL
Fuente: Elaboración Propia
[2]
El servidor “ns.recursion.bo” esta configurado para hacer recursion al “ns.ispdns.bo – 100.100.100.100” el cual se encargaría de resolver el dominio buscado. Dado que la pagina buscada se encuentra en el servidor “ns.ispdns.bo” este devolverá la IP correcta del dominio.
En el ambiente controlado, el servidor ns.ispdns.bo no consta con los registros de Global Top Level Domain – GTLD. Esto serviría si el cliente estaría buscando otra pagina que no se encontraria en la base local del servidor “ns.ispdns.bo”, con cualquier extensión como “.net”, “.com”, “.org”, etc.
Figura 6: Recursion DNS
Fuente: Elaboración Propia
Nota: OPT proporciona espacio para hasta 16 opciones adicionales y extiende el espacio para los códigos de respuesta. El tamaño total del paquete UDP y el número de versión (en la actualidad 0) figuran en el registro OPT.
[3]
El servidor “ns.ispdns.bo” tiene lo que estábamos buscando: proporciona el registro “A” de www.ispdns.bo.
Además, la respuesta incluye el identificador que dice "Esta es una respuesta autoritativa", que indica que proviene de la fuente original del dominio solicitado.
Figura 7: Respuesta Autoritativa
Fuente: Elaboración Propia
[4]
Ahora, con la respuesta el servidor “ns.recursion.bo” responde al cliente (Atacante) y con eso concluiría el ciclo de la consulta.
El servidor de nombres recursivo también archiva esta respuesta en su propio caché en caso de que este u otro cliente, realice la misma consulta más adelante.
Pero notaremos que la respuesta al cliente no incluye el indicador "autoritativo". A pesar de que recibió del “ns.ispdns.bo”, el servidor de nombres recursivo no puede fingir ante el cliente que en realidad es la fuente de autoridad, por lo que se considera una respuesta no autoritativa, a pesar que en el payload se puede apreciar cual es el servidor autoritativo del dominio solicitado.
Figura 8: Respuesta DNS - Cliente
Fuente: Elaboración Propia
[-] Suplantación de IP de origen
En este escenario se explicara como un atacante puede aprovechar la vulnerabilidad de recursion, para generar una ataque DDoS a un servidor víctima.
Tomar en cuenta el dominio solicitado, es un dominio que consta de los registros adecuados para su traducción por lo que la carga útil del paquete de respuesta es relativamente pequeño. La mayoría de los ataques se realizan con peticiones de “ANY” o “.” esto aumenta considerablemente el tamaño del paquete, como se menciono anteriormente.
Figura 9: Flujo de petición DNS con Victima (Lab)
Fuente: Elaboración Propia
[*] Python Script
El siguiente script en Python 2.7, se enviá peticiones DNS con la facilidad de modificar el IP de origen y destino como también los puertos y el URL solicitado.
Otra característica es la posibilidad de mandar varias peticiones, esto se podría mejorar en un ataque masivo empleando multiprocesos y de esta manera generar varios paquetes al mismo tiempo.
Scapy es un poderoso programa interactivo de manipulación de paquetes escrito en “python”. Es capaz de forjar o decodificar paquetes de una gran cantidad de protocolos, enviarlos por cable, capturarlos, responder a las solicitudes y mucho más. Puede manejar fácilmente la mayoría de las tareas clásicas como escaneo, trazo, sondeo, pruebas unitarias, ataques o redes de descubrimiento (puede reemplazar a hping, 85% de nmap, arpspoof, arp-sk, arping, tcpdump, tethereal, p0f, etc.). También funciona muy bien en muchas otras tareas específicas que la mayoría de las otras herramientas no pueden manejar, como enviar marcos no válidos, inyectar sus propios marcos 802.11, combinar técnicas (saltos de VLAN + envenenamiento de caché ARP, decodificación VOIP en canal cifrado WEP, ... ), etc.
|
“””This script send DNS packets from scapy.all import DNS #IP de origen, el cual puede ser reemplazado por la IP de la victima #IP de destino, el IP del servidor que tiene la vulnerabilidad de RECURSIVIDAD #Puerto de Origen, la respuesta del servidor DNS lo enviara por este puerto #Peticion URL del cliente (Ej.: www.google.com, www.linux.net, etc..) #Cuantos paquetes se enviara. packet = IP(src=src_ip,dst=dst_ip)\ send(packet, count=peticiones, verbose=False) |
Con el uso del script en python, se realiza la petición del dominio “www.ispdns.bo” suplantando el IP de origen por la dirección de la Victima que en este caso seria el 192.168.100.100. Por consiguiente la respuesta del url solicitado se enviara al IP victima generando varios paquetes de diferentes dispositivos produciría un ataque de DDoS.
Figura 10: Paquete con IP suplantada
Fuente: Elaboración Propia
VII. DETECCIÓN
Para la detección de servidores DNS vulnerables a la recursion no controlada se puede emplear las siguientes herramientas como también sitios web:
[*] NMAP
| nmap -sU -pU:53 --script dns-recursion <IP> |
O bien se puede utilizar la pagina web directamente
| https://openresolver.com |
VIII. MITIGACIÓN
Desafortunadamente, debido al volumen de tráfico masivo que puede producirse por uno de estos ataques, a menudo la víctima puede hacer poco para contrarrestar un ataque de denegación de servicio distribuido basado en la amplificación de DNS a gran escala.
Sin embargo, es posible reducir la cantidad de servidores que los atacantes pueden usar para generar los volúmenes de tráfico. Si bien el único medio eficaz de eliminar el uso de DNS recursivos en este tipo de ataque es eliminar los DNS recursivos no seguros, esto requiere un gran esfuerzo de varias partes.
Según el Open DNS Resolver Project, de los 27 millones de servidores DNS conocidos en Internet, aproximadamente "25 millones representan una amenaza significativa" de ser utilizados en un ataque. Sin embargo, hay varias técnicas posibles para reducir la efectividad general de tales ataques a la comunidad de Internet en general.
Siempre que sea posible, se han proporcionado enlaces de configuración para ayudar a los administradores a realizar los cambios recomendados. La información de configuración se ha limitado a BIND9. Si está ejecutando un servidor DNS diferente, consulte la documentación de su proveedor para obtener detalles de la configuración.
[*] Verificación de IP de origen
Debido a que las consultas DNS enviadas por los clientes controlados por atacante deben tener una dirección de origen suplantada para aparecer como el sistema de la víctima, el primer paso para reducir la efectividad de la amplificación DNS es que los servidores DNS que se implementan dentro de una organización o proveedor de servicios de Internet, deben configurarse para realizar consultas recursivas solo para el segmento de clientes autorizados.
Estas solicitudes generalmente solo deberían provenir de clientes dentro del rango de direcciones de red de la organización. Recomendamos encarecidamente que todos los administradores del servidor ejecuten restricciones de recursividad solo a clientes en la red de la organización.
Para reducir la efectividad de la amplificación DNS de los proveedores de servicios de Internet deben rechazar cualquier tráfico DNS con direcciones falsificadas.
Un proveedor de servicios de Internet puede filtrar el tráfico de red en su red para rechazar paquetes con direcciones fuente no accesibles a través de la ruta real del paquete.
Todos los cambios recomendados en este documento provocarían que un dispositivo de enrutamiento evalúe si es posible llegar a la dirección de origen del paquete a través de la interfaz que transmitió el paquete. Si no es posible, entonces el paquete obviamente tiene una dirección de origen falsificada. Este cambio de configuración reduciría sustancialmente el potencial de los tipos más populares de ataques DDoS.
Como tal, recomendamos a todos los operadores de red que realicen el filtrado de ingreso de red si es posible.
A continuación se detalla la configuración de un ACL (ingress filtering) para un servidor DNS Bind9 en una organización.
ns.recursion.bo~$ cat /etc/bind/named.conf.options
| acl intranet { 172.16.10.0/24;}; #ACL de la red interna de la organizacion options { directory "/var/cache/bind"; recursion yes; allow-query { any;}; allow-recursion { intranet;}; #Colocar la ACL creada listen-on {172.16.10.100;}; allow-transfer {none;}; auth-nxdomain no; listen-on-v6 { none; }; forwarders { 100.100.100.100; }; }; |
Figura 11: Paquete rechazado (mitigación)
Fuente: Elaboración Propia
Respuesta del servidor ns.recursion.bo, en el cual se puede apreciar que la petición fue rechazada, dado que pertenece al segmento de la ACL configurada. Peticiones pertenecientes al dominio recursion.bo es aceptada, dado que no es necesario recursion para devolver la IP del dominio que se encuentra en la base local del servidor DNS.
IX. BIBLIOGRAFÍA
[+] https://www.us-cert.gov/ncas/alerts/TA13-088A
[+] http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html
[+] https://www.ietf.org/rfc/rfc1034.txt
[+] https://www.ietf.org/rfc/rfc1035.tx