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.