Investigadores de ciberseguridad han dado a conocer dos ataques de denegación de servicio que aprovechan un detalle operativo en muchas redes de distribución de contenido (CDN): la forma en que convierten el tráfico HTTP/3 que llega al borde (edge) en peticiones HTTP/1.1 que se envían hacia el servidor de origen. El resultado, según el estudio, es una amplificación del impacto de un flujo de solicitudes de baja capacidad, con factores reportados de hasta 350 veces en ciertos proveedores.
En conjunto, los ataques se agruparon bajo el nombre de ataques CDN Tsunami. La evaluación incluyó proveedores ampliamente usados como Alibaba, Baidu, Cloudflare, Amazon CloudFront, Fastly y Tencent.
Qué son los ataques CDN Tsunami
La idea central detrás de los ataques CDN Tsunami es un “desajuste” entre lo que el navegador negocia con el CDN y lo que el CDN necesita para hablar con el sitio que protege. En esencia, el CDN puede hablar HTTP/3 al cliente, pero hacia el servidor de origen termina usando HTTP/1.1. Ese salto entre versiones crea una ventana en la que ciertas transformaciones técnicas pueden amplificar recursos consumidos en el origen.
Los investigadores explican que el problema se apoya en una brecha de despliegue: CDNs no ofrecen HTTP/3 de punta a punta hacia el servidor final. Al operar así, algunas mecánicas de HTTP/3—especialmente la compresión y el manejo de cabeceras—no tienen un equivalente directo en HTTP/1.1. Para poder reenviar la solicitud, el CDN debe “reconstruir” información, lo que incrementa el tamaño real o la cantidad de conexiones abiertas del lado del origen.
Dos técnicas: amplificación de ancho de banda y de conexiones
El estudio distingue dos variantes principales de ataque, con objetivos distintos. Ambas se basan en el mismo hueco: la terminación HTTP/3 en el borde y la posterior comunicación HTTP/1.1 con el origen.
1) HTTP/3 Bandwidth Amplification (HBA)
La amplificación de ancho de banda (HBA) se apoya en QPACK, el mecanismo de compresión de cabeceras introducido con HTTP/3. Los investigadores sostienen que HTTP/1.1 no incluye una función equivalente. Por eso, cuando el CDN recibe valores “indexados” o compactos de QPACK, debe expandirlos para construir cabeceras completas antes de enviarlas al servidor de origen.
El impacto es asimétrico: lo que cuesta muy pocos bytes al atacante en el enlace (gracias a QPACK) puede traducirse en una solicitud mucho más grande del lado del origen tras la descompresión.
2) HTTP/3 Connection Amplification (HCA)
La amplificación de conexiones (HCA) apunta a la capacidad de manejo de conexiones, no al volumen de datos. En pruebas, muchos CDNs abren una conexión HTTP/1.1 hacia el origen tan pronto reciben el frame HEADERS de HTTP/3, incluso antes de que llegue el cuerpo (DATA).
Como HTTP/3 permite multiplexar múltiples streams sobre una misma conexión del cliente, un atacante puede disparar muchas solicitudes simultáneas que, a su vez, provocan múltiples conexiones TCP desde el CDN al origen. Mantener un ritmo muy bajo en los DATA frames prolonga esas conexiones “incompletas” y consume recursos del servidor objetivo.
Qué proveedores resultaron susceptibles
Los ataques CDN Tsunami fueron evaluados contra seis CDNs. En general, los resultados se separaron por tipo de variante:
- Todos los proveedores analizados mostraron susceptibilidad a la variante de ancho de banda (HBA) en su configuración probada.
- Cinco de seis fueron vulnerables a la variante de conexiones (HCA).
Un punto notable es el comportamiento de Cloudflare en la variante de conexiones: los investigadores indican que no se observó susceptibilidad en HCA porque el CDN amortigua (bufferiza) la solicitud completa antes de abrir la conexión con el origen, evitando así que un HEADERS temprano detone múltiples conexiones.
Factores de amplificación observados
El factor de amplificación reportado depende del proveedor y del tipo de técnica. El estudio menciona que el multiplicador “hasta 350x” aplica solo a tres proveedores: Alibaba, Baidu y Tencent.
Para HBA basado en tabla dinámica QPACK, los investigadores reportan aproximadamente estos factores:
- Baidu: 66.06x (tabla dinámica soportada)
- Alibaba: 65.8x (tabla dinámica soportada)
- Tencent: 54.08x (tabla dinámica soportada)
- Amazon CloudFront: 51.2x (sin tabla dinámica)
- Cloudflare: 48.27x (sin tabla dinámica)
- Fastly: 36.41x (sin tabla dinámica)
Además, se observó que la amplificación relacionada con la tabla dinámica requería un paso previo: el atacante envía una solicitud HTTP/3 con cabeceras grandes para poblar la tabla dinámica, y luego referencia repetidamente entradas con valores pequeños. En el análisis se cita un límite de tamaño para la tabla dinámica anunciada por cada proveedor (por ejemplo, 4 KB y con entrada máxima alrededor de 3,072 bytes en los casos mencionados).
Cómo se midió y qué significan los resultados
Para acotar el estudio, los investigadores impusieron límites. Por ejemplo, el origen estuvo capado en un máximo de 100 Mbps y la capacidad del atacante en 30 Mbps. El trabajo no reporta pruebas que excedieran esos topes, por lo que se advierte que no se validó el comportamiento con servidores y capacidades mayores.
En cuanto al patrón temporal, los investigadores reportan que el multiplicador se aproximaba a un pico cerca de 64 streams concurrentes y luego disminuía. Atribuyen esa caída a sobrecarga de CPU del lado del borde, aunque no incluyen mediciones de CPU del edge como parte del conjunto de datos.
Riesgo: exposición potencial en subdominios
Para estimar cuántos objetivos podrían estar expuestos, el equipo enumeró subdominios a partir de una lista Top 1M de Tranco, revisó registros CNAME y NS, los comparó con sufijos asociados a los CDNs y probó cada uno mediante un cliente compatible con HTTP/3.
El proceso produjo 151,685 subdominios alojados por los seis proveedores. De ellos, 42,330 respondieron a una solicitud HTTP/3 y se etiquetaron como potencialmente vulnerables.
Eso no significa que el origen de cada uno estuviera siendo explotado: según el estudio, el sondeo confirma básicamente que el borde responde a HTTP/3, y que el origen fuera del entorno de pruebas del equipo no fue atacado en esa fase.
Mitigaciones propuestas y aplicadas
Los investigadores señalan que las medidas de mitigación que entregaron a los proveedores se aplican en el CDN (no en el sitio de origen). En términos de acciones técnicas, el documento menciona:
- Limitar el tamaño de entradas insertadas en la tabla dinámica QPACK (sugerido: ~512 bytes).
- Reducir cuántas veces puede referenciarse una entrada dinámica dentro de un mismo stream (sugerido: no más de 10).
- Imponer un tope al tamaño total descomprimido de la petición HTTP/1.1 y rechazar solicitudes que excedan el umbral (sugerido: 64 KB).
- Bufferizar la solicitud HTTP/3 completa—tanto HEADERS como DATA—antes de abrir la conexión CDN-origen.
- Limitar la cantidad de conexiones que un cliente HTTP/3 puede forzar hacia el origen por cada conexión del cliente.
- Aplicar un timeout independiente de la conexión del cliente para las conexiones CDN-origen (sugerido: ~30 segundos sin envío relevante).
El informe indica que Baidu y Tencent confirmaron el reporte y desplegaron mitigaciones. También recoge que otros cuatro proveedores reconocieron el hallazgo y seguían discutiendo internamente.
Sin CVE reportado y sin explotación en el mundo real
Hasta donde reflejan los resultados divulgados, no se asignaron identificadores CVE y no se reporta explotación en la naturaleza. Los investigadores también mencionan que no está documentado si el equipo hizo una revalidación una vez aplicadas las mitigaciones en los proveedores que respondieron con cambios.
Qué pueden hacer los responsables de sitios
Aunque el estudio se centra en el comportamiento de CDNs, hay implicaciones prácticas para quienes operan sitios detrás de estas redes:
- Verificar qué versiones de HTTP están habilitadas en el borde y cómo el proveedor realiza la conversión hacia el origen.
- Revisar si el CDN ofrece opciones para limitar tamaños de cabeceras, tiempo de espera hacia el origen y número de conexiones desencadenadas.
- Coordinar con el proveedor del CDN para confirmar que las mitigaciones relacionadas con QPACK y el buffering de solicitudes se encuentran activas.
Conclusión
Los ataques CDN Tsunami muestran cómo un pequeño desajuste entre HTTP/3 en el borde y HTTP/1.1 hacia el origen puede convertirse en una amplificación severa del impacto de tráfico mínimo. En el estudio se observaron multiplicadores de decenas de veces, con casos donde el efecto llegó a aproximarse a cifras muy altas en función del proveedor y del soporte de QPACK dinámico.
La buena noticia es que las mitigaciones descritas—como limitar tamaños de cabeceras descomprimidas, bufferizar la solicitud completa y restringir conexiones hacia el origen—se enfocan en corregir el punto donde se produce la conversión. Para equipos de seguridad y operación, la recomendación es clara: confirmar la postura del CDN y asegurar que estas defensas estén aplicadas de forma efectiva.
Fuente: https://thehackernews.com/2026/08/cdn-tsunami-attack-abuses-http3.html
