HTTP/3 prometía acelerar todo, pero en su lugar abrió una nueva vía de ataque

La tecnología que debería acelerar la carga de los sitios web puede amplificar repetidamente el tráfico malicioso dirigido contra ellos. Un grupo de investigadores describió dos nuevos ataques DoS a las redes de entrega de contenido (CDN), que permiten usar la infraestructura del proveedor contra el sitio protegido. En ciertas condiciones, el tráfico se amplifica aproximadamente 350 veces. El estudio recibió el nombre CDN Tsunami.

El problema surge por la diferencia de protocolos en dos tramos de la conexión. El usuario puede dirigirse a la CDN mediante el moderno HTTP/3; sin embargo, entre la CDN y el servidor de origen seis proveedores analizados usan HTTP/1.1. La CDN tiene que convertir las solicitudes de un formato a otro. Los autores demostraron que un atacante puede hacer que la CDN consuma, al realizar dicha conversión, muchos más recursos del servidor de origen.

Los autores llamaron al primer variante HTTP/3 Bandwidth Amplification (HBA). HTTP/3 comprime los encabezados con QPACK y puede transmitir, en lugar de datos repetidos, índices cortos. HTTP/1.1 no dispone de ese mecanismo, por lo que la CDN expande las entradas compactas de nuevo a encabezados completos antes de enviar la solicitud al servidor. Un flujo pequeño por parte del atacante se convierte así en un flujo mucho mayor hacia el servidor de origen.

En las pruebas el tráfico se amplificó unas 350 veces cuando los especialistas activaron la tabla dinámica de QPACK. El pico se observó aproximadamente con 64 flujos paralelos. Para tres CDN que soportan dicha tabla, la parte atacante necesitó menos de 500 Kbit/s, mientras que la carga en el servidor de prueba superó los 100 Mbit/s.

La segunda variante, HTTP/3 Connection Amplification (HCA), ataca no el ancho de banda, sino las conexiones disponibles. HTTP/3 permite transmitir múltiples flujos dentro de una sola conexión. Cinco de las seis CDN analizadas abrían inmediatamente conexiones HTTP/1.1 separadas con el servidor de origen tan pronto como recibían los encabezados. Al enviar lentamente los datos restantes, el atacante puede mantener esas conexiones abiertas y agotar su número permitido.

Los especialistas evaluaron Alibaba, Baidu, Cloudflare, Amazon CloudFront, Fastly y Tencent. Las seis resultaron vulnerables a HBA; cinco de ellas a HCA. Cloudflare evitó la segunda variante, porque primero recibe la solicitud completa y solo entonces establece la conexión con el servidor de origen. Los especialistas examinaron la lista Tranco Top 1M y encontraron 151 685 subdominios detrás de las CDN afectadas, de los cuales 42 330 cumplían las condiciones de un posible ataque.

Los autores comunicaron los resultados a los seis proveedores. Baidu y Tencent confirmaron los problemas, pagaron recompensas e implementaron las medidas de protección propuestas. Tencent, en particular, limitó el número de conexiones entre la CDN y el servidor de origen y el tamaño de los encabezados en la tabla dinámica. Para protegerse, los especialistas proponen limitar el tamaño desplegado de las solicitudes y el factor de amplificación, no abrir la conexión con el servidor hasta no recibir la solicitud completa, así como introducir límites independientes de tiempo y de cantidad para dichas conexiones.