El que ha sido etiquetado como el mayor ataque DDoS de la historia golpeó los servidores de Github a las 17:21 del pasado miércoles.
Los grandes ataques DDoS han sido relativamente habituales en los últimos años, pero las estadísticas de este han sido de récor llegando a un pico de 1350 gigabits por segundo con una réplica que alcanzó 400 gigabits por segundo.
El anterior récor lo tenía un ataque al proveedor de DNS Dyn en 2016, con un pico estimado de 1000 gigabits por segundo que causó problemas en servicios como Netflix, Twitter y, curiosamente, Github.
Según el equipo de ingenieros de Github, los problemas de la semana pasada duraron nueve minutos:
A las 17:21 UTC nuestro sistema de monitorización de red detectó una anomalía entre la relación entre el tráfico de entrada y de salida y lo notificamos, entre otros, al equipo de ingenieros por nuestro sistema de chat… Dado que el aumento del tráfico entrante superaba los 100 Gbps en una de nuestras instalaciones, se tomó la decisión de desviar el tráfico a Akamai.
Buenas noticias, los sistemas de defensa contra ataques DDoS funcionaron como debían, pero lo interesante del ataque no es tanto su tamaño si no lo que alimentaba ese tamaño.
El ataque utilizó amplificación, una técnica que ya habíamos visto en otros mega incidentes DDoS, esta vez atacando Memcached.
Memcached es una tecnología popular diseñada para acelerar el acceso a webs que ejecutan grandes bases de datos al almacenar datos en la RAM para un acceso rápido.
Por defecto, permite conexiones externas sin autentificar en el puerto UDP 11211, lo que significa que los atacantes pudieron generar grandes cantidades de tráfico simplemente enviado a servidores que se encontraban en ese estado débil un simple comando “stats” desde una dirección IP falsa.
Las respuestas de Memcached a stats resultaron ser enormes, según Github, alcanzando un factor de amplificación de hasta 51.000, lo que significa que por cada byte enviado por el atacante, se enviaban hasta 51kb hacia el objetivo.
Ataques anteriores, como el de 2013 a Spamhaus, tenían un factor de amplificación mucho menor de solo 50, con lo que consiguieron un pico de 300 Gbps.
Un año después, se aprovecharon del protocolo NTP para conseguir un ataque de 400 Gbps a una empresa francesa de hosting llamada OVH, con un factor de amplificación de 500 veces.
Puede que los expertos intuyeran que algo malo se estaba cociendo, lo que explicaría porque Akamai fue capaz de mitigar el ataque tan rápido.
Afortunadamente, no es difícil de parar usando un firewall de perímetro para bloquear el UDP en un determinado puerto, o directamente desactivando UDP o Memcached directamente en los servidores.
Una vez más, como ocurrió en otros ataques de amplificación, el problema subyacente son infraestructuras con poca seguridad. Se calcula que hay cerca de 100.000 servidores vulnerables a Memcached en todo el mundo, principalmente en EEUU y China.
Akamai ya ha avisado que han visto una mayor búsqueda de servidores con Memcached abierto desde el ataque, por lo que es fácil que se repita este tipo de ataque.
Ahora alguien debería persuadir a los dueños de esos servidores con Memcached vulnerable que solucionasen el problema.
Puede que los atacantes estuvieran probando una nueva idea. Incluso se ha sugerido que era un ataque de rescate porque había una petición de dinero en la criptomoneda Monero.
Nuestra esperanza es que vista la rapidez con la que solucionaron el problema, sirva para que los ciberdelincuentes no vuelvan a utilizar esta técnica.
Para manteneros al día de las últimas amenazas haceros fans de nuestra página de Facebook o síguenos en Twitter para intercambiar experiencias en torno al mundo de la seguridad. Si deseas recibir nuestro boletín de seguridad en tu correo electrónico, suscríbete en la siguiente aplicación:
