Un equipo de investigadores da Universidade de Pequín, a Universidade de Tsinghua e a Universidade de Texas en Dallas unha nova clase de ataques DoS - RangeAmp, baseada no uso dunha cabeceira HTTP para organizar a amplificación do tráfico mediante redes de entrega de contidos (CDN). A esencia do método é que, debido á forma en que se procesan as cabeceiras de rango en moitas CDN, un atacante pode solicitar un byte dun ficheiro grande a través da CDN, pero a CDN descargará o ficheiro completo ou un bloque de datos moito máis grande do CDN. servidor de destino para ser colocado na caché. O grao de amplificación do tráfico durante un ataque deste tipo, dependendo da CDN, varía de 724 a 43330 veces, o que se pode usar para sobrecargar a CDN con tráfico entrante ou reducir a capacidade da canle de comunicación final ao sitio da vítima.
A cabeceira Rango dálle ao cliente a posibilidade de especificar un rango de posicións no ficheiro que debería descargarse en lugar de devolver todo o ficheiro. Por exemplo, o cliente pode especificar "Range: bytes=0-1023" e o servidor transmitirá só os primeiros 1024 bytes de datos. Esta función é demandada cando descarga ficheiros grandes: o usuario pode pausar a descarga e despois continuar desde a posición interrompida. Ao especificar "bytes=0-0", o estándar indica que o primeiro byte do ficheiro, "bytes=-1" - o último, "bytes=1-" - comezando desde 1 byte ata o final do ficheiro. É posible transmitir varios intervalos nunha cabeceira, por exemplo "Range: bytes=0-1023,8192-10240".
Ademais, propúxose unha segunda opción de ataque, destinada a aumentar a carga da rede cando se reenvía o tráfico a través doutro CDN, que se usa como proxy (por exemplo, cando Cloudflare actúa como frontend (FCDN) e Akamai actúa como backend ( BCDN). O método é semellante ao primeiro ataque, pero localízase dentro das redes CDN e permite aumentar o tráfico cando se accede a través doutras CDN, aumentando a carga da infraestrutura e reducindo a calidade do servizo.
A idea é que o atacante envíe solicitudes de rango de varios rangos ao CDN, como "bytes=0-,0-,0-...", "bytes=1-,0-,0-..." ou "bytes=-1024,0 ,0-,0-...". As solicitudes conteñen un gran número de intervalos "0-", o que implica que o ficheiro se devolve desde a posición cero ata o final. Debido a unha implementación incorrecta da análise de intervalos, cando o primeiro CDN accede ao segundo, envíase un ficheiro completo para cada intervalo "53-" (os intervalos non se agregan, senón que se iteran secuencialmente), se hai duplicación e intersección de intervalos en a solicitude enviada inicialmente polo atacante. O grao de amplificación do tráfico nun ataque deste tipo oscila entre 7432 e XNUMX veces.
Durante o estudo, estudouse o comportamento de 13 CDN -
Akamai, Alibaba Cloud, Azure, CDN77, CDNsun, Cloudflare, CloudFront, Fastly, G-Core Labs, Huawei Cloud, KeyCDN, StackPath e Tencent Cloud. Todos os CDN examinados permitiron o primeiro tipo de ataque ao servidor final. A segunda variante do ataque CDN afectou a 6 servizos, dos cales catro poderían actuar como frontend no ataque (CDN77, CDNsun, Cloudflare e StackPath) e tres como backend (Akamai, Azure e StackPath). A maior ganancia conséguese en Akamai e StackPath, que permiten especificar máis de 10 mil intervalos na cabeceira Rango. Os propietarios de CDN foron notificados sobre as vulnerabilidades hai uns 7 meses e, cando a información foi divulgada publicamente, 12 de cada 13 CDN solucionaran os problemas identificados ou expresaron a súa disposición para solucionalos (só o servizo StackPath non respondeu).
Fonte: opennet.ru