Un equipo de investigadores de la Universidad de Pekín, la Universidad de Tsinghua y la Universidad de Texas en Dallas dieron a conocer información sobre su trabajo realizado para poder identificar una nueva clase de ataques DoS a los cuales nombraron como «RangeAmp» y los cuales se basan en el uso del encabezado Range HTTP para organizar la amplificación del tráfico a través de la red de entrega de contenido (CDN).
La esencia del método es que, debido a la peculiaridad de procesar encabezados Range en muchos CDN, un atacante puede solicitar un byte de un archivo grande a través de CDN, pero el CDN descargará el archivo completo o un bloque de datos significativamente más grande del servidor de destino para el almacenamiento en caché.
El grado de amplificación del tráfico durante un ataque de este tipo, según la CDN, es de 724 a 43330 veces, lo que se puede utilizar para sobrecargar el tráfico de CDN entrante o reducir el ancho de banda del canal de comunicación final al sitio de la víctima.
El encabezado Range permite al cliente determinar el rango de posiciones en el archivo que se debe cargar en lugar de devolver el archivo completo.
Por ejemplo, el cliente puede especificar «Rango: bytes = 0-1023» y el servidor transmitirá solo los primeros 1024 bytes de datos. Esta característica es muy solicitada cuando se descargan archivos grandes: el usuario puede pausar la descarga y luego continuarla desde la posición interrumpida. Al especificar «bytes = 0-0», el estándar prescribe dar el primer byte en el archivo, «bytes = -1» – el último, «bytes = 1-» – desde 1 byte hasta el final del archivo. Puede transferir varios rangos en un encabezado, por ejemplo, «Rango: bytes = 0-1023.8192-10240».
Además, se propuso una segunda opción de ataque (se llama ataque RangeAmp Overlapping Byte Ranges (OBR), destinada a aumentar la carga de la red cuando el tráfico se reenvía a través de otro CDN, que se utiliza como proxy (por ejemplo, cuando Cloudflare actúa como el frontend (FCDN) y Akamai actúa como el backend (BCDN)). El método se asemeja al primer ataque, pero está localizado dentro de las redes CDN y le permite aumentar el tráfico cuando 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 varios rangos a la solicitud de rango de CDN, como «bytes = 0-, 0-, 0 -…», «bytes = 1-, 0-, 0 -…» o » bytes = -1024,0-, 0 -… «.
Las solicitudes contienen una gran cantidad de rangos «0-«, lo que implica el retorno del archivo desde cero hasta el final. Debido al análisis de rango incorrecto cuando el primer CDN se refiere al segundo, se devuelve un archivo completo a cada banda «0-» (los rangos no se agregan, pero se ordenan secuencialmente) si la duplicación e intersección de rangos están presentes en la solicitud de ataque enviada originalmente. El grado de amplificación del tráfico en dicho ataque varía de 53 a 7432 veces.
El estudio examinó el comportamiento de 13 CDN: Akamai, Alibaba Cloud, Azure, CDN77, CDNsun, Cloudflare, CloudFront, Fastly, G-Core Labs, Huawei Cloud, KeyCDN, StackPath y Tencent Cloud.
«Desafortunadamente, aunque les enviamos correos electrónicos varias veces y tratamos de comunicarnos con sus servicios al cliente, StackPath no proporcionó ningún comentario», dijo el equipo de investigación.
«En general, hemos hecho todo lo posible para informar de manera responsable las vulnerabilidades y proporcionar soluciones de mitigación. Los proveedores de CDN relacionados han tenido casi siete meses para implementar técnicas de mitigación antes de que se publicara este documento».
Todos los CDN revisados permitieron el primer tipo de ataque en el servidor de destino. La segunda versión del ataque CDN resultó estar expuesta a 6 servicios, de los cuales cuatro pueden actuar como una interfaz en el ataque (CDN77, CDNsun, Cloudflare y StackPath) y tres en el papel de un back-end (Akamai, Azure y StackPath).
La mayor ganancia se logra en Akamai y StackPath, que permiten indicar más de 10 mil rangos en el encabezado Rango.
Los propietarios de CDN fueron notificados acerca de las vulnerabilidades hace aproximadamente 7 meses y para el momento de la divulgación pública de información, 12 de 13 CDN resolvieron los problemas identificados o expresaron su disposición a solucionarlos.
Fuente: https://www.liubaojun.org