¿Alguna vez os habéis preguntado cómo se consiguen cantidades de tráfico tan elevadas en los ataques DDoS?¿Mediante una botnet con muchos zombies lanzando peticiones? Bueno, sí, es posible... pero es complicado conseguir el control de tantas máquinas (¿alguien ha dicho IoT?). Una opción más sencilla es hacer uso de técnicas de amplificación de tráfico UDP para poder realizar una inundación de paquetes, necesitando una botnet mucho más pequeña para conseguir el mismo efecto.
Ataque UDP Flood. Lo siento señor usuario legítimo, pero la conexión del sistema está saturada.
Antes de nada, ¿por qué UDP? Porque es un protocolo no orientado a la conexión (no hay un three-way handshake previo), lo que hace que sea fácilmente spoofeable: al no comprobar la IP origen, podemos poner la de la víctima como origen de las peticiones maliciosas (lo que se denomina ataque por reflexión).
Por otro lado, algunos protocolos de aplicación sobre UDP poseen ciertas características (vulnerables por diseño) que generan unas respuestas de un tamaño muy superior a las peticiones. De este modo, si ante una petición de unos 10 bytes se genera una respuesta de 100 bytes, se obtiene una amplificación de tráfico de 10:1. Combinando esto con la reflexión se explica la capacidad de generación de tráfico de estos ataques, ya que se atacan una serie de servidores vulnerables con una IP de origen común: la pobre víctima que va a recibir todas las respuestas a la vez.
Veamos algunos de los ejemplos más comunes (los ratios máximos de amplificación los hemos sacado de aquí):
Domain Name System (DNS) es un protocolo más que conocido. Pese a que originalmente DNS soportaba unas respuestas de un tamaño máximo de 512 bytes sobre UDP, la especificación EDNS0 (un parche publicado en la RFC 2671 en 1999) permitió el envío de mensajes de hasta 4096 bytes.
Por tanto, a partir de una consulta de unos 75 bytes se puede provocar una respuesta de hasta 4096 bytes (para respuestas mayores se obliga a usar TCP), obteniendo un factor de amplificación máximo de aproximadamente de 54:1.
Lo más gracioso (y peligroso) de este protocolo es, que pese a no tener un factor de amplificación muy elevado, está diseñado para estar publicado a Internet, por lo que todos los servidores DNS públicos podrían valer como amplificadores (salvo que cuenten con medidas de protección).
Vamos a mancharnos las manos un poco: Veamos si los DNS de Google podrían valer para amplificar tráfico (spoiler: sí). Para ello, hacemos uso de la herramienta DiG: forzamos el protocolo UDP (+notcp), seleccionamos los NameServers de Google (@8.8.8.8), especificamos que devuelva información de cualquier tipo de registro (any) y probamos diversos dominios (tras varias pruebas, hemos conseguido alcanzar la mayor respuesta con el dominio “re”).
Amplificación 42:1. Invita Google
El Protocolo de Generación de Caracteres (CHARGEN) es un servicio definido en la RFC 864 de 1983. Se diseñó para usos de testing y debugging, pero a día de hoy se utiliza muy poco.
Ante una conexión TCP a una máquina con este servicio (localizado en el puerto 19), esta comienza a enviar caracteres arbitrarios hasta que la conexión se cierra. Si esta conexión es mediante UDP, el servidor envía un número aleatorio (entre 0 y 512) de caracteres cada vez que recibe un datagrama, obteniendo una amplificación de hasta unos 359:1.
Bien, parece un protocolo viejo y absurdo ¿verdad? Pues a día de hoy hay casi 54.500 máquinas con el puerto 19 abierto a Internet están anunciadas en Shodan (por suerte, no todos en UDP), así que... ¡Vamos a jugar un poco! Seleccionamos cualquier máquina con el puerto 19 UDP abierto, le lanzamos un netcat, escribimos una “a” (se puede enviar únicamente un retorno de carro, pero la imagen siguiente no quedaría tan chula), pulsamos enter... y lo que pasará a continuación os sorprenderá.
Amplificación 133:1. Not bad.
Quote Of The Day (QOTD) QOTD es un protocolo definido en la RFC 865 de 1983 que básicamente devuelve una cita ante una conexión al puerto 17 TCP o UDP (sí, parece que ese año se lucieron).
¿Existen servidores con el puerto abierto a Internet? Sí, unos 35.250 (Shodan dixit)... pero afortunadamente QOTD tiene un factor de amplificación menor que CHARGEN (hasta unos 140:1).
Vuelta a Shodan, seleccionamos un servidor con el puerto 17 UDP abierto, abrimos un netcat y enviamos varios retornos de carro para ver qué frases devuelve el servidor. Observamos que la variedad de las frases es muy limitada, y en otros de los servidores publicados en Shodan parecen ser las mismas. Por tanto, los resultados de este ataque son muy modestos... no llega a 5:1.
Amplificación 5:1. No todo va a ser rock’n’roll, ¿no?
Network Time Protocol (NTP) definido en la RFC 1305 (en el año 1992), es un protocolo utilizado para sincronizar los relojes de las máquinas conectadas a Internet a través del puerto 123. Entre otras funciones, NTP ofrece una de monitorización denominada “monlist”, que envía una lista con las últimas 600 IPs que han hecho una petición de hora al servidor. De este modo, se puede llegar a generar un factor de amplificación de hasta 557:1.
No obstante, los servidores NTP posteriores a la versión 4.2.7 llevan esta funcionalidad deshabilitada por defecto, y hay que modificar un fichero de configuración para volver a establecerla (del mismo modo, en versiones anteriores puede deshabilitarse a través del mismo fichero).
Nuevamente, ¡hora de jugar! Volvemos a Shodan, esta vez buscando máquinas con el puerto 123 abierto y con versiones antiguas del servidor NTP. Nos llama la atención que existan versiones 4.1.0 pululando por ahí, así que nos centraremos en ellas. Tras probar varios servidores damos con uno que, bueno... Devuelve un mensaje corrupto/incompleto. Lo bueno es que este mensaje, aunque corrupto, es muchísimo más grande que la petición: ¡amplificación conseguida!
Amplificación 105:1. Mejoraremos esta cifra en futuros posts, promesa.
En futuros posts hablaremos un poco más en detalle de este ataque, que permitió alcanzar las mayores cantidades de tráfico en ataques DDoS de la historia. No obstante, ha sido enormemente eclipsado por...
Memcached el chico malo de este año. El ataque que ha reventado el récord de tráfico conseguido dos veces en una misma semana: la vulnerabilidad ‘memcrashed’.
Memcached es un sistema diseñado en 2003, el cual realiza un cacheo en la memoria RAM de distintos datos cuyo tiempo de acceso es elevado. Este almacenamiento se reparte entre varios servidores en forma de tabla hash distribuida, a los cuales se accede a través del puerto 11211. El problema viene en que este sistema está diseñado para ser desplegado en redes privadas, y nunca publicado a Internet.
Por una última vez, volvemos a darnos un paseo por Shodan. En este caso buscamos máquinas con el puerto 11211 abierto (¡86.739!). “Desgraciadamente” vamos a tener que realizar bastantes intentos para dar con una máquina que responda por UDP a una petición para memcached. De nuevo, usaremos netcat para enviar estas peticiones. Para ello, usamos un comando muy visto por Internet para ver si un servidor es vulnerable a memcrashed:
Amplificación 21,5:1. Decepción :(
¿Esto es el terrible memcrashed? No nos lo podíamos creer, así que seguimos investigando hasta dar con una función interesante. Es posible añadir un argumento al comando “stats”, en específico, es posible pedir las estadísticas de los objetos almacenados en memoria en ese momento con el argumento “items”.
En la captura anterior se puede ver que únicamente hay un objeto almacenado en memoria en ese momento (“curr_items 1”), pero ¿puede haber algún servidor memcached con una gran cantidad de objetos almacenados?
Por supuesto.
Veamos las estadísticas de los objetos:
Aquí vemos de nuevo que hay la friolera de 3732 items almacenados en memoria. Vemos también un 2, que es el “slab_id” (zona de memoria) donde están almacenados los objetos. Con este valor, es posible obtener todos los objetos de dicha posición de memoria con el comando “stats cachedump 2 0” donde el 0 indica que no se especifica un límite a la hora de devolver los datos de la memoria.
Amplificación 3.479:1. Boom
¡Y esto no es todo! Como se ve en la captura anterior “stats cachedump” devuelve una lista de claves, que pueden llegar a tener un tamaño de valor muy elevado. Por tanto, tras realizar una pequeña búsqueda, encontramos un servidor que tiene una clave con un valor de un tamaño considerable, el cual obtenemos mediante el comando “get <clave>”:
Me encanta el olor a hacked (ajeno) por las mañanas
Y esto no es nada, el protocolo establece un límite en la respuesta que puede devolver... de 1 o 2MB. Esto podría dar unas amplificaciones superiores a 20.000:1. Según algunos investigadores, este ataque podría llegar incluso a 51.000:1... ¡Casi nada!
Y hasta aquí llegamos esta vez. Espero que os haya gustado este pequeño estudio. Me gustaría acabar con una pequeña reflexión, aunque esté ya muy manida: en todos los ataques hemos visto máquinas vulnerables en España e Hispanoamérica así que si tenéis servidores públicos y estáis leyendo este post; por favor, actualizadlos, analizad sus servicios publicados a Internet y eliminad aquellos que sean inseguros... No facilitéis las cosas a aquellos que quieren hacer un mal uso de la red.
¡Saludos!
Artículo cortesía de Luis Vazquez (@macgruap)
No hay comentarios:
Publicar un comentario