La empresa Google ha registrado el mayor ataque DDoS a su infraestructura, cuya intensidad alcanzó 398 millones de solicitudes por segundo. Este nuevo ataque supera en 7 veces la intensidad del anterior ataque DDoS récord, en el cual los atacantes lograron generar un flujo de 47 millones de solicitudes por segundo. Para comparación, todo el tráfico de la Web se estima entre 1 y 3 mil millones de solicitudes por segundo. Además de Google, las empresas Amazon y Cloudflare también se enfrentaron a este ataque. La posibilidad de un nuevo ataque está relacionada con la identificación de una vulnerabilidad en el protocolo HTTP/2 (CVE-2023-44487), que permite dirigir un enorme flujo de solicitudes al servidor con una carga mínima sobre el cliente.
La nueva técnica de ataque se denomina 'Rapid Reset' y aprovecha los medios de multiplexión de canales de comunicación proporcionados en HTTP/2, permitiendo generar un flujo de solicitudes dentro de una conexión ya establecida, sin abrir nuevas conexiones de red y sin esperar la confirmación de recepción de paquetes. La vulnerabilidad se considera una consecuencia de una deficiencia en el protocolo HTTP/2, cuya especificación indica que al intentar abrir un número excesivo de flujos, solo se deben anular aquellos que superen el límite, sin cerrar toda la conexión de red.
Siguiendo el ejemplo de los métodos de ataque utilizados anteriormente en HTTP/2, en el nuevo ataque también se crean un gran número de flujos dentro de una única conexión. La clave de la nueva táctica es que, en lugar de esperar una respuesta después de cada solicitud enviada, se envía un marco con la bandera RST_STREAM, cancelando inmediatamente la solicitud. Cancelar la solicitud en una etapa temprana permite evitar el tráfico de retorno hacia el cliente y eludir las restricciones existentes en los servidores HTTP sobre el número máximo de flujos que se pueden abrir simultáneamente en una sola conexión por HTTP/2. De este modo, el volumen de solicitudes dirigidas al servidor HTTP deja de depender de los retrasos entre el envío de la solicitud y la recepción de la respuesta (RTT, tiempo de ida y vuelta) y se basa únicamente en el ancho de banda del canal de comunicación.
Dado que para llevar a cabo un ataque del lado del cliente es suficiente enviar solicitudes sin recibir respuestas, el ataque puede realizarse con un costo mínimo. Por ejemplo, el ataque registrado por Cloudflare de 201 millones de solicitudes por segundo se llevó a cabo con un botnet relativamente pequeño de 20,000 computadoras. Del lado servidores los costos de procesamiento de las solicitudes entrantes son significativamente mayores, a pesar de su cancelación, ya que es necesario realizar operaciones como la asignación de estructuras de datos para nuevos flujos, el análisis de la solicitud, la descompresión del encabezado y la coincidencia de la URL con el recurso. En un ataque a proxies inversos, el ataque puede extenderse a los backends, ya que el proxy puede redirigir la solicitud al backend antes de procesar el marco RST_STREAM.
El ataque solo puede realizarse contra servidores vulnerables que soporten HTTP/2 (script para verificar la manifestación de vulnerabilidad en servidores, herramienta para realizar el ataque). Hasta ahora no se han registrado ataques contra HTTP/3 y la posibilidad de realizarlos no ha sido completamente analizada, pero representantes de Google recomiendan a los desarrolladores servidores agregar medidas de protección en las implementaciones de HTTP/3, similares a las implementadas para bloquear ataques en HTTP/2.
Vulnerabilidad y disponibilidad de parches para servidores HTTP y proxies:
- nginx (anuncio, aclaración de que la vulnerabilidad no se manifiesta plenamente en nginx con la configuración por defecto, ya que el ataque se topa con el límite en el número de solicitudes por conexión (es decir, después de cada 1000 solicitudes, la conexión se restablecerá). Se ha añadido protección adicional mediante la directiva “limit_req” para restringir la intensidad de las solicitudes).
- En HAProxy, se incorporó protección efectiva contra el exceso del límite en el número de flujos HTTP/2 desde 2018 y está activa desde la versión 1.9-dev.
- Apache httpd (se crea cierta carga en httpd, pero no se extiende a los backends y se limita a los límites de conexiones de clientes en vigor desde 2016).
- mod_h2 para Apache httpd.
- caddy
- envoy
- golang (el problema se resolvió en las versiones Go 1.21.3 y 1.20.10).
- h2o (parche).
- grpc-go
- hyper (la vulnerabilidad no se manifiesta).
- jetty (corregido en 12.0.2, 11.0.17, 10.0.17 y 9.4.53.v20231009).
- netty
- nghttp2 (corregido en la versión 1.57.0).
- Facebook proxygen
- .NET y ASP.NET Core (la vulnerabilidad afecta al servidor http ASP.NET Core Kestrel).
- Node.js
- proxygen
- swift-nio-http2 (corregido en la versión 1.28.0).
- Apache Tomcat (corregido en las versiones 11.0.0-M12, 10.1.14, 9.0.81, 8.5.94).
- Apache Traffic Server (corregido en la rama 9.2.x).
Fuente: opennet.ru
