OVH NEWS | ACTUALIDAD, INNOVACIÓN Y TENDENCIAS IT


Descubrir, entender y adelantarse









07/03/2018
Compartir

Artículo redactado por Sébastien Meriot


1,3 Tbit/s mitigados por el VAC: repaso de lo sucedido con Memcached


El jueves 1 de marzo, en torno a las dos de la madrugada (GMT+1), nuestro VAC mitigó un ataque DDoS dirigido a uno de nuestros clientes que superaba los 1,3 Tbit/s y, por consiguiente, el récord de 1 Tbit/s que ostentaba hasta entonces Mirai. Unas horas antes, GitHub había sido el blanco de otro ataque que también alcanzaba los 1,3 Tbit/s. Por desgracia, la web de GitHub estuvo caída durante unos minutos.

Artículo escrito en colaboración con Alban Lecoq, del equipo VAC.



Estos impresionantes ataques tenían algo en común: el uso en todo el mundo de servicios Memcached mal configurados para lanzar ataques por amplificación. Repasamos una semana llena de emociones e investigaciones.



Figura 1: Ataque de 1,3 Tbit/s, completamente mitigado por el VAC, destinado a uno de nuestros clientes


La configuración por defecto de Memcached, en tela de juicio


Memcached es un sistema de caché distribuida de tipo clave-valor de código abierto. Por lo general, se utiliza para mejorar el rendimiento de sitios web, guardando los resultados de las consultas en una base de datos, o el contenido de páginas dinámicas. Es una herramienta muy utilizada por los webmasters y por algunos editores que integran Memcached en su solución, como es el caso del webmail Zimbra, por ejemplo. Pero ¿qué le ha ocurrido ahora a este servicio tan utilizado?



En 2017, los investigadores en seguridad de la empresa china 360 descubrieron que era posible utilizar un fallo de configuración de Memcached para enviar ataques de denegación de servicio amplificados. Al instalarlo, Memcached escucha por defecto en la interfaz de red pública. Si no se configuran reglas de firewall, cualquiera puede acceder a Memcached desde la IP pública del servidor. Si el servicio solo escuchase en TCP, el problema se limitaría a la confidencialidad de los datos, puesto que no hay ningún mecanismo de autenticación. Lo que ocurre es que también escucha en UDP, y es ahí donde la situación se complica, ya que posibilita la amplificación con un factor impresionante, que puede ser de hasta 51 000 (NTP tenía un factor de solo 557).



¿Qué es un ataque por amplificación?


La amplificación es un fenómeno que consiste en generar una respuesta mayor que la petición. La figura 2 muestra una amplificación de factor 2, donde el volumen de la respuesta duplica al de la petición.



Figura 2: Esquema que muestra una respuesta cuyo tamaño duplica al de la petición (con un factor de amplificación de 2)


Para aprovechar toda la potencia de este fenómeno y utilizarlo en ataques de denegación de servicio, los atacantes combinan el mecanismo de amplificación con el de reflexión. La reflexión consiste en usurpar una dirección IP para que la respuesta se envíe a la IP usurpada. Así, el servidor responde a la que, erróneamente, cree que es la IP de origen de un paquete. Y la víctima, sin haber solicitado nada, recibe paquetes del servidor.



Figura 3: Ilustración del mecanismo de reflexión combinado con el de amplificación


La reflexión es habitual en UDP, ya que este es un protocolo no orientado a conexión, es decir, que, al contrario que TCP, no tiene un mecanismo de three-way handshake, de modo que basta con enviar un único paquete para obtener una respuesta del interlocutor, mientras que en TCP es necesario un intercambio de al menos 4 paquetes entre el cliente y el servidor para que se pongan de acuerdo sobre el establecimiento de una conexión. Si la IP estuviera usurpada, la respuesta del servidor (SYN-ACK) llegaría a la víctima, que no podría confirmar (ACK) haber iniciado la conexión, lo que impediría que esta se realizase y, por tanto, haría que cualquier usurpación de IP fuera en vano. Si desea ampliar la información, esta página de Wikipedia explica bastante bien cómo se establece una conexión TCP.



Plan de acción de OVH


Al detectar este incremento repentino de los ataques por amplificación utilizando Memcached, pusimos en marcha un plan de acción con el objetivo de resistir en caso de que se produjeran grandes ataques. La amplificación es un vector muy fácil de identificar. Sin embargo, debíamos asegurarnos de que nuestros enlaces de interconexión con los otros operadores (peering) no se saturasen para que la calidad del servicio no se viera afectada. Nuestro plan de acción pronto dio sus frutos, como muestra la figura 1: uno de nuestros clientes era blanco de un ataque de más de 1,3 Tbit/s, que fue perfectamente interceptado por el VAC sin interrupción del servicio.



El plan también debía impedir que nuestros clientes que no tuvieran bien configurado el servicio Memcached se vieran, a su pesar, implicados en los ataques. Para ello, hicimos lo siguiente:



• Enviar una comunicación a los clientes potencialmente afectados para ayudarles a configurar su servicio.



• Detectar las IP de OVH utilizadas como reflectores, actuando directamente en la red sin degradar la calidad del servicio y sin esperar horas o días a que nuestros clientes corrigieran el problema.



Decidimos no bloquear el puerto UDP/11211 (el que utiliza Memcached) en nuestra red, ya que este también puede utilizarse para iniciar comunicaciones como puerto cliente, y bloquearlo afectaría negativamente a la calidad del servicio de juegos online, VoIP, streaming y otros servicios que utilizan UDP. Así pues, optamos por otro enfoque, consistente en mitigar permanentemente las IP que recibían un número muy elevado de peticiones Memcached por segundo y que, por tanto, estaban contribuyendo a enviar ataques DDoS. Limpiando estas peticiones maliciosas desde su llegada a nuestra red, nos asegurábamos de que el servicio de nuestro cliente no servía como reflector.



Investigaciones realizadas


El 26 de febrero de 2018, los primeros ataques que detectamos eran generados por peticiones de tipo «gets», tal como muestra la figura 4. Al igual que Cloudflare, observamos que este comando permitía leer una clave que contenía un archivo .zip que, a su vez, estaba protegido por contraseña y contenía un archivo .gif.



Figura 4: Peticiones recibidas en el puerto UDP/11211 (Memcached) por nuestros «honeypots» el 27 de febrero


¿Qué hacía ese archivo .zip en este tipo de caché? Enseguida pensamos que los servicios atacados habrían sido preparados antes de los ataques para poder utilizarlos. Actualmente estamos intentando localizar el origen. Sabemos que Memcached era utilizado desde varios días antes con fines de amplificación. Las gráficas de la figura 5 ilustran el ancho de banda del servidor de uno de nuestros clientes, que era utilizado desde el 24 de febrero para enviar ataques contra la IP china 59.56.19.xxx (ocultamos voluntariamente el último octeto).



Figura 5: Amplificación a través del puerto UDP/11211 observada en el servidor de uno de nuestros clientes el 24 de febrero (GMT+1)


Nos dimos cuenta de que esa IP era atacada regularmente por máquinas de nuestra red de forma muy sincronizada mediante amplificación (LDAP, NTP, SNMP…). Hay varias razones que pueden explicar este fenómeno: o bien la IP aloja un servicio que suscita mucho odio, o bien ha servido como prueba en la preparación de los ataques por amplificación Memcached.



Si seguimos observando, vemos que los ataques contra esa IP suelen ser muy breves (desde unas decenas de segundos hasta unos pocos minutos), mientras que los otros ataques suelen durar mucho más tiempo (el mayor observado ha durado 3 horas).



Hay muchos elementos que nos incitan a creer que esa IP era un Dstat, es decir, que servía para medir en tiempo real la eficacia del DDoS. Por eso, tenemos la teoría de que probablemente los administradores del booter (plataforma de venta de DDoS) querían comparar sus distintos ataques por amplificación con la amplificación a través de Memcached. Entre las pruebas que se realizaron en la misma franja horaria, observamos NTP (UDP/123), LDAP (UDP/389), SSDP (UDP/1900) y BitTorrent.



Continuando la investigación en foros especializados en DDoS, dimos finalmente con una conversación bastante explícita, que puede verse en la figura 6, en la que un usuario reconoce que su plataforma de venta de DDoS es la primera en haber ofrecido la amplificación Memcached.



Figura 6: Un usuario dice públicamente ser el autor del script que permite hacer amplificación a través de Memcached


Evolución de la amenaza


En una semana, las cosas han cambiado mucho. Aunque parece que en un principio la idea de la amplificación Memcached proviene de un único booter, otros administradores no han tardado en implementar la funcionalidad para comercializarla entre sus clientes. Desde los primeros casos, nuestros honeypots han revelado la existencia de diversas formas de explotar los servicios Memcached disponibles en internet, como muestra la figura 7.



Figura 7: Distribución de los comandos Memcached recibidos en nuestros «honeypots»


En algunos servicios, el archivo .zip contenido en la clave «a» da paso a una cadena «abcdefghij» que se repite miles de veces sin que veamos ningún intento de escritura.



Figura 8: Ejemplo de un Memcached con una clave «a» que contiene una secuencia del alfabeto que se repite múltiples veces


También hemos observado claves que contienen mensajes en los que se exige el pago de 50 XMR (una popular criptomoneda conocida como Monero). ¿Podría tratarse de un intento de ransomware en bases de datos que, por definición, solo almacenan datos temporales? ¿O es solo una forma de llenar la caché para aumentar el factor de amplificación?



Figura 9: Clave «a» de un servicio Memcached que contiene un mensaje exigiendo el pago de 50 XMR


A pesar de que rápidamente se corrigieron algunos servicios Memcached que estaban abiertos, todavía hay muchos que pueden utilizarse para cometer ataques.

Al igual que NTP, parece que la amenaza de Memcached haya venido para quedarse. Aunque los mecanismos de protección implementados por los proveedores de alojamiento han reducido drásticamente la envergadura de los ataques —en este momento, la mayoría es inferior a 100 Gbit/s—, la corrección de la configuración por los usuarios es clave. De hecho, el caso NTP nos ha demostrado que, cinco años después, sigue habiendo servidores vulnerables, a pesar de que existen parches.