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

Esta entrada de blog se centra en una vulnerabilidad descubierta recientemente relacionada con el protocolo HTTP/2. En determinadas condiciones, esta vulnerabilidad puede aprovecharse para llevar a cabo un ataque de denegación de servicio contra NGINX Open Source, NGINX Plus y otros productos relacionados que implementan la parte del servidor de la especificación HTTP/2. Para proteger sus sistemas frente a este ataque, recomendamos actualizar de inmediato la configuración de NGINX.

El problema de los reinicios de flujo de HTTP/2

Tras establecer una conexión con un servidor, el protocolo HTTP/2 permite a los clientes iniciar flujos simultáneos para intercambiar datos. A diferencia de las versiones anteriores del protocolo, si un usuario final decide abandonar la página o detener el intercambio de datos por cualquier otro motivo, HTTP/2 ofrece un método para cancelar el flujo. Para ello, envía una trama RST_STREAM al servidor, evitando que este realice trabajo innecesario.

La vulnerabilidad se explota iniciando y cancelando rápidamente un gran número de flujos HTTP/2 a través de una conexión establecida, eludiendo así el límite máximo de flujos simultáneos del servidor. Esto ocurre porque los flujos entrantes se restablecen más rápido de lo que llegan los siguientes, lo que permite al cliente sobrecargar el servidor sin alcanzar en ningún momento el umbral configurado.

Impacto en NGINX

Por motivos de rendimiento y consumo de recursos, NGINX limita de forma predeterminada a 128 el número de flujos simultáneos (consulte http2_max_concurrent_streams). Además, para lograr un equilibrio óptimo entre el rendimiento de la red y el del servidor, NGINX permite de forma predeterminada que el cliente mantenga conexiones HTTP persistentes durante un máximo de 1000 solicitudes mediante HTTP keepalive (consulte keepalive_requests).

Al utilizar el límite de keepalive predeterminado, NGINX evita este tipo de ataque. La creación de conexiones adicionales para eludir este límite permite detectar a los actores maliciosos mediante herramientas estándar de supervisión y alertas de capa 4.

Sin embargo, si NGINX se configura con un valor de keepalive considerablemente superior al predeterminado y recomendado, el ataque puede agotar los recursos del sistema. Cuando se restablece un flujo, el protocolo HTTP/2 exige que no se devuelvan al cliente más datos a través de dicho flujo. Por lo general, el restablecimiento genera una sobrecarga insignificante en el servidor, derivada de las tareas que gestionan correctamente la cancelación. Sin embargo, eludir el umbral de flujos de NGINX permite que un cliente aproveche esta sobrecarga y la amplifique iniciando rápidamente miles de flujos. Esto provoca un aumento brusco del uso de la CPU del servidor e impide prestar servicio a los clientes legítimos.

Denegación de servicio mediante el establecimiento de flujos HTTP/2, seguido de la cancelación de dichos flujos con límites de keepalive anormalmente altos

Medidas para reducir la exposición a ataques

Como servidor y proxy con todas las funciones, NGINX proporciona a los administradores potentes herramientas para mitigar los ataques de denegación de servicio. Para aprovechar estas funciones, es esencial realizar las siguientes actualizaciones en los archivos de configuración de NGINX, a fin de minimizar la superficie de ataque del servidor:

• keepalive_requests debe mantenerse en el valor predeterminado de 1000 solicitudes.
• http2_max_concurrent_streams debe mantenerse en la configuración predeterminada de 128 flujos.

También recomendamos añadir estas medidas de seguridad como práctica recomendada:

• limit_conn limita el número de conexiones permitidas desde un único cliente. Esta directiva debe añadirse con una configuración razonable que equilibre el rendimiento de la aplicación y la seguridad.
• limit_req limita el número de solicitudes de un mismo cliente que se procesarán durante un periodo de tiempo determinado. Esta directiva debe añadirse con una configuración razonable que equilibre el rendimiento de la aplicación y la seguridad.

Cómo estamos respondiendo

Experimentamos con varias estrategias de mitigación que nos ayudaron a comprender cómo podría afectar este ataque a nuestra amplia variedad de clientes y usuarios. Aunque esta investigación confirmó que NGINX ya cuenta con todas las herramientas necesarias para evitar el ataque, quisimos adoptar medidas adicionales para garantizar que los usuarios que necesiten configurar NGINX más allá de las especificaciones recomendadas puedan hacerlo.

Nuestra investigación permitió desarrollar un método para mejorar la resiliencia de los servidores frente a diversas formas de ataques de inundación teóricamente posibles a través del protocolo HTTP/2. Como resultado, hemos publicado un parche que aumenta la estabilidad del sistema en estas condiciones. Para protegerse frente a estas amenazas, recomendamos que los usuarios de NGINX Open Source vuelvan a compilar los binarios a partir del código base más reciente y que los clientes de NGINX Plus actualicen de inmediato a los paquetes más recientes (R29p1 o R30p1).

Cómo funciona el parche

Para garantizar la detección temprana de ataques de inundación en NGINX, el parche limita el número de flujos nuevos que pueden iniciarse en una sola iteración del bucle de eventos. Este límite se establece en el doble del valor configurado mediante la directiva http2_max_concurrent_streams. El límite se aplica aunque nunca se alcance el umbral máximo, como ocurre 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 de NGINX (ngx_http_v2_module). Para obtener información sobre el producto específico de NGINX o F5 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 restablecimiento rápido de HTTP/2, consulte: https://www.cve.org/CVERecord?id=CVE-2023-44487

Agradecimientos

Nos gustaría reconocer la labor de Cloudflare, Amazon y Google en el descubrimiento de esta vulnerabilidad, así como su colaboración para identificarla y mitigarla.

Esta entrada del blog se ha actualizado con información adicional sobre las medidas correctivas y para mejorar su claridad tras su fecha de publicación original.