En los últimos dos días, hemos visto un gran aumento en un extraño vector de ataque de amplificación, que usa el protocolo Memcached, originado del puerto UDP 11211.
CC BY-SA 2.0 image por David Trawin
En el pasado, hemos hablado mucho acerca de los ataques de amplificación que ocurren en internet. Nuestras últimas dos publicaciones del blog sobre el tema fueron:
Amplificaciones de SSDP que cruzan los 100 Gbps. Curiosamente, desde entonces hemos sido objetivo de un ataque SSDP de 196 Gbps.
Estadísticas generales sobre varios ataques de amplificación que vemos.
La idea general detrás de todos los ataques de amplificación es la misma. Un atacante capaz de suplantar la IP envía solicitudes falsas a un servidor UDP vulnerable. El servidor UDP, que no sabe que la solicitud es falsa, prepara cordialmente la respuesta. El problema sucede cuando se envían miles de respuestas a un host de destino desprevenido, sobrecargando sus recursos, generalmente la propia red.
Los ataques de amplificación son efectivos porque, a menudo, los paquetes de respuesta son mucho más grandes que los paquetes de solicitud. Una técnica preparada cuidadosamente permite que un atacante con una capacidad de suplantación de IP limitada (por ejemplo, 1 Gbps) lance ataques muy grandes (que alcanzan los 100 Gbps) mediante la «amplificación» del ancho de banda del atacante.
Memcrashed
Los ataques desconocidos de amplificación suceden todo el tiempo. A menudo vemos paquetes de «chargen» o «call of duty» que alcanzan nuestros servidores.
Sin embargo, el descubrimiento de un nuevo vector de amplificación, que permite una enorme amplificación, rara vez sucede. Este nuevo Memcached UDP DDoS entra sin duda en esta categoría.
El DDosMon de Qihoo 360 supervisa los vectores de ataque de amplificación, y este gráfico muestra los recientes ataques de Memcached/11211:
El número de ataques de Memcached era relativamente bajo, hasta que empezó a aumentar hace un par de días. Nuestros gráficos también lo confirman. Estos son los ataques en paquetes por segundo de los últimos cuatro días:
Mientras que el recuento de paquetes por segundo no es enorme, el ancho de banda generado sí lo es:
$ tcpdump -n -t -r memcrashed.pcap udp and port 11211 -c 10
IP 87.98.205.10.11211 > 104.28.1.1.1635: UDP, length 13
IP 87.98.244.20.11211 > 104.28.1.1.41281: UDP, length 1400
IP 87.98.244.20.11211 > 104.28.1.1.41281: UDP, length 1400
IP 188.138.125.254.11211 > 104.28.1.1.41281: UDP, length 1400
IP 188.138.125.254.11211 > 104.28.1.1.41281: UDP, length 1400
IP 188.138.125.254.11211 > 104.28.1.1.41281: UDP, length 1400
IP 188.138.125.254.11211 > 104.28.1.1.41281: UDP, length 1400
IP 188.138.125.254.11211 > 104.28.1.1.41281: UDP, length 1400
IP 5.196.85.159.11211 > 104.28.1.1.1635: UDP, length 1400
IP 46.31.44.199.11211 > 104.28.1.1.6358: UDP, length 13En el pico vimos 260 Gbps de tráfico de Memcached UDP entrante. Esto es enorme para un nuevo vector de amplificación. Pero los números no mienten. Es posible porque todos los paquetes reflejados son muy grandes. Así es como se ve en tcpdump:
La mayoría de los paquetes tienen un tamaño de 1400 bytes. Si se hace el cálculo, 23 Mpps x 1400 bytes da 257 Gbps de ancho de banda, exactamente lo que muestra el gráfico.
¿Memcached crea UDP?
Me sorprendí al enterarme de que Memcached crea UDP, ¡pero es lo que hay! ¡La especificación de protocolo muestra que es uno de los mejores protocolos que existen para usar en amplificación! No hay absolutamente ninguna comprobación, y los datos se le entregarán al cliente con extrema rapidez. Además, la solicitud puede ser pequeña y la respuesta, enorme (hasta 1 MB).
Lanzar este tipo de ataque es muy sencillo. Primero, el atacante implanta una carga grande en un servidor Memcached expuesto. Luego, el atacante falsifica el mensaje de solicitud de "get" con destino de la IP de origen.
$ sudo tcpdump -ni eth0 port 11211 -t
IP 172.16.170.135.39396 > 192.168.2.1.11211: UDP, length 15
IP 192.168.2.1.11211 > 172.16.170.135.39396: UDP, length 1400
IP 192.168.2.1.11211 > 172.16.170.135.39396: UDP, length 1400
...(repeated hundreds times)...La ejecución sintética con Tcpdump muestra el tráfico:
15 bytes de solicitud desencadenaron 134 KB de respuesta. ¡Este es un factor de amplificación multiplicado por 10 000! En la práctica, hemos visto que un resultado de solicitud de 15 bytes da como resultado una respuesta de 750 kB (una amplificación multiplicada por 51 200).
IP de origen
Hay servidores Memcached vulnerables por todo el mundo, con mayor concentración en América del norte y Europa. Aquí hay un mapa de las IP de origen que hemos visto en cada uno de nuestros más de 120 puntos de presencia:
┌─ips─┬─srcASN──┬─ASName───────────────────────────────────────┐
│ 578 │ AS16276 │ OVH │
│ 468 │ AS14061 │ DIGITALOCEAN-ASN - DigitalOcean, LLC │
│ 231 │ AS7684 │ SAKURA-A SAKURA Internet Inc. │
│ 199 │ AS9370 │ SAKURA-B SAKURA Internet Inc. │
│ 165 │ AS12876 │ AS12876 │
│ 119 │ AS9371 │ SAKURA-C SAKURA Internet Inc. │
│ 104 │ AS16509 │ AMAZON-02 - Amazon.com, Inc. │
│ 102 │ AS24940 │ HETZNER-AS │
│ 81 │ AS26496 │ AS-26496-GO-DADDY-COM-LLC - GoDaddy.com, LLC │
│ 74 │ AS36351 │ SOFTLAYER - SoftLayer Technologies Inc. │
│ 65 │ AS20473 │ AS-CHOOPA - Choopa, LLC │
│ 49 │ AS49981 │ WORLDSTREAM │
│ 48 │ AS51167 │ CONTABO │
│ 48 │ AS33070 │ RMH-14 - Rackspace Hosting │
│ 45 │ AS19994 │ RACKSPACE - Rackspace Hosting │
│ 44 │ AS60781 │ LEASEWEB-NL-AMS-01 Netherlands │
│ 42 │ AS45899 │ VNPT-AS-VN VNPT Corp │
│ 41 │ AS2510 │ INFOWEB FUJITSU LIMITED │
│ 40 │ AS7506 │ INTERQ GMO Internet,Inc │
│ 35 │ AS62567 │ DIGITALOCEAN-ASN-NY2 - DigitalOcean, LLC │
│ 31 │ AS8100 │ ASN-QUADRANET-GLOBAL - QuadraNet, Inc │
│ 30 │ AS14618 │ AMAZON-AES - Amazon.com, Inc. │
│ 30 │ AS31034 │ ARUBA-ASN │
└─────┴─────────┴──────────────────────────────────────────────┘Curiosamente, nuestros centros de datos en EWR, HAM y HKG han visto un número desproporcionadamente alto de IP atacantes. Esto es así porque la mayoría de los servidores vulnerables están ubicados en los principales proveedores de hosting. Los números de AS de las IP que hemos visto son estos:
La mayoría de los servidores Memcached que hemos visto venían de AS16276 - AS14061 - Digital Ocean y AS7684 - Sakura.
En total, hemos visto solo 5 729 IP de fuente única de servidores Memcached. Esperamos ver ataques mucho más grandes en el futuro, ya que Shodan informa sobre 88 000 servidores Memcached abiertos:
Solucionémoslo
Es necesario solucionar esto y prevenir nuevos ataques. A continuación verá una lista de las cosas que deberían hacerse.
Usuarios de Memcached
Si está usando Memcached, por favor, deshabilite la asistencia de UDP si no la está usando. Al iniciar Memcached, puede especificar --listen 127.0.0.1 para escuchar solo al host local, y -U 0 para deshabilitar UDP completamente. Por defecto, Memcached escucha en INADDR_ANY y se ejecuta con la asistencia de UDP HABILITADA. Documentación:
$ echo -en "\x00\x00\x00\x00\x00\x01\x00\x00stats\r\n" | nc -q1 -u 127.0.0.1 11211
STAT pid 21357
STAT uptime 41557034
STAT time 1519734962
...Puede probar con facilidad si su servidor es vulnerable ejecutando:
Si ve una respuesta que no está vacía (como la de arriba), su servidor es vulnerable.
Administradores del sistema
$ nmap TARGET -p 11211 -sU -sS --script memcached-info
Starting Nmap 7.30 ( https://nmap.org ) at 2018-02-27 12:44 UTC
Nmap scan report for xxxx
Host is up (0.011s latency).
PORT STATE SERVICE
11211/tcp open memcache
| memcached-info:
| Process ID 21357
| Uptime 41557524 seconds
| Server time 2018-02-27T12:44:12
| Architecture 64 bit
| Used CPU (user) 36235.480390
| Used CPU (system) 285883.194512
| Current connections 11
| Total connections 107986559
| Maximum connections 1024
| TCP Port 11211
| UDP Port 11211
|_ Authentication no
11211/udp open|filtered memcache¡Asegúrese de que los servidores Memcached cuenten con un firewall contra internet! Para probar si se puede acceder a ellos usando UDP, recomiendo el ejemplo nc anterior. Para verificar si TCP se cierra, ejecutE nmap:
Proveedores de servicios de Internet
Para anular tales ataques en el futuro, necesitamos corregir los protocolos vulnerables y la suplantación de IP. Mientras se permita la suplantación de IP en internet, estaremos en problemas.
Ayúdenos a localizar a los responsables de estos ataques. No necesitamos saber quién tiene servidores Memcached problemáticos, sino quién les ha enviado las consultas en primer lugar. ¡No podemos hacer esto sin su ayuda!
Desarrolladores
Por favor, por favor, por favor: Deje de usar UDP. Si debe usarlo, por favor, no lo habilite por defecto. Si desconoce lo que es un ataque de amplificación, por la presente le prohíbo que vuelva a escribir SOCK_DGRAM en su editor.
Ya hemos pasado por esto muchas veces. DNS, NTP, Chargen, SSDP y ahora Memcached. Si utiliza UDP, siempre debe responder con un tamaño de paquete estrictamente menor que el de la solicitud. De lo contrario, se abusará de su protocolo. Recuerde también que la gente se olvida de poner el firewall. Sea un buen ciudadano. No invente un protocolo basado en UDP que carezca de cualquier tipo de autenticación.
Eso es todo
Nadie sabe qué tan grandes serán los ataques de Memcached antes de que limpiemos los servidores vulnerables. Ya había rumores de amplificaciones de 0,5 Tbps en los últimos días, y esto es solo el comienzo.
Finalmente, si es cliente de Cloudflare, no tiene de qué preocuparse. La arquitectura Anycast de CloudFlare funciona bien para distribuir la carga en caso de grandes ataques de amplificación, y, a menos que su IP de origen esté expuesta, está seguro con Cloudflare.
Prólogo
Un comentario (debajo) señala que la posibilidad de utilizar Memcached para DDoS se debatió en una presentación en 2017.
Actualización
Hemos recibido noticias de que Digital Ocean, OVH, Linode y Amazon han abordado el problema de Memcached, y sus redes ya no deberían ser un vector en futuros ataques. ¡Hurra!
¿El manejo de los ataques DDoS le resulta interesante? Únase a nuestro famoso equipo global en Londres, Austin, San Francisco y nuestra oficina de élite en Varsovia, Polonia.