Una vulnerabilidad de restablecimiento rápido en HTTP/2 provoca el DDoS más grande de la historia

• Google mitigó el DDoS más grande de la historia, con 398 millones de solicitudes por segundo.
  • Durante los 2 minutos que duró el ataque, se generaron más solicitudes que el tráfico mensual de Wikipedia.
• Este ataque fue provocado por Rapid Reset, una nueva vulnerabilidad de HTTP/2.
  • Aprovecha la multiplexación de streams y la función de cancelación de solicitudes según el funcionamiento de HTTP/2.
  • Un solo cliente puede generar una cantidad ilimitada de solicitudes, siempre que el ancho de banda de red lo permita.
    • Normalmente, los ataques DoS de capa 7 dependen del RTT y del número de conexiones simultáneas, por lo que un solo cliente tiene límites para generar muchas solicitudes.
    • Pero este método permite generar solicitudes muy rápidamente mediante el proceso de cancelarlas inmediatamente después de crearlas.
  • A diferencia de los DDoS récord anteriores, este ataque puede ser efectivo con una cantidad reducida de dispositivos.
  • Esta vulnerabilidad puede consultarse en CVE-2023-44487 y tiene una puntuación CVSS de 7.5, considerada grave.
• Otros proveedores, como Cloudflare y AWS, también recibieron ataques DDoS de 201 millones de RPS y 155 millones de RPS, respectivamente.
  • Cloudflare informó que el ataque fue lanzado por una botnet de unas 20 mil máquinas.
    • Los DDoS masivos anteriores solían provenir de botnets de decenas de miles a millones de dispositivos.
• Servidores web como Nginx y Caddy están aplicando parches rápidamente.
  • De forma llamativa, HAProxy ya había resuelto este problema en 2018.

[kuroneko]

• El hilo de HN del enlace de arriba
• Hilo de HN relacionado
  • Google - Cómo funciona: el novedoso ataque DDoS de "restablecimiento rápido" en HTTP/2
• Hilo de HN relacionado
  • Cloudflare - Ataque DDoS de escala récord debido a una vulnerabilidad zero-day en HTTP/2

Casi 400 millones de solicitudes por segundo... de verdad da miedo.
Era una vulnerabilidad en implementaciones de HTTP/2, y también es impresionante que Google, Cloudflare y AWS, entre otros, hayan logrado mitigarla.

Lo que más me llama la atención es que HAProxy resolvió este problema en 2018.
No identificaron ni corrigieron esta vulnerabilidad como tal en ese momento, pero al revisarlo después, resultó que el problema planteado en 2018 contenía la idea que resolvía esta vulnerabilidad.

En fin, quienes usen servidores web deberían actualizar a una versión en la que esta vulnerabilidad ya esté corregida.