Análisis de un ataque DDoS con Amplificación DNS

Transcripción

1 Análisis de un ataque DDoS con Amplificación DNS Leonardo Pizarro Universidad Técnica Federico Santa María July 11, 2013 I. Introducción En el presente documento se desarrolla un estudio del ataque DDoS con Amplificación DNS, el cual combina conocimientos de las diversas capas de red, así como el funcionamiento detallado del protocolo DNS. Este ataque ha adquirido popularidad en el último tiempo debido a su eficiencia y a que provee de anonimato al atacante. Esta investigación entrega una descripción del problema, define los principales causantes, así como el modus operandi del atacante, es decir, los pasos que debe seguir. Luego, se presentan las contramedidas conocidas a la fecha, como el desarrollo y conclusiones del trabajo práctico llevado a cabo, que busca generar un ambiente controlado en el que se pueda replicar el ataque con el fin de su estudio. II. Descripción del Problema Los Ataques de Denegación de Servicio o DoS por su sigla en ingles han existido durante años a través de internet. A lo largo del tiempo se han podido factores claves en este tipo de amenazas, como la constante búsqueda de factores de amplificación del ataque, teniendo como claro ejemplo el Smurf Attack y el Fraggle Attack a finales de la decada del 90, así como el actual uso de BotNets por parte de los atacantes, dando pie al Distributed-Dos o DDos. Otro aspecto vislumbrado es el uso de IP Spoofing, el cual es uno de los pilares de cualquier ataque debido a el ocultamiento de la identidad, y en los casos mencionados anteriormente, dificulta la forma en que se pueden mitigar, ya que esta modificación actua al nivel 3 del modelo OSI. El modus operandi del ataque DDos a Spamhaus y finalmente mitigado por Cloudfare, se pudo observar el uso de las peticiones DNS. Normalmente, un consulta DNS, específicamente el paquete de respuesta, no podía pesar más de 512 bytes. Lo anterior se puede generar desde una petición de 60 bytes, logrando un factor de amplificación de 8.5. Con el uso de la extensión EDNS0 para DNS los paquetes de respuesta puede ser aumentados, permitiendo actualmente respuestas mayores a 4000 Bytes, generadas con la misma petición de 60 bytes, consiguiendo una amplificación de un factor 60, es decir, un paquete a lo menos 7 veces más grande, que al ser UDP (connectionless) puede generar un caudal importante en segundos. Lo anterior, en conjunto con servidores OpenDNS y un servidor DNS contaminado, permiten que el atacante genere un registro TXT de más de 4000 bytes, los que mediante las consultas falsificadas a servidores OpenDNS, gatilla el tráfico hacia la victima[4]. II.1 Causas Las causas del efecto amplificador de este ataque se fundamentan en 2 aspectos: En la recursión del servidor DNS, lo que permite que 1

2 cualquier servidor o cliente fuera del dominio pueda realizar consultas. Por ejemplo, si el servidor OpenDNS responde por el dominio example.com, sólo debiese devolver una consulta a clientes o servidores dentro de aquel dominio, como sucede con masterdns.labcomp.cl, que es el servidor de nombres encargado del dominio labcomp.cl. El otro aspecto es el mal uso del EDNS0, que fue diseãśado para permitir un una mayor comunicación debido a los datos adicionales que puede proporcionar un servidor de nombres, lo que ocasiona que se el máximo tamaãśo de respuesta de un servidor de nombres pasase de 512 bytes, a más de 4 KiloBytes. II.2 Modus Operandi del Atacante El atacante busca dejar sin utilidad el servicio de su victima utilizando la menor cantidad posible de recursos. Esto lo logra mediante los siguientes pasos: Figure 1: Secuencia del Ataque El lograr el paso 1 o 3 no es un acto trivial, además de que a diferencia de los demás pasos, no son automatizables y requieren de un conocimiento intermedio-avanzando de seguridad como de redes. II.3 Contramedidas conocidas Actualmente la medida inmediata a tomar en este caso es la de bloquear la dirección IP de el o los servidores OpenDNS que estan devolviendo las consultas realizadas. Sin embargo, esta defensa actua como un ataque DoS por sí mismo, ya que a cada servidor OpenDNS le aparecerá que la victima esta realizando una serie de consultas de gran tamaãśo, bloqueando las respuestas y por ende causando un gran uso del ancho de banda de la red de los servidor OpenDNS. A su vez, ciertos firewalls segmentan cualquier paquete de tamaãśo mayor a 512 bytes, por lo que esto funciona como contramedida parcial, ya que independiente de la cantidad de paquetes que se segmenten, el fin último del atacante es colapsar la red. 2

3 III. Trabajo Práctico En pos de lograr un entendimiento del problema se procedió a montar un escenario similar, en el cual destacan aspectos más técnicos y particulares del ataque, los que posibilitan estudiar aspectos como que la conexión de los computadores atacantes debe ser detrás de un modem (switch) o un router que permita la falsificación o Spoofeo de la IP de origen, lo cual aãśade un grado de dificultad al ataque, ya que no sólo se necesita controlar un computador de una botnet sino que también componentes de la red a la cual pertenece. Otro aspecto que surge en el desarrollo de la parte práctica es que se uso el mismo servidor OpenDNS casero, es decir, que permite la recursión de una consulta perteneciente a otro dominio, para alojar la información del dominio hackeado o falsificado, es decir el dominio que contiene un registro TXT y con EDNS0 activado, que permite el envío de paquetes de gran tamaño y cuyo servidor de nombres permite la transferencia a cualquiera que lo solicite. Finalmente, la creación del paquete con la herramienta Scapy permite la posterior automatización del ataque, el cual es monitoreado con las herramientas wireshark y tshark en la máquina atacante (detectando los 60 bytes de la consulta del paquete de salida UDP), con tshark en el servidor victima (detectando la consulta no solicitada) y con munin en el servidor OpenDNS/Dominio falso para monitorear la entrada y salida de datos. En el Anexo 3 se presenta el detalle de la puesta en marcha con todos los detalles técnicos remanentes. IV. Conclusiones La efectividad de este ataque presenta una total dependencia a la topología de la red, tanto de la botnet atacante como la de la victima, ya que es común que servidores, aún teniendo redundancia y balanceo de carga, no tengan redundancia en cuanto al cableado de la red que les da acceso a internet. Aquello conlleva que el bloqueo de el único canal de comunicación mediante este ataque de nivel 3 sea muy efectivo. Como contramedida clásica surge el tener una red distribuida con múltiples accesos a internet. Sin embargo, como solución más cercana a un servidor con servicios críticos sin tanto presupuesto, es factible dividir los servicios imprescindibles en diferentes IPs públicas, de modo que ante un ataque sea posible redirigir la red interna o las peticiones de los clientes por estas direcciones. En otro aspecto, este ataque al ser una modificación de la lógica del Smurff Attack, permite extrapolar que aunque se logre palear la amplificación DNS, otro servicio UDP podrá ser fuente de un mal uso, como lo podría ser una falsificación múltiple de paquetes NTP con el fin de desorientar a la victima o simplemente colapsar su red. V. Anexos V.1 DNS El protocolo de búsqueda de dominio de nombres o DNS por su sigla en ingles, cumple la función de transformar una dirección url a una IP, con el fin de poder utilizar un denominador para distintos servidores más cercano que un conjunto de números. Este protocolo pertenece a la capa de aplicaciones o capa 7 según el modelo OSI La forma en que opera una consulta DNS se puede apreciar en la Figura 1, siendo el desglose el siguiente: Se puede apreciar que un cliente realiza la consulta a la cual es analizada 3

4 Figure 2: Búsqueda DNS de derecha a izquerda, tomando inicialmente lo que se denomina como TLD, que en el caso sería org, a lo que uno de los servidores root le indica la dirección IP del servidor que maneja ese TLD. Luego, el cliente le realiza al servidor de.org la consulta por wikipedia.org, obteniendo la respuesta del servidor de nombres encargado de esa dirección. Finalmente, el servidor de nombres de wikipedia.org le entraga una dirección IP del servidor que aloja la página, y puede acceder a esa IP para ver su contenido. Este procedimiento es conocido como búsqueda recursiva o recursión Desde sus comienzos en 1983, DNS entrega paquetes de respuesta a las consultas como la anterior mediante el protocolo UDP, con un tamaño máximo de 512 bytes. Desde 1999 es posible transferir una respuesta más grande, siendo común el usar 4KB, debido a la mayor información disponible. Lo anterior es debido a la aprobaciín del RFC 2671 o EDNS0, el cual es un mecanismo de extension para DNS. Entre las consultas posibles, existen distintos tipos, siendo los más comunes: Tipo A AAAA NS MX TXT CNAME Descripción Indica la dirección IPv4 del servidor host con el contenido del dominio buscado Indica la dirección IPv6 del servidor host con el contenido del dominio buscado Indica el servidor de nombres a cargo del dominio Indica el servidor de correo a cargo del dominio Contiene información adicional del dominio, como filtros de spam Alias de un dominio Table 1: Tipos de records DNS más comunes A diferencia de una consulta de un cliente a un servidor DNS, los servidores DNS se comunican entre si mediante el protocolo TCP en el mismo puerto 53. Como buenas prácticas para un servidor DNS, se recomienda que permita recursión sólo para consultas realizadas dentro de su zona. 4

5 V.2 HowTo: DDos with DNS Amplification Pasos para replicar un ataque en un ambiente controlado. 1. Servidor DNS: Se instala Debian 6 en su versión estable, cuyo nombre código es Squeeze con la función de servidor DNS seleccionada entre los paquetes básicos. Los cambios a realizar a la configuración del S.O. instalado son: Firewall: Iptables controla el firewall en Squeeze mediante el archivo iptables.rules en la carpeta /etc. En caso de no existir el archivo, es conveniente realizar el comando iptables-save > iptables.rules. Luego, se agregan 2 reglas: -A INPUT -p udp -m udp --dport 53 -j ACCEPT -A INPUT -p tcp -m tcp --dport 53 -j ACCEPT Las que permiten la comunicación con los clientes y otros servidores DNS. DNS: La configuración por defecto para DNS en Debian esta en el archivo named.conf en la carpeta /etc/bind/, el cual inicialmente sólo incluye a 3 archivos, de los cuales nos interesa named.conf.options, que es aquel que filtra la recursión, la transferencia y a quienes se autoriza a realizar consultas al servidor. Se debe descomentar la sección forwarders y agregar las siguientes lineas al archivo: allow-transfer { /0; }; allow-query { /0 }; allow-recursion { /0; }; Esto permite obtener un servidor OpenDNS (recursión para todos), además de actuar como el servidor del Dominio hackeado o falso, ya que permite la transferencia a todos.. A lo anterior, se debe agregar uno o más dominios, que deben ser configurados a modo de contener el registro TXT malicioso. Aquello se realiza de la siguiente manera[3]: $ORIGIN template.cl. $TTL IN SOA inti.inf.utfsm.cl. hostmaster.inf.utfsm.cl. ( ; Serial ; Refresh 1800 ; Retry ; Expire 3600 ) ; Minimum IN NS inti.inf.utfsm.cl. IN NS secundario.nic.cl. IN A IN MX 10 crux.inf.utfsm.cl. 5

6 www IN A mail IN A Lo anterior debe guardarse con el nombre dominio.tld.zone, que en este caso es template.cl.zone en /etc/bind. Finalmente se debe agregar al archivo named.conf.defaultzones en /etc/bind, lo siguiente para cada dominio: zone "template.cl" IN { type master; file "/etc/bind/template.cl.zone"; notify yes; also-notify { ; }; # Notificando al servidor secundario allow-transfer { ; }; # Permite la transferencia de zona a # cualquiera que lo solicite }; Con lo anterior, al hacer una consulta del tipo dig any Servidor DNS> se tendrá una respuesta normal. 2. Activar EDNS0: Se puede observar que viene activado en la instalación base. 3. Crear entrada TXT de 4000 Bytes: El registro TXT para DNS puede variar entre 0 y 4096 bytes (Con EDNS0 Activado), sin embargo, el registro debe estar compuesto de substrings que no superen los 255 bytes de largo cada uno[2], de lo contrario, el servidor DNS no iniciará. Un registro correcto es de la forma IN TXT "Giant TXT record for DNS Amplification Testing, any questions, at leoxdxp on twitter or lepizar at inf dot utfsm dot cl Now Just more text text text text text DDoS text text text text text text more text text text text" " text DDoS text text text text text text more text text text text text DDoS text text text text text text more text text " "text text text DDoS text text text text text text more text text text text text DDoS text text " En donde se puede apreciar las comillas dobles entre substrings, lo cual permite la creacion de un string gigante. El string del ejemplo pesa 552 bytes. 4. Aplicar paquete UDP con IP Spoofeada: Utilizando la herramienta Scapy, mediante el uso del método IP(), se puede asignar tanto un origen como un destino. En este caso, el origen es la IP de la victima y el destino el o los servidor OpenDNS. Además, Scapy permite elegir el protocolo mediante el cual será enviado el paquete, por lo que se utilizará el método UDP(). Finalmente, usando el método DNS(), se pasan los parámetros de la consulta como tal. La suma de lo anterior queda como: 6

7 #!/usr/bin/python import sys from scapy.all import sr1,ip,dns,udp,dnsqr,send victimsip = " XXX" OpenDNSIP = " YY" packet = IP(src=victimsIP, dst=opendnsip)/udp() /DNS(rd=1,qd=DNSQR(qname="example.com",qtype="TXT")) send(packet) Para poder medir la salida como llegada del paquete, se recomienta dejar UDP( sport=53, dport=53 ), y con tcpdump o wireshark filtrar el puerto, el protocolo y medir el contenido de este. References [1] An Extensible Pattern-based Library and Taxonomy of Security Threats for Distributed Systems, Anton V. Uzunova, Eduardo B. Fernandez [2] TXT Records Size [3] Template DNS ftp://ftp.inf.utfsm.cl/dnstemplate Todos los links activos al DD de MM del 2013 [4] Anatomy of a DNS DDoS Amplification Attack, David Piscitello, ICANN SSAC Fellow 7