Ir al contenido
Únase al foro de la comunidad Censys : Conectar, compartir y prosperar | Empieza aquí
Blogs

HTTP/¿Quién? CVE-2023-44487

Resumen ejecutivo

  • Google y Cloudflare han publicado recientemente informes sobre un nuevo ataque de denegación de servicio denominado "Rapid Reset", que aprovecha la funcionalidad de cancelación de flujos de HTTP/2.
  • Esta técnica permite a los actores participar en un patrón de "solicitud, cancelación" a escala para producir ataques de denegación de servicio de gran volumen. Los servidores que ejecutan HTTP/2 y delegan el tráfico en servidores backend son especialmente susceptibles a este ataque.
  • Más de 555 millones de hosts en Internet parecen tener actualmente la capacidad de ejecutar HTTP/2 y, por tanto, pueden ser vulnerables a este ataque.
  • Aunque actualmente no existen soluciones para este problema, los administradores con servidores HTTP/2 habilitados que envían solicitudes a un servidor backend pueden deshabilitar temporalmente HTTP/2 en el frontend hasta que los proveedores hayan creado una solución.

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.

Los 10 mejores sistemas autónomos 

ASN Sistema autónomo Recuento de anfitriones Recuento de servicios
16509 AMAZON-02 73.4M 85.4M
46606 UNIFIEDLAYER-AS-1 29.2M 57.5M
63949 AKAMAI-LINODE-AP Nube Conectada de Akamai 25.8M 45.7M
13335 CLOUDFLARENET 39.8M 40.3M
53831 ESPACIO CUADRADO 33.7M 33.7M
14618 AMAZON-AES 23.6M 26.1M
24940 HETZNER-AS 14.2M 19.6M
19871 NETWORK-SOLUTIONS-HOSTING 9.1M 17.8M
16276 OVH 10.7M 15.9M
47846 SEDO-AS 13.7M 13.7M

 

Los 10 primeros países

País Recuento de anfitriones Recuento de servicios
Estados Unidos 295.5M 391.1M
Alemania 53.2M 60.9M
China 19.6M 29.5M
Francia 13.7M 19.7M
Países Bajos 13.6M 18.8M
Canadá 16.9M 18.5M
Reino Unido 10.7M 13.9M
Rusia 12.7M 13.5M
Singapur 7.3M 9.3M
Japón 8.3M 9.0M

Para encontrar hosts y servicios que ejecuten HTTP/2, podemos utilizar las siguientes consultas:

Búsqueda en Censy

Censys Plataforma EM

  • web_entity.instances.http.supports_http2: "true"

¿Qué se puede hacer?

  • Evalúe el grado de exposición de su servidor HTTP/2 y reduzca su superficie. Si tiene un servidor HTTP/2 habilitado que envía las solicitudes a un servidor backend, una posible solución es deshabilitar temporalmente HTTP/2 en el frontend hasta que los proveedores hayan creado una solución.
  • Algunas contramedidas eficaces comunicadas por los servicios en nube afectados incluyen la combinación de:
    • Utilización de los métodos y servicios de protección DDoS existentes.
    • Aplicar otros parches de software que pueden hacer que sus servidores web compatibles con HTTP/2 sean más resistentes.

Sobre el autor

El equipo de investigación Censys
Soluciones de gestión de la superficie de ataque
Más información