Publicado originalmente el 29 de septiembre de 2023 | Actualizado el 10 de octubre de 2023
Por: Dave Andrews, Marcus Hildum, Sergio Ruiz
Actualización: Ataque de restablecimiento rápido HTTP/2 – CVE-2023-44487
Después del 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 dio 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 mediante la ejecución de la terminación HTTP/2 y el proxy HTTP/1,1 de vuelta a la infraestructura de los clientes. Por favor, póngase en contacto 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 memoria en nuestros servidores de borde, 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, era novedoso porque solo era observable en los registros de nuestro balanceador de carga de capa 7. Edgio ejecuta nuestro motor personalizado de almacenamiento en caché HTTP y proxy, Sailfish, como nuestro balanceador de carga de capa 7 (que llamamos un “frontend”), y nuestra capa de almacenamiento en caché y proxy (el “backend”). Esto permite la instrumentación y el registro comunes en ambas capas, haciendo que las comparaciones entre ellas sean triviales.
Cuando cavamos en los registros 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 instancias 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 gastado iniciando una nueva conexión proxy a los backends.
- Todas las conexiones que mostraban el comportamiento eran conexiones HTTP/2.
Basándonos en estas observaciones iniciales, teorizamos que el atacante estaba abandonando las solicitudes usando 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.
- Construyendo variables de Sailfish para exponer los fundamentos de este comportamiento para permitir 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 un examen más profundo de la diferencia, nos dimos cuenta de que esta cuestión no era sólo en Envoy, sino en realidad en nghttp2, que sí usamos.
Una solicitud de pull y una liberación de etiquetas de punto para nghttp2 fueron lanzados poco después de la divulgación, abordando el problema subyacente. La falta de un CVE específico asignado contra nghttp2 había significado que nuestro sistema de escaneo CVE automatizado, que usamos para rastrear vulnerabilidades en software clave que utilizamos, se perdiera el problema originalmente.
Inmediatamente comenzamos el proceso para actualizar esta dependencia y desplegarla, que se completó hace varias semanas.
2. Solicitar reset por ciento
Paralelamente, se trabajó para identificar el comportamiento de ataque de forma programática, dentro de la propia 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 excedido un umbral de solicitud y había reiniciado más de un porcentaje configurado de solicitudes. Envolvimos esta configuración en cajas fuertes normales operativas, que nos permiten desactivarla para ubicaciones o clientes específicos.
En pseudocode esto parece:
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 producen 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, en una ubicación. Esto, junto con una visión singular de la disponibilidad de memoria y los controles de salud, nos dio una clara señal de degradación potencial debido a este tipo específico de ataque:
Sin embargo, seguimos preocupados por otros posibles tipos de ataque que podrían afectar solo las frontend específicamente. Para dar visibilidad a esta preocupación más general, comenzamos a rastrear la relación de la tasa de transacción entre frontend y backends en una ubicación dada. Los datos subyacentes para esta comparación han sido una parte central de nuestro monitoreo durante mucho tiempo.
Si observas el comportamiento normal, puedes ver la banda fuerte alrededor de 1, la relació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 hacen 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 relación excede un determinado valor, creando un incidente para que los ingenieros de soporte de Edgio puedan evaluar e iniciar los pasos de mitigación.
Resumen
Este fue un nuevo tipo de ataque interesante, aprovechando una vulnerabilidad relativamente reciente 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 sintonizables 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 las 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í.
