Publicado originalmente el 29 de septiembre de 2023 | Actualizado el 10 de octubre de 2023
Por: Dave Andrews, Marcus Hildum, Sergio Ruiz
Actualización: HTTP/2 Rapid Reset Attack – CVE-2023-44487
Siguiendo el breve blog inicial a continuación, Edgio se comprometió con colegas de toda la industria en la definición y divulgación responsable de CVE-2023-44487 – HTTP/2 Rapid Reset Attack.
El problema subyacente afecta a muchas implementaciones de servidores HTTP/2, lo que hace que las implicaciones del ataque sean mucho más amplias de lo que Edgio se había dado cuenta anteriormente. Edgio aconseja a todos los clientes que ejecutan infraestructura pública que actualicen a versiones parcheadas de sus servidores tan pronto como estén disponibles, y/o desactiven HTTP/2 temporalmente.
Edgio también está disponible para ayudar a mitigar el riesgo para nuestros clientes realizando la terminación de HTTP/2 y proxying HTTP/1,1 de nuevo a la infraestructura de los clientes. Por favor, comuníquese con nosotros para iniciar este proceso.
El 28 de agosto de 2023 a las 6:43 p.m., PST, los ingenieros de Edgio observaron un aumento en la utilización de la memoria en nuestros servidores perimetrales, las tasas de solicitud a varias propiedades web grandes, y el volumen de registros que se generan en el borde.
El tráfico, pronto identificado como un ataque, fue novedoso porque solo era observable en los registros de nuestro balanceador de carga de capa 7. Edgio ejecuta nuestro motor de almacenamiento en caché y proxying HTTP personalizado, Sailfish, tanto como nuestro balanceador de carga de capa 7 (que llamamos “frontend”), como nuestra capa de almacenamiento en caché y proxying (el “backend”). Esto permite la instrumentación común y el registro en ambas capas, haciendo que las comparaciones entre ellas sean triviales.
Cuando cavamos en los registros del frontend, observamos algunos comportamientos interesantes que indican un ataque:
- El recuento de solicitudes para clientes individuales fue mucho más alto de lo habitual: Durante el ataque vimos casos de más de 20.000 solicitudes en un solo socket.
- No se enviaban bytes a los clientes.
- El tiempo total de solicitud, de principio a fin, fue de entre 1 y 2 milisegundos, todo invertido iniciando una nueva conexión proxy a los backends.
- Todas las conexiones que exhibieron el comportamiento fueron conexiones HTTP/2.
Basándonos en estas observaciones iniciales, teorizamos que el atacante estaba abandonando las solicitudes utilizando el marco RST_STREAM de HTTP/2 e iniciando nuevas solicitudes en el mismo socket, muy rápidamente.
Después de esto, dividimos nuestros esfuerzos en tres flujos de trabajo distintos:
- Investigar cualquier problema potencial que afecte a la biblioteca HTTP/2 que usamos, nghttp2, que pueda probar la causa raíz.
- Construir variables Sailfish para exponer los fundamentos de este comportamiento para habilitar las mitigaciones.
- Creación de nuevas métricas, paneles y alertas para identificar este tipo de ataque más rápidamente.
1. Enviado… pero realmente nghttp2
Después de una pequeña búsqueda, encontramos en este número Envoy, un proxy de servicio que Edgio no utiliza en el borde, y el CVE correspondiente. Tras una revisión más profunda del diff, nos dimos cuenta de que este tema no estaba solo en Envoy, sino en realidad en nghttp2, que sí usamos.
Poco después de la divulgación se publicó una solicitud de pull y una publicación de etiquetas de punto para nghttp2, lo que solucionó el problema subyacente. La falta de un CVE específico asignado contra nghttp2 había significado que nuestro sistema de escaneo CVE automatizado, que utilizamos para rastrear vulnerabilidades en el software clave que utilizamos, perdió el problema originalmente.
Inmediatamente comenzamos el proceso para actualizar esta dependencia e implementarla, que se completó hace unas semanas.
2. Solicitud de reinicio por ciento
En paralelo, trabajamos para identificar el comportamiento de ataque programáticamente, dentro de Sailfish, con el fin de poder tomar medidas de inmediato para evitar problemas de rendimiento o fiabilidad. Decidimos implementar una variable de configuración (h2_remote_reset_percent) dentro de Sailfish, que rastrearía el porcentaje de solicitudes en una conexión dada que ha sido restablecida por el cliente.
La adición, junto con una variable existente para el recuento de solicitudes en una sola conexión, nos permitió crear una regla que cerraría inmediatamente una conexión a un cliente que había superado un umbral de solicitud y había reiniciado más de un porcentaje configurado de solicitudes. Envolvimos esta configuración en sistemas de seguridad operativos normales, que nos permiten desactivarla para ubicaciones o clientes específicos.
En pseudocode esto se ve como:
if request_count > 1000 and
h2_remote_reset_percent > 99 and
pop ~ ".*" and
customer_id not in () then
connection.silent_close();
fi
Después de una cuidadosa validación para evitar cualquier impacto no deseado en el tráfico de nuestros clientes, se implementó la nueva regla y los ingenieros de Edgio continuaron monitoreando cualquier anomalía adicional.
3. Recuentos y ratios
Con el fin de identificar más rápidamente cuando se están produciendo ataques de este tipo, configuramos un nuevo panel de control y alerta basado en el recuento de tramas HTTP/2 RST_STREAM recibidas de los clientes, a través de una ubicación. Esto, junto con una visión singular de la disponibilidad de memoria y los controles de estado, nos dio una señal clara de la degradación potencial debido a este tipo específico de ataque:
Sin embargo, seguimos preocupados por otros tipos de ataque potenciales que podrían afectar solo los frontends específicamente. Para dar visibilidad a esta preocupación más general, comenzamos a rastrear la proporción de la tasa de transacción entre frontends y backends en una ubicación determinada. Los datos subyacentes para esta comparación han sido una parte central de nuestro monitoreo durante mucho tiempo.
Observando el comportamiento normal, puede ver la banda fuerte alrededor de 1, la proporción esperada, ya que cada solicitud que llega a un front end se traduce en una sola solicitud de backend. También es visible la banda más cercana a 0,5 y 0,25, que ocurren principalmente en lugares de prueba inactivos, donde sistemas como purga y verificación de estado causan que más transacciones internas sean procesadas por backends:
Sin embargo, durante el ataque inicial, puedes ver claramente el efecto en esta proporción:
Nuestra alerta actual está configurada para activarse cuando la proporción excede un valor determinado, creando un incidente para que los ingenieros de Edgio Support clasifiquen e inicien los pasos de mitigación.
Resumen
Este fue un nuevo tipo de ataque interesante, aprovechando una vulnerabilidad recientemente revelada en una biblioteca ampliamente utilizada. Afortunadamente, el equipo de Edgio trabajó rápidamente para mejorar nuestra conciencia operativa, mitigar la causa raíz específica del ataque, así como poner en mitigaciones genéricas y ajustables de propósito general para esta clase de ataque.
Por supuesto, siempre estamos trabajando en mejoras como esta, como nuevas formas de identificar a los malos actores a través de huellas dactilares, así como la integración de este trabajo en nuestro paquete de productos de seguridad para permitir un bloqueo más persistente y la limitación de la velocidad.
Nunca un momento aburrido en Edgio.
Para obtener más información sobre nuestra protección DDoS de espectro completo, parte de la galardonada solución de protección de aplicaciones web y API (WAAP) de Edgio, póngase en contacto con nuestros expertos aquí.
