[10/10/2023] En los últimos dos meses, los atacantes han estado abusando de una característica del protocolo de comunicación web HTTP/2 que hace que los servidores de aplicaciones web, los equilibradores de carga y los proxies web sean vulnerables a ataques de denegación de servicio distribuidos (DDoS) de una escala sin precedentes. Google, AWS, Cloudflare y otros importantes proveedores de infraestructuras en la nube, así como proveedores de servidores web, han estado trabajando en estrategias de mitigación y parches en grupos privados hasta que hoy se ha revelado el punto débil.
Los recién bautizados ataques DDoS HTTP/2 Rapid Reset aprovechan la capacidad de multiplexación de flujos del protocolo HTTP/2, que permite enviar varias peticiones HTTP en paralelo a través de la misma conexión de transporte TCP, y en particular la capacidad de los clientes para restablecer unilateralmente esos flujos. El problema se rastrea como CVE-2023-44487 y las organizaciones deberían comprobar si sus proveedores de servidores web y equilibradores de carga disponen de parches o recomendaciones de mitigación.
La multiplexación de flujos hace más eficaces los ataques DDoS
En la antigua versión 1 de HTTP, que aún soportan la mayoría de los servidores y clientes web, se pueden enviar múltiples peticiones a través de una única conexión TCP, pero se envían en serie y el servidor las procesa y responde en el orden en que se recibieron.
En HTTP/2, múltiples peticiones llamadas flujos que se componen de tramas como HEADERS o DATA pueden ser enviadas a través de una conexión TCP simultáneamente y fuera de orden. Esto se debe a que cada flujo tiene un ID asociado, por lo que el servidor siempre sabrá de qué flujo forma parte una trama y cómo responder. Esto se conoce como multiplexación de flujos y permite un uso más eficiente de las conexiones TCP y acelera los tiempos de carga de la página.
Imagínese una página web moderna con multitud de recursos, scripts de terceros e imágenes cargadas desde distintas ubicaciones. Un navegador que acceda a esa página a través de HTTP/2 empezará inmediatamente a cargar esos recursos en paralelo, dando prioridad a los que estén a la vista del usuario. Si el usuario hace clic inmediatamente en un botón y se aleja de la página, el navegador puede cerrar los flujos, aunque los recursos no se hayan cargado o renderizado completamente sin cerrar toda la conexión y abrir nuevas peticiones.
"Desde finales del 2021, la mayoría de los ataques DDoS de Capa 7 que hemos observado en los servicios propios de Google y en los proyectos de Google Cloud protegidos por Cloud Armor se han basado en HTTP/2, tanto por el número de ataques como por los picos de peticiones", señalan los ingenieros de Google en una entrada de blog en la que explican el nuevo ataque. "Uno de los principales objetivos de diseño de HTTP/2 era la eficiencia y, por desgracia, las características que hacen que HTTP/2 sea más eficiente para los clientes legítimos también se pueden utilizar para hacer que los ataques DDoS sean más eficientes".
Eludir los límites de flujos concurrentes con los reinicios rápidos
Dado que un servidor necesita consumir ciclos de CPU y memoria para procesar cada trama y flujo, la posibilidad de abusar de los flujos concurrentes para agotar los recursos de un servidor y, por tanto, provocar una situación de denegación de servicio, ha sido obvia para los desarrolladores del protocolo desde el principio. Por eso añadieron un parámetro llamado SETTINGS_MAX_CONCURRENT_STREAMS que el servidor comunicará a los clientes finales durante la primera conexión a través de una trama SETTINGS.
Por defecto, el valor de este ajuste es ilimitado, pero los diseñadores del protocolo recomiendan que no sea inferior a 100 para mantener un paralelismo eficiente. Debido a esto, en la práctica, muchos clientes no esperan a la trama SETTINGS, y simplemente asumen un límite mínimo de 100 y envían 100 tramas desde el principio.
El problema viene con otra característica llamada RST_STREAM que significa "reset stream". Se trata de un tipo de trama que un cliente puede enviar a un servidor para indicar que debe cancelarse un ID de secuencia previamente abierto. Esto permite al cliente cancelar solicitudes de recursos que ya no necesita, por ejemplo, porque el usuario ha abandonado la página antes de que se cargara el recurso. Es útil porque le dice al servidor que deje de responder a una solicitud anterior y no desperdicie ancho de banda.
Sin embargo, hay un inconveniente. Al enviar una trama RST_STREAM el flujo objetivo ya no cuenta para el límite máximo de flujos concurrentes, por lo que el cliente puede abrir inmediatamente un nuevo flujo después de enviar un reset para uno anterior. Esto significa que incluso con un límite de flujos concurrentes de 100, el cliente puede abrir y reiniciar cientos de flujos sobre la misma conexión TCP en rápida sucesión.
El servidor todavía necesita gastar recursos para procesar las tramas RST_STREAM. Aunque no sea mucho, con millones de peticiones se acumulan rápidamente. Utilizando esta técnica, los atacantes han conseguido lanzar ataques DDoS de una escala sin precedentes contra servidores alojados en Google, Cloudflare y AWS.
"Cuando un servidor HTTP/2 es capaz de procesar las tramas RST_STREAM enviadas por el cliente y descomponer el estado con la suficiente rapidez, estos reinicios rápidos no causan ningún problema", afirman los ingenieros de Cloudflare en su informe. "Donde empiezan a surgir problemas es cuando hay algún tipo de retraso o demora en la puesta en orden. El cliente puede hacer tantas peticiones que se acumule trabajo atrasado, lo que provoca un consumo excesivo de recursos en el servidor".
El mayor ataque HTTP/2 Rapid Reset observado por Google alcanzó un máximo de 398 millones de solicitudes por segundo (rps). En comparación, el mayor ataque observado por la empresa en el 2022 alcanzó un máximo de 46 millones de rps. El ataque que afectó a Cloudflare en agosto alcanzó un pico de 201 millones de rps, tres veces mayor que el mayor ataque DDoS que la empresa había detectado anteriormente. Este nuevo ataque HTTP/2 Rapid Reset se lanzó desde una botnet de sólo 22 mil computadoras, que es pequeña en comparación con otras botnets.
Múltiples variaciones del ataque DDoS HTTP/2
Los ataques que utilizan la nueva técnica HTTP/2 continúan, y Google ha visto múltiples variantes, algunas de las cuales son probablemente en respuesta a las mitigaciones. Por ejemplo, una variante de ataque abrió y restableció flujos en lotes, esperando antes de enviar las tramas RST_STREAM y abriendo después otro lote. Es probable que esto sirva para contrarrestar las medidas de mitigación que se basan en la detección de un gran número de tramas RST_STREAM en la misma conexión TCP y el cierre de la conexión como respuesta.
"Estos ataques pierden la principal ventaja de los ataques de cancelación al no maximizar la utilización de la conexión, pero todavía tienen algunas eficiencias de implementación sobre los ataques DDoS HTTP/2 estándar", dijeron los ingenieros de Google. "Pero esta variante sí significa que cualquier mitigación basada en cancelaciones de flujo de limitación de velocidad debe establecer límites bastante estrictos para ser efectiva".
Otra variante no utiliza las cancelaciones RST_STREAM en absoluto y, en su lugar, intenta abrir tantos flujos simultáneos como sea posible, ignorando el límite anunciado por el servidor. El estándar HTTP/2 dice que, en este caso, los flujos que superen el límite deben ser invalidados por el servidor, pero la conexión TCP completa no debe ser cancelada. Así que esta variante de ataque permite a los atacantes mantener el canal de peticiones lleno en todo momento.
"No creemos que el simple bloqueo de solicitudes individuales sea una solución viable contra este tipo de ataques, sino que es necesario cerrar toda la conexión TCP cuando se detecta un abuso", afirman los ingenieros de Google.
Mitigación y parches para los ataques DDoS HTTP/2
Las estrategias de mitigación contra estos ataques no son sencillas porque existen usos legítimos para las cancelaciones RST_STREAM, por lo que cada propietario de servidor debe decidir cuándo se está produciendo un abuso y la dureza de la respuesta en función de las estadísticas de conexión y la lógica empresarial. Por ejemplo, si una conexión TCP tiene más de 100 peticiones y el cliente cancela más del 50% de ellas, la conexión podría considerarse abusiva. Las respuestas podrían ir desde el envío contundente de tramas GOAWAY o el cierre inmediato de la conexión TCP.
Otra respuesta podría ser bloquear una dirección IP infractora para que no pueda acceder al servicio a través de HTTP/2 y relegarlo a HTTP 1.x sólo temporalmente. El problema con los filtros IP es que varios clientes pueden compartir la misma dirección IP y no todos pueden ser maliciosos. Al limitar las peticiones a HTTP 1.x, los clientes no maliciosos detrás de una IP filtrada podrán seguir accediendo al servicio web, aunque experimenten una baja de rendimiento.
Los desarrolladores de Nginx, un popular proxy inverso y equilibrador de carga, también proporcionaron mitigaciones que se basan en funciones específicas que el servidor ya tiene implementadas, como keepalive_requests, limit_conn y limit_req. Además, en los próximos días prepararán un parche que limitará aún más el impacto de este tipo de ataques.
Microsoft, AWS, F5 y otras empresas de infraestructuras y desarrolladores de software de servidores web o de equilibrio de carga han publicado mitigaciones o parches. Los usuarios pueden seguir la entrada oficial en el rastreador de CVE para obtener enlaces con respuestas actualizadas de los proveedores.
Basado en el artículo de Lucian Constantin (CSO) y editado por CIO Perú