Nuevo ataque DDoS HTTP/2 'Rapid Reset'

 (cloud.google.com)
1 puntos por GN⁺ 2023-10-11 | 1 comentarios | Compartir por WhatsApp
  • Un DDoS de capa 7 basado en HTTP/2 dirigido a servicios de Google y clientes de Google Cloud alcanzó su punto máximo en agosto de 2023, superando los 398 millones de solicitudes por segundo
  • El ataque fue bloqueado en su mayor parte por la infraestructura global de balanceo de carga de Google, por lo que no derivó en una interrupción, y después se añadieron medidas de protección para mitigar ataques similares
  • Rapid Reset cancela solo el flujo con un frame RST_STREAM justo después de la solicitud y mantiene la conexión, repitiendo la generación de solicitudes mientras evita el límite de flujos simultáneos
  • El servidor puede seguir realizando tareas como descompresión de encabezados, mapeo de URL y proxy al backend incluso para solicitudes canceladas, lo que amplía la asimetría de costos
  • Los operadores de HTTP/2 deben revisar su exposición y aplicar parches, y ante la detección de abuso, la medida clave de mitigación es cerrar la conexión TCP completa en lugar de cada solicitud individual

Escala del ataque y respuesta de Google

  • Los servicios de Google y los clientes de Cloud fueron objetivo de un ataque DDoS de capa 7 basado en HTTP/2 que alcanzó su pico en agosto de 2023
  • El ataque máximo superó los 398 millones de solicitudes por segundo, una escala muy superior a la de ataques de capa 7 reportados anteriormente
  • La infraestructura global de balanceo de carga de Google bloqueó la mayor parte del ataque en el borde de la red
    • No se produjo ninguna interrupción
    • El impacto se mantuvo en un nivel limitado
  • El equipo Google DDoS Response Team revisó el ataque y aplicó medidas de protección adicionales para reducir ataques similares
  • Google lideró, junto con socios de la industria, un proceso de divulgación coordinada para abordar este nuevo vector de ataque en HTTP/2

Por qué HTTP/2 puede favorecer los DDoS

  • Desde finales de 2021, muchos de los ataques DDoS de capa 7 observados en servicios propios de Google y en proyectos de Google Cloud protegidos por Cloud Armor estuvieron basados en HTTP/2
    • También fueron numerosos por cantidad de ataques
    • También mostraron tasas máximas de solicitudes más altas
  • La eficiencia de HTTP/2 puede aumentar no solo la eficiencia de clientes legítimos, sino también la de ataques DDoS

  • Multiplexación de flujos

    • HTTP/2 transmite frames entre endpoints mediante flujos (stream), una abstracción bidireccional
    • Gracias a la multiplexación de flujos, una sola conexión TCP puede procesar varias solicitudes al mismo tiempo
    • La principal limitación de un ataque DoS de capa 7 es la cantidad de conexiones concurrentes en transmisión
      • Cada conexión usa memoria del sistema operativo para registros de socket y buffers
      • El handshake TLS requiere tiempo de CPU
      • Se necesita una 4-tupla única compuesta por ambas direcciones IP y el par de puertos
    • HTTP/1.1 normalmente procesa solicitudes en serie, por lo que la tasa de solicitudes de una sola conexión se acerca a una solicitud por tiempo de ida y vuelta
    • En HTTP/2 pueden abrirse múltiples flujos concurrentes sobre una sola conexión TCP, y cada flujo corresponde a una solicitud HTTP
    • En entornos reales, un cliente puede abrir 100 flujos por solicitud y el servidor puede procesarlos en paralelo, elevando el rendimiento efectivo de una sola conexión hasta unas 100 solicitudes por tiempo de ida y vuelta
    • Como resultado, la utilización de la conexión puede ser casi 100 veces mayor que con HTTP/1.1

Cómo funciona Rapid Reset

  • HTTP/2 permite que el cliente envíe un frame RST_STREAM para informar al servidor de la cancelación de un flujo previo
  • La cancelación no requiere coordinación separada entre cliente y servidor
    • El cliente puede cancelarla unilateralmente
    • Puede asumirse que un servidor que recibe el frame RST_STREAM aplicará la cancelación antes que otros datos de la misma conexión TCP
  • Rapid Reset se basa en enviar un frame RST_STREAM inmediatamente después de enviar los frames de la solicitud
    • Hace que el endpoint remoto empiece a trabajar y luego reinicia rápidamente la solicitud
    • La solicitud se cancela, pero la conexión HTTP/2 permanece abierta
  • El procedimiento del ataque es simple
    • Abre muchos flujos a la vez, como en un ataque HTTP/2 estándar
    • No espera la respuesta del servidor o proxy
    • Cancela de inmediato cada solicitud
  • Si el reset inmediato es posible, cada conexión puede mantener en la práctica una gran cantidad de solicitudes en curso por tiempo indefinido
    • El atacante no supera explícitamente el límite de flujos abiertos simultáneos
    • La cantidad de solicitudes en curso depende más del ancho de banda de red disponible que del tiempo de ida y vuelta (RTT)
  • Una implementación típica de servidor HTTP/2 puede tener que seguir trabajando incluso sobre solicitudes canceladas
    • Asignación de nuevas estructuras de datos para flujos
    • Parseo de consultas
    • Descompresión de encabezados
    • Mapeo de URL a recursos
  • En implementaciones de proxy inverso, la solicitud puede ser enviada al servidor backend antes de que se procese el frame RST_STREAM
  • Como el cliente casi no paga costo por transmitir la solicitud, se genera una asimetría de costos explotable entre servidor y cliente
  • Si la solicitud se cancela antes de redactar la respuesta, el servidor de proxy inverso no envía la respuesta, lo que también reduce el ancho de banda de bajada desde el servidor o proxy hacia el atacante

Variantes de ataque observadas

  • Durante las semanas posteriores al DDoS inicial se observaron variantes de Rapid Reset
  • Aunque estas variantes no son tan eficientes como el método inicial, pueden seguir siendo más eficientes que un ataque DDoS HTTP/2 estándar

  • Variante de cancelación por lotes

    • La primera variante no cancela los flujos de inmediato, sino que abre grupos de flujos, espera un momento y luego los cancela todos juntos
    • Justo después de la cancelación vuelve a abrir un nuevo grupo grande de flujos para continuar el ataque
    • Este método puede eludir mitigaciones que se basan solo en la tasa de frames RST_STREAM entrantes
      • Ejemplo: una política que permita como máximo 100 RST_STREAM por segundo por conexión y cierre la conexión si se supera ese valor
    • Como no maximiza la utilización de la conexión, se reduce la principal ventaja de los ataques por cancelación
    • Aun así, puede ser más eficiente de implementar que un ataque DDoS HTTP/2 estándar, por lo que limitar solo la tasa de cancelación de flujos requeriría límites bastante estrictos

  • Variante sin cancelación

    • La segunda variante no cancela flujos en absoluto
    • En su lugar, intenta abrir de forma optimista más flujos que la cantidad de flujos simultáneos anunciada por el servidor
    • Puede seguir llenando por completo el pipeline de solicitudes y reducir el cuello de botella del RTT entre cliente y proxy
    • Si apunta a recursos a los que el servidor HTTP/2 responde de inmediato, también puede eliminar el cuello de botella del RTT entre proxy y servidor
    • El RFC actual de HTTP/2, RFC 9113, sugiere que ante el intento de abrir demasiados flujos se deben invalidar solo los flujos que exceden el límite y no toda la conexión
    • En estructuras donde la mayoría de los servidores HTTP/2 no procesan flujos excedentes, es posible aceptar y procesar nuevos flujos casi de inmediato después de responder a flujos previos, lo que habilita esta variante sin cancelación

Estrategias de mitigación

  • Para esta familia de ataques, bloquear solicitudes individuales difícilmente constituye una mitigación viable
  • Cuando se detecta abuso, debe cerrarse la conexión TCP completa
  • HTTP/2 admite el cierre de conexiones con el tipo de frame GOAWAY
  • El RFC define un procedimiento de cierre gradual: primero se envía un GOAWAY informativo que no fija un límite de apertura de nuevos flujos y, tras un tiempo de ida y vuelta, se envía un GOAWAY que prohíbe abrir flujos adicionales
  • Pero este procedimiento gradual con GOAWAY a menudo no es lo suficientemente robusto frente a clientes maliciosos
    • Deja la conexión expuesta demasiado tiempo al ataque Rapid Reset
    • No logra detener las solicitudes entrantes
  • Para fines de mitigación, GOAWAY debe configurarse para restringir de inmediato la creación de flujos

  • Identificación de conexiones abusivas

    • El hecho de que un cliente cancele solicitudes no siempre implica abuso
    • La función de cancelación de HTTP/2 existe para gestionar mejor el procesamiento de solicitudes
      • Cuando el usuario abandona la página y el navegador ya no necesita el recurso solicitado
      • En aplicaciones que usan long polling con timeout del lado del cliente
    • La mitigación se enfoca en rastrear estadísticas de conexión y usar múltiples señales y lógica de negocio para evaluar la utilidad de cada conexión
    • Por ejemplo, si una conexión tiene más de 100 solicitudes y más del 50% fueron canceladas, puede convertirse en candidata a mitigación
    • La magnitud y el tipo de respuesta dependen del riesgo de cada plataforma
      • Frame GOAWAY forzado
      • Terminación inmediata de la conexión TCP
    • Para mitigar la variante sin cancelación, se recomienda que los servidores HTTP/2 cierren las conexiones que excedan el límite de flujos simultáneos
      • Puede cerrarse de inmediato
      • O tras unas pocas infracciones repetidas

Aplicabilidad a HTTP/3

  • Google no considera que este método de ataque se aplique directamente a HTTP/3 (QUIC) debido a diferencias de protocolo
  • Por ahora, Google no observa que HTTP/3 se esté usando como vector de DDoS a gran escala
  • Aun así, se recomienda que las implementaciones de servidor HTTP/3 adopten de forma preventiva mecanismos para limitar la cantidad de trabajo que realiza una sola conexión de transporte
    • En una dirección similar a las mitigaciones discutidas para HTTP/2

Coordinación de la industria y CVE

  • Desde las primeras etapas de la investigación del Google DDoS Response Team quedó claro que este tipo de ataque podía tener un impacto amplio sobre todos los servicios que ofrecen HTTP/2
  • Google lideró un proceso de divulgación coordinada de vulnerabilidades aprovechando un grupo existente para este tipo de coordinación
  • El proceso de divulgación se centró en notificar a implementadores de HTTP/2 a gran escala
    • Empresas de infraestructura
    • Proveedores de software de servidor
  • El objetivo del aviso previo era desarrollar mitigaciones y prepararse conforme al calendario de divulgación coordinada
  • En ocasiones anteriores, este enfoque ya había derivado en una aplicación amplia de protecciones por parte de proveedores de servicios o en la publicación de actualizaciones de software para varios paquetes y soluciones
  • Durante el proceso de divulgación coordinada, se reservó CVE-2023-44487 para hacer seguimiento a las correcciones en varias implementaciones de HTTP/2

Qué deben hacer los operadores de servicios HTTP/2

  • Este ataque puede tener un impacto considerable en servicios de cualquier escala
  • Todos los proveedores que ofrecen servicios HTTP/2 deben evaluar su nivel de exposición a este problema
  • Los parches y actualizaciones de software para servidores web y lenguajes de programación de uso común pueden estar disponibles ahora o en un futuro cercano
  • Se recomienda aplicar las correcciones disponibles lo antes posible
  • Para clientes de Google Cloud, además de los parches de software, se recomienda usar Application Load Balancer y Google Cloud Armor
    • Google Cloud Armor ha protegido a Google y a usuarios existentes de Google Cloud Application Load Balancing

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-10-11
Opiniones en Hacker News

  • Hilos relacionados en curso:
    El mayor ataque DDoS hasta la fecha, con un pico de más de 398 millones de solicitudes por segundo - https://news.ycombinator.com/item?id=37831062
    Una vulnerabilidad zero-day en HTTP/2 provocó un ataque DDoS récord - https://news.ycombinator.com/item?id=37830998

  • Da gusto ver que el equipo de HAProxy parece haber detectado y mitigado este tipo de problema en HTTP/2 ya en 2018: https://www.mail-archive.com/haproxy@formilux.org/msg44134.h...

  • En una implementación típica de servidor HTTP/2, incluso para solicitudes canceladas hay que hacer bastante trabajo, como asignar una nueva estructura de datos de stream, parsear la consulta, descomprimir encabezados y mapear el recurso de la URL
    En una implementación de proxy inverso, la solicitud incluso podría ser enviada al servidor backend antes de que se procese el frame RST_STREAM. En cambio, al cliente casi no le cuesta enviar la solicitud, así que se genera una asimetría de costos explotable entre el servidor y el cliente
    Sorprende que esto no se haya previsto al diseñar HTTP/2. Los ataques de amplificación ya eran bien conocidos en otros protocolos. También sorprende de forma similar que este ataque haya salido a la luz tan tarde, aunque quizá hasta hace poco HTTP/2 no estaba desplegado lo suficiente como para ser un objetivo valioso

    • Estrictamente hablando, esto no es un ataque de amplificación. Es más bien una forma mucho más eficiente de usar una conexión TCP
    • A mí también me sorprendió, pero viendo la línea de tiempo, RST_STREAM ya existía en las primeras versiones de SPDY, y SPDY parece haber sido diseñado en general alrededor de 2009
      Ataques como Slowloris aparecieron casi en la misma época, pero entonces no eran muy conocidos. En cambio, SYN cookies se introdujo en 1996, así que claramente hay precedentes históricos de ataques en los que la víctima paga Y y el atacante paga X
    • Como ocurre con la mayoría de estas cosas, es muy probable que muchísima gente sin importancia ya lo hubiera reportado y probado
      Lo inusual es que alguien lo intentara en serio contra Google

  • Al final necesitábamos HTTP/2 para entregar más rápido anuncios, rastreadores y frameworks de frontend inflados. Ahora también entrega ataques más rápido

    • HTTP/2 hace que la experiencia de navegación en conexiones de alta latencia sea mucho más tolerable. En general, también hace que las páginas web carguen más rápido
      Por suerte, HTTP/1.1 sigue funcionando. Si no te gusta ese protocolo, siempre puedes activar HTTP/1.1 en la configuración del navegador y en el servidor web
    • ¿Quieres decir que HTTP/2 no era necesario? Si es así, ¿cuál sería una alternativa realista?

  • Otra razón más para mantener pequeño el protocolo base. HTTP/2, si incluimos SPDY, existe desde hace más de 10 años, y este tipo de ataque recién aparece ahora
    Me pregunto qué sorpresas estarán escondidas en HTTP/3 y QUIC

    • DNS es un protocolo pequeño y aun así los atacantes DDoS de todo el mundo lo usan para ataques de rebote
    • QUIC no tuvo en cuenta correctamente los ataques de amplificación en su diseño, y quienes señalaron esto al principio fueron ignorados
    • HTTP/2 es bastante pequeño

  • Habría que agregar “cancelación” a la lista de “problemas difíciles de las ciencias de la computación”
    No es que sea realmente tremendamente difícil, como otros elementos de esa lista, por ejemplo errores por diferencia de 1 o invalidación de caché, pero se subestima y se pasa por alto con facilidad. Si se dedicara aunque sea la mitad del tiempo que se dedica a creación, constructores e inicialización al diseño de destrucción, limpieza, desmontaje y cancelación, creo que habría muchos menos bugs de agotamiento de recursos

    • Lo asíncrono de Rust es realmente bueno porque permite cancelar un Future de inmediato en cualquier punto de await sin cooperación de las llamadas individuales, cancelando junto con él toda la pila de llamadas
    • En bibliotecas C, esto definitivamente es cierto. La cancelación de hilos POSIX es el tipo de función cuyas implicaciones se filtran por todas partes solo por existir

  • Quiero recordarles a todos que Google es la empresa que creó HTTP/2
    Ahora lo cuentan como si nos estuvieran salvando heroicamente de un problema que ellos mismos crearon, pero no mencionan la parte de que lo crearon. Qué descaro el de estas empresas tecnológicas. Microsoft lleva décadas haciendo lo mismo

    • Intentaban resolver un problema que no existía

  • ¿Alguien puede explicar qué tiene de nuevo este ataque frente a una inundación de solicitudes común y corriente?

    • Depende de qué entiendas por ataque de “inundación de solicitudes”
      En HTTP/1.1 se podía enviar una solicitud por tiempo de ida y vuelta[0]. Con multiplexación de HTTP/2 se pueden enviar 100 por tiempo de ida y vuelta. En este ataque se puede enviar, en la práctica, una cantidad infinita de solicitudes por tiempo de ida y vuelta. Espero que los diagramas del artículo muestren la diferencia, aunque quizá te refieras a otro tipo de ataque distinto a lo anterior
      [0] Si consideramos el pipelining de HTTP/1.1, se puede reducir un factor de tiempo de ida y vuelta, pero los clientes reales casi nunca usan pipelining de HTTP/1.1, así que su uso en sí mismo se convierte en una señal muy clara de tráfico malicioso
    • La nueva técnica descrita evita el límite máximo de solicitudes por segundo por cliente que el atacante puede hacer que el servidor procese
      Si se envían solicitudes y restablecimientos de stream juntos dentro de una misma conexión, se pueden mandar más solicitudes por conexión/cliente que antes, lo que puede hacer que el ataque sea más barato o más difícil de bloquear

  • El encabezado del blog sigue apareciendo y hace que la página no se pueda leer