Un equipo de investigadores de la Universidad de Pekín, la Universidad de Tsinghua y la Universidad de Texas en Dallas.
El encabezado Rango le brinda al cliente la capacidad de especificar un rango de posiciones en el archivo que deben descargarse en lugar de devolver el archivo completo. Por ejemplo, el cliente puede especificar "Rango: bytes=0-1023" y el servidor transmitirá sólo los primeros 1024 bytes de datos. Esta característica es muy solicitada al descargar archivos grandes: el usuario puede pausar la descarga y luego continuar desde la posición interrumpida. Al especificar “bytes=0-0”, el estándar indica que se proporcione el primer byte del archivo, “bytes=-1” - el último, “bytes=1-” - comenzando desde 1 byte hasta el final del archivo. Es posible transmitir varios rangos en un encabezado, por ejemplo "Rango: bytes=0-1023,8192-10240".
Además, se ha propuesto una segunda opción de ataque, destinada a aumentar la carga de la red al reenviar tráfico a través de otra CDN, que se utiliza como proxy (por ejemplo, cuando Cloudflare actúa como frontend (FCDN) y Akamai actúa como backend ( BCDN). El método es similar al primer ataque, pero está localizado dentro de las redes CDN y permite un mayor tráfico cuando se accede a través de otras CDN, lo que aumenta la carga en la infraestructura y reduce la calidad del servicio.
La idea es que el atacante envíe solicitudes de rango de varios rangos a la CDN, como "bytes=0-,0-,0-...", "bytes=1-,0-,0-..." o "bytes = -1024,0, 0-, 0-...". Las solicitudes contienen una gran cantidad de rangos "0-", lo que implica que el archivo se devuelve desde la posición cero hasta el final. Debido a una implementación incorrecta del análisis de rangos, cuando la primera CDN accede a la segunda, se envía un archivo completo para cada rango “53-” (los rangos no se agregan, sino que se iteran secuencialmente), si hay duplicación e intersección de rangos en la solicitud enviada inicialmente por el atacante. El grado de amplificación del tráfico en un ataque de este tipo oscila entre 7432 y XNUMX veces.
Durante el estudio, se estudió el comportamiento de 13 CDN:
Akamai, Alibaba Cloud, Azure, CDN77, CDNsun, Cloudflare, CloudFront, Fastly, G-Core Labs, Huawei Cloud, KeyCDN, StackPath y Tencent Cloud. Todas las CDN examinadas permitieron el primer tipo de ataque al servidor final. La segunda variante del ataque CDN afectó a 6 servicios, de los cuales cuatro podrían actuar como frontend en el ataque (CDN77, CDNsun, Cloudflare y StackPath) y tres como backend (Akamai, Azure y StackPath). La mayor ganancia se logra en Akamai y StackPath, que permiten especificar más de 10 mil rangos en el encabezado Rango. Los propietarios de CDN fueron notificados de las vulnerabilidades hace aproximadamente 7 meses, y cuando la información se hizo pública, 12 de 13 CDN habían solucionado los problemas identificados o habían expresado su disposición a solucionarlos (solo el servicio StackPath no respondió).
Fuente: opennet.ru