Ataque de reinicio rápido HTTP/2 que afecta a los productos NGINX de F5

Esta entrada de blog se centra en una vulnerabilidad que se descubrió recientemente relacionada con el protocolo HTTP/2. En determinadas condiciones, esta vulnerabilidad puede explotarse para ejecutar un ataque de denegación de servicio en NGINX Open Source, NGINX Plus y productos relacionados que implementan la parte del lado del servidor de la especificación HTTP/2. Para proteger sus sistemas de este ataque, recomendamos una actualización inmediata de su configuración de NGINX.

El problema con los reinicios de flujo HTTP/2

Después de establecer una conexión con un servidor, el protocolo HTTP/2 permite a los clientes iniciar transmisiones simultáneas para el intercambio de datos. A diferencia de las iteraciones anteriores del protocolo, si un usuario final decide abandonar la página o detener el intercambio de datos por cualquier otro motivo, HTTP/2 proporciona un método para cancelar la transmisión. Lo hace emitiendo un marco RST_STREAM al servidor, evitando que ejecute trabajo innecesariamente.

La vulnerabilidad se explota iniciando y cancelando rápidamente una gran cantidad de transmisiones HTTP/2 a través de una conexión establecida, eludiendo así el máximo de transmisiones simultáneas del servidor. Esto sucede porque los flujos entrantes se restablecen más rápido que lo que llegan los flujos posteriores, lo que permite que el cliente sobrecargue el servidor sin alcanzar nunca su umbral configurado.

Impacto en NGINX

Por razones de rendimiento y consumo de recursos, NGINX limita la cantidad de transmisiones simultáneas a un valor predeterminado de 128 (consulte http2_max_concurrent_streams ). Además, para equilibrar de forma óptima el rendimiento de la red y del servidor, NGINX permite al cliente persistir conexiones HTTP para hasta 1000 solicitudes de manera predeterminada usando un keepalive HTTP (ver keepalive_requests ).

Al confiar en el límite de keepalive predeterminado, NGINX evita este tipo de ataque. La creación de conexiones adicionales para eludir este límite expone a los actores maliciosos a través de herramientas de alerta y monitoreo de capa 4 estándar.

Sin embargo, si NGINX está configurado con un keepalive sustancialmente más alto que la configuración predeterminada y recomendada, el ataque puede agotar los recursos del sistema. Cuando se produce un restablecimiento de una transmisión, el protocolo HTTP/2 requiere que no se devuelvan datos posteriores al cliente en esa transmisión. Normalmente, el restablecimiento genera una sobrecarga insignificante en el servidor en forma de tareas que manejan la cancelación sin problemas. Sin embargo, eludir el umbral de transmisión de NGINX permite que un cliente aproveche esta sobrecarga y la amplifique iniciando rápidamente miles de transmisiones. Esto obliga a que la CPU del servidor se active, negando el servicio a clientes legítimos.

Denegación de servicio mediante el establecimiento de flujos HTTP/2, seguido de cancelaciones de flujos bajo límites de keepalive anormalmente altos.

Pasos para mitigar la exposición a ataques

Como servidor y proxy completo, NGINX proporciona a los administradores herramientas poderosas para mitigar ataques de denegación de servicio. Para aprovechar estas características, es esencial que se realicen las siguientes actualizaciones en los archivos de configuración de NGINX, minimizando la superficie de ataque del servidor:

• keepalive_requests debe mantenerse en la configuración predeterminada de 1000 solicitudes
• http2_max_concurrent_streams debe mantenerse en la configuración predeterminada de 128 transmisiones

También recomendamos que se agreguen estas medidas de seguridad como práctica recomendada:

• limit_conn impone un límite en la cantidad de conexiones permitidas desde un solo cliente. Esta directiva debería agregarse con una configuración razonable que equilibre el rendimiento y la seguridad de la aplicação .
• limit_req impone un límite en la cantidad de solicitudes que se procesarán dentro de un período de tiempo determinado desde un solo cliente. Esta directiva debería agregarse con una configuración razonable que equilibre el rendimiento y la seguridad de la aplicação .

Cómo estamos respondiendo

Experimentamos con múltiples estrategias de mitigación que nos ayudaron a comprender cómo este ataque podría afectar a nuestra amplia gama de clientes y usuarios. Si bien esta investigación confirmó que NGINX ya está equipado con todas las herramientas necesarias para evitar el ataque, queríamos tomar medidas adicionales para garantizar que los usuarios que necesiten configurar NGINX más allá de las especificaciones recomendadas puedan hacerlo.

Nuestra investigación arrojó un método para mejorar la resiliencia del servidor ante diversas formas de ataques de inundación que son teóricamente posibles a través del protocolo HTTP/2. Como resultado, hemos emitido un parche que aumenta la estabilidad del sistema en estas condiciones. Para protegerse contra estas amenazas, recomendamos que los usuarios de NGINX Open Source reconstruyan los binarios desde el código base más reciente y que los clientes de NGINX Plus actualicen a los paquetes más recientes (R29p1 o R30p1) inmediatamente.

Cómo funciona el parche

Para garantizar la detección temprana de ataques de inundación en NGINX, el parche impone un límite en la cantidad de transmisiones nuevas que se pueden introducir dentro de un bucle de eventos. Este límite se establece al doble del valor configurado mediante la directiva http2_max_concurrent_streams . El límite se aplicará incluso si nunca se alcanza el umbral máximo, como cuando los flujos se restablecen justo después de enviar la solicitud (como en el caso de este ataque).

Productos afectados

Esta vulnerabilidad afecta al módulo HTTP/2 NGINX ( ngx_http_v2_module ). Para obtener información sobre su producto NGINX o F5 específico que podría verse afectado, visite: https://my.f5.com/manage/s/article/K000137106 .

Para obtener más información sobre CVE-2023-44487 (ataque de reinicio rápido HTTP/2), consulte: https://www.cve.org/CVERecord?id=CVE-2023-44487

Agradecimientos

Nos gustaría reconocer a Cloudflare, Amazon y Google por su participación en el descubrimiento y la colaboración para identificar y mitigar esta vulnerabilidad.