RangeAmp - Uma série de ataques de CDN que manipulam o cabeçalho Range HTTP

Uma equipe de pesquisadores da Universidade de Pequim, Universidade de Tsinghua e da Universidade do Texas em Dallas divulgou informações sobre seu trabalho feito para ser capaz de identificar uma nova classe de ataques DoS que eles chamaram de "RangeAmp" e que se baseiam no uso do cabeçalho Range HTTP para organizar a amplificação do tráfego através da rede de distribuição de conteúdo (CDN).

A essência do método é que, devido à peculiaridade de processar cabeçalhos de intervalo em muitos CDNs, um atacante pode solicitar um byte de um arquivo grande via CDN, mas o CDN baixará o arquivo inteiro ou um bloco significativamente maior de dados do servidor de destino para armazenamento em cache.

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 a vítima.

O cabeçalho Range permite ao cliente determinar o intervalo de posições no arquivo que deve ser carregado em vez de retornar o arquivo inteiro.

Por exemplo, o cliente pode especificar "Intervalo: bytes = 0-1023" e o servidor transmitirá apenas os primeiros 1024 bytes de dados. Este recurso está em alta demanda ao baixar arquivos grandes: o usuário pode pausar o download e continuar a partir da posição interrompida. Ao especificar "bytes = 0-0", o padrão prescreve dar o primeiro byte no arquivo, "bytes = -1" - o último, "bytes = 1-" - de 1 byte até o final do arquivo. Você pode passar vários intervalos em um cabeçalho, por exemplo "Intervalo: bytes = 0-1023.8192-10240".

Além disso, uma segunda opção de ataque foi proposta (chamado ataque RangeAmp Overlapping Byte Ranges (OBR), projetado para aumentar a carga da rede quando o tráfego é encaminhado por meio de outro CDN, que é usado como proxy (por exemplo, quando o Cloudflare atua como front-end (FCDN) e a Akamai atua como back-end (BCDN)). O método se assemelha ao primeiro ataque, mas está localizado nos CDNs e permite aumentar o tráfego ao acessar por meio de outros CDNs, aumentando a carga da infraestrutura e reduzindo a qualidade do serviço.

A ideia é que o invasor envie vários intervalos para a solicitação de intervalo CDN, como "bytes = 0-, 0-, 0 - ...", "bytes = 1-, 0-, 0 - ..." ou "bytes = - 1024,0-, 0 -…«.

As solicitações contêm um grande número de intervalos "0-", o que implica o retorno do arquivo do zero ao final. Devido à análise de intervalo incorreta quando o primeiro CDN se refere ao segundo, um arquivo completo é retornado para cada banda "0-" (os intervalos não são agregados, mas ordenados sequencialmente) se a duplicação de intervalo e a interseção estiverem presentes na solicitação de ataque enviada originalmente. O grau de amplificação do tráfego em tal ataque varia de 53 a 7432 vezes.

O estudo examinou o comportamento de 13 CDNs: Akamai, Alibaba Cloud, Azure, CDN77, CDNsun, Cloudflare, CloudFront, Fastly, G-Core Labs, Huawei Cloud, KeyCDN, StackPath e Tencent Cloud.

"Infelizmente, embora tenhamos enviado e-mail várias vezes e tentado entrar em contato com o atendimento ao cliente, StackPath não forneceu nenhum feedback", disse a equipe de pesquisa.

“No geral, fizemos o nosso melhor para relatar vulnerabilidades com responsabilidade e fornecer soluções de mitigação. Os fornecedores de CDN relacionados tiveram quase sete meses para implementar técnicas de mitigação antes que este documento fosse publicado. "

Todos os CDNs revisados ​​permitiram o primeiro tipo de ataque no servidor alvo. A segunda versão do ataque CDN acabou sendo exposta a 6 serviços, dos quais quatro podem atuar como uma interface no ataque (CDN77, CDNsun, Cloudflare e StackPath) e três na função de um back-end (Akamai, Azure e StackPath).

O ganho mais alto é obtido em Akamai e StackPath, que permitem que você indique mais de 10 classificações no título Classificação.

Os proprietários de CDN foram notificados sobre de vulnerabilidades cerca de 7 meses atrás e no momento da divulgação pública das informações, 12 de 13 CDNs resolveram os problemas identificados ou manifestaram vontade de resolvê-los.

fonte: https://www.liubaojun.org


Deixe um comentário

Seu endereço de email não será publicado. Campos obrigatórios são marcados com *

*

*

  1. Responsável pelos dados: AB Internet Networks 2008 SL
  2. Finalidade dos dados: Controle de SPAM, gerenciamento de comentários.
  3. Legitimação: Seu consentimento
  4. Comunicação de dados: Os dados não serão comunicados a terceiros, exceto por obrigação legal.
  5. Armazenamento de dados: banco de dados hospedado pela Occentus Networks (UE)
  6. Direitos: A qualquer momento você pode limitar, recuperar e excluir suas informações.