Una mirada más atenta a la mecánica de ataque
El 10 de octubre, Google y Cloudflare publicaron informes sobre el abuso de una función específica del protocolo HTTP/2, que provoca un aumento de la carga y una posible denegación de servicio en servidores que no pueden atender muchas solicitudes simultáneas.
Sus informes entran en detalle sobre un escenario en el que un actor puede eludir las restricciones establecidas para limitar el número de solicitudes simultáneas que llegan a un servidor HTTP/2 (para cada cliente) mediante la cancelación de una solicitud justo después de que se haga, reiniciando efectivamente el contador interno de solicitudes para cada solicitud de cancelación. Esto significa que el actor puede entonces enviar infinitamente nuevas peticiones al servidor sin llegar a estos límites.
Un servidor web bien optimizado en el que el servicio HTTP/2 interactúa directamente con el cliente, y no se recuperan datos externos a través de la lógica de negocio (es decir, un servidor que no reenvía o proxy peticiones a otro servidor), sin duda verá un cierto aumento en la utilización, pero nada que el servidor no debería ser capaz de manejar. El problema se hace más evidente cuando el servidor HTTP/2 intenta proxy cada solicitud a través de alguna conexión en red (como un servidor Nginx proxy conexiones a un servicio API que se ejecuta en Apache).
En este escenario, los datos de la petición tienen que ser almacenados por el proxy y luego enviados a un servicio backend; ese servicio backend debe entonces procesar esos datos y enviar la respuesta de vuelta al servidor HTTP/2. Mientras tanto, a la espera de esas respuestas proxy, varias áreas del proceso en ejecución pueden estar utilizando memoria y recursos que aún no se han limpiado.
En resumen, un cliente envía una solicitud HTTP/2 válida, el servidor HTTP/2 analiza esa solicitud, la envía a un servidor backend y espera una respuesta. Sin embargo, el cliente cancela inmediatamente esa petición, por lo que el servidor HTTP2 también tiene que cancelar la petición al backend, pero en ese momento, los datos y los recursos ya han sido asignados y utilizados. Y como el contador de peticiones máximas se pone a cero continuamente, pueden llegar infinitas peticiones sin que nada las detenga.
El blog de Google lo dijo mejor con lo siguiente:
"...el cliente puede abrir 100 flujos y enviar una petición a cada uno de ellos en un único viaje de ida y vuelta; el proxy leerá y procesará cada flujo en serie, pero las peticiones a los servidores backend pueden paralelizarse de nuevo. El cliente puede entonces abrir nuevos flujos a medida que recibe respuestas a los anteriores. Esto da un rendimiento efectivo para una única conexión de 100 peticiones por viaje de ida y vuelta, con constantes de tiempo de viaje de ida y vuelta similares a las peticiones HTTP/1.1. De este modo, la utilización de cada conexión se multiplica casi por 100".
Acertadamente denominado "Ataque de reinicio rápido" de HTTP/2 (basado en que los clientes reinician cada solicitud saliente), los métodos descritos afectan técnicamente a cualquier implementación de HTTP/2, lo que significa que no es específico de un proveedor o producto, sino una debilidad del propio protocolo. Y cualquier producto que soporte HTTP/2 (actualmente) es susceptible a este ataque.
En resumen, este ataque pone una gran cantidad de presión entre los servidores frontales y los servidores backend con los que se comunican, como en entornos fuertemente proxyados. Esta es la razón por la que la mayoría de los informes de este ataque provienen de proveedores de servicios que se ocupan en gran medida del equilibrio de carga y el proxy HTTP, como Cloudflare y Google.
Lo que ve Censys
Censys puede determinar si un servicio HTTP puede aceptar y procesar peticiones HTTP/2 entrantes, pero no tiene ninguna información adicional sobre la implementación subyacente fuera de lo que los servidores HTTP nos dicen que se está ejecutando (Por ejemplo, una cabecera de servidor que nos dice que es Apache o Nginx). En el momento de escribir estas líneas no existen parches ni soluciones concretas. Si tuviéramos que adivinar, no se trataría de un cambio en el protocolo subyacente, sino de una solución en las propias implementaciones del protocolo. En cualquier caso, las implementaciones del protocolo HTTP/2 se modificarán, y los propietarios de los hosts tendrán que actualizar sus servidores.
Dado que el protocolo HTTP2 no incorpora ninguna identificación o versionado semántico específico, aunque se aplique una solución o corrección, Censys sólo podrá identificar si el protocolo HTTP/2 es compatible o no.
A fecha de 10 de octubre de 2023, Censys observó 556,3M de hosts ejecutando 719,8M de servidores habilitados para HTTP/2. Tenga en cuenta que esto incluye servidores HTTP con la capacidad de actualizarse a HTTP/2, pero no necesariamente todos los que lo están ejecutando actualmente.
