Novo ataque DDoS HTTP/2 “Rapid Reset”

 (cloud.google.com)
1 pontos por GN⁺ 2023-10-11 | 1 comentários | Compartilhar no WhatsApp
  • Um DDoS de Camada 7 baseado em HTTP/2 direcionado a serviços do Google e clientes do Google Cloud atingiu seu pico em agosto de 2023, ultrapassando 398 milhões de requisições por segundo no maior ataque
  • O ataque foi bloqueado em sua maior parte pela infraestrutura global de balanceamento de carga do Google, não resultou em indisponibilidade, e novas proteções foram adicionadas depois para mitigar ataques semelhantes
  • O Rapid Reset cancela apenas o stream com um frame RST_STREAM logo após a requisição, mantendo a conexão aberta e repetindo a criação de requisições enquanto evita o limite de streams simultâneos
  • Mesmo para requisições canceladas, o servidor pode executar tarefas como descompactação de cabeçalhos, mapeamento de URL e proxy para o backend, aumentando a assimetria de custo
  • Operadores de HTTP/2 devem verificar sua exposição e aplicar patches; quando abuso for detectado, a principal mitigação é encerrar a própria conexão TCP, em vez de bloquear requisições individuais

Escala do ataque e resposta do Google

  • Serviços do Google e clientes do Cloud foram alvo de um ataque DDoS de Camada 7 baseado em HTTP/2 que atingiu o pico em agosto de 2023
  • O maior ataque ultrapassou 398 milhões de requisições por segundo, em escala muito superior à de ataques de Camada 7 relatados anteriormente
  • A infraestrutura global de balanceamento de carga do Google bloqueou a maior parte do ataque na borda da rede
    • Não houve indisponibilidade
    • O impacto permaneceu limitado
  • A Google DDoS Response Team analisou o ataque e aplicou proteções adicionais para reduzir ataques semelhantes
  • O Google, junto com parceiros do setor, liderou um processo coordenado de divulgação para lidar com o novo vetor de ataque HTTP/2

Pontos em que o HTTP/2 favorece DDoS

  • Desde o fim de 2021, muitos dos ataques DDoS de Camada 7 observados em serviços 1st-party do Google e em projetos do Google Cloud protegidos pelo Cloud Armor foram baseados em HTTP/2
    • Foram numerosos também em quantidade de ataques
    • E altos também em termos de taxa máxima de requisições
  • A eficiência do HTTP/2 pode aumentar não apenas a eficiência de clientes legítimos, mas também a de ataques DDoS

  • Multiplexação de streams

    • O HTTP/2 transmite frames entre endpoints por meio de uma abstração bidirecional chamada stream
    • Graças à multiplexação de streams, várias requisições podem ser processadas simultaneamente em uma única conexão TCP
    • Uma das principais restrições de ataques DoS de Camada 7 é o número de conexões de transmissão simultâneas
      • Cada conexão usa memória do sistema operacional para registros de socket e buffers
      • Handshakes TLS exigem tempo de CPU
      • É necessário um 4-tuple único composto pelos endereços IP e pares de portas dos dois lados
    • O HTTP/1.1 normalmente processa requisições em série, de modo que a taxa de requisições de uma única conexão fica próxima de 1 requisição por tempo de ida e volta
    • No HTTP/2, uma única conexão TCP pode abrir vários streams simultâneos, e cada stream corresponde a uma requisição HTTP
    • Em ambientes reais, um cliente pode abrir 100 streams por requisição e o servidor pode processá-los em paralelo, elevando a vazão efetiva de uma única conexão para algo em torno de 100 requisições por ida e volta
    • Como resultado, a utilização da conexão pode ser quase 100 vezes maior do que no HTTP/1.1

Como o Rapid Reset funciona

  • O HTTP/2 permite que o cliente envie um frame RST_STREAM para avisar ao servidor que está cancelando um stream anterior
  • O cancelamento não exige coordenação separada entre cliente e servidor
    • O cliente pode cancelar unilateralmente
    • Pode-se assumir que o servidor que recebeu o frame RST_STREAM aplicará o cancelamento antes de outros dados na mesma conexão TCP
  • O Rapid Reset depende do envio de um frame RST_STREAM logo após o envio do frame da requisição
    • Ele faz o endpoint do outro lado iniciar o trabalho e, em seguida, reseta rapidamente a requisição
    • A requisição é cancelada, mas a conexão HTTP/2 permanece aberta
  • O procedimento do ataque é simples
    • Como em um ataque HTTP/2 padrão, abre muitos streams de uma vez
    • Não espera a resposta do servidor ou do proxy
    • Cancela cada requisição imediatamente
  • Se o reset imediato for possível, cada conexão pode, na prática, colocar um grande número de requisições em andamento por tempo indefinido
    • O atacante não excede explicitamente o limite de streams abertos simultaneamente
    • O número de requisições em andamento passa a depender mais da largura de banda de rede disponível do que do tempo de ida e volta (RTT)
  • Implementações comuns de servidores HTTP/2 podem precisar executar trabalho mesmo em requisições canceladas
    • Alocação de estruturas de dados para novos streams
    • Parsing de queries
    • Descompactação de cabeçalhos
    • Mapeamento de URLs para recursos
  • Em implementações de proxy reverso, a requisição pode ser encaminhada por proxy para o servidor backend antes que o frame RST_STREAM seja processado
  • Como o cliente praticamente não paga o custo de transmitir a requisição, surge uma assimetria de custo explorável entre servidor e cliente
  • Se a requisição for cancelada antes da escrita da resposta, o servidor de proxy reverso não envia a resposta, reduzindo também a largura de banda de downlink que sai do servidor ou proxy em direção ao atacante

Variantes de ataque observadas

  • Nas semanas após o DDoS inicial, foram observadas variantes do Rapid Reset
  • As variantes não são tão eficientes quanto o método inicial, mas ainda podem ser mais eficientes do que ataques DDoS HTTP/2 padrão

  • Variante de cancelamento em lote

    • A primeira variante não cancela os streams imediatamente; ela abre um lote de streams, espera um pouco e depois cancela todos de uma vez
    • Logo após o cancelamento, abre novamente um novo grande lote de streams e continua o ataque
    • Essa abordagem pode contornar mitigações baseadas apenas na proporção de frames RST_STREAM de entrada
      • Ex.: política que permite no máximo 100 RST_STREAM por segundo por conexão e fecha a conexão ao exceder isso
    • Por não maximizar a utilização da conexão, os principais benefícios do ataque de cancelamento são reduzidos
    • Ainda assim, por poder ser mais eficiente na implementação do que ataques DDoS HTTP/2 padrão, limitar apenas a taxa de cancelamento de streams exigiria restrições bastante rigorosas

  • Variante sem cancelamento

    • A segunda variante não cancela streams de forma alguma
    • Em vez disso, tenta abrir de forma otimista mais streams do que o número de streams simultâneos anunciado pelo servidor
    • Ela consegue manter o pipeline de requisições sempre cheio, reduzindo o gargalo de RTT entre cliente e proxy
    • Ao mirar recursos aos quais o servidor HTTP/2 responde imediatamente, também pode eliminar o gargalo de RTT entre proxy e servidor
    • A RFC atual do HTTP/2, RFC 9113, sugere que, em tentativas de abrir streams demais, apenas os streams que excedem o limite sejam invalidados, não a conexão inteira
    • Na maioria dos servidores HTTP/2, quando a arquitetura não processa streams excedentes, um novo stream pode ser recebido e processado quase imediatamente após a resposta do stream anterior, tornando possível a variante sem cancelamento

Estratégias de mitigação

  • Para essa família de ataques, bloquear apenas requisições individuais dificilmente é uma mitigação viável
  • Quando abuso for detectado, é preciso fechar a conexão TCP inteira
  • O HTTP/2 oferece suporte ao encerramento da conexão por meio do tipo de frame GOAWAY
  • A RFC define um procedimento de encerramento gradual: primeiro envia um GOAWAY informativo que não define limite para abertura de novos streams e, após uma ida e volta, envia um GOAWAY que proíbe a abertura de streams adicionais
  • Porém, esse procedimento gradual de GOAWAY muitas vezes não é suficientemente robusto contra clientes maliciosos
    • A conexão fica exposta por tempo demais ao ataque Rapid Reset
    • Ele não interrompe requisições de entrada
  • Para fins de mitigação, o GOAWAY deve ser configurado para restringir imediatamente a criação de streams

  • Identificação de conexões abusivas

    • O fato de um cliente cancelar requisições não é, por si só, sempre abuso
    • O recurso de cancelamento do HTTP/2 existe para gerenciar melhor o processamento de requisições
      • Quando o usuário sai de uma página e o navegador não precisa mais dos recursos solicitados
      • Aplicações que usam long polling com timeout do lado do cliente
    • A mitigação se concentra em rastrear estatísticas da conexão e julgar a utilidade de cada conexão com base em vários sinais e na lógica de negócio
    • Por exemplo, se uma conexão tiver mais de 100 requisições e mais de 50% delas tiverem sido canceladas, ela pode ser candidata à mitigação
    • A intensidade e o tipo de resposta variam de acordo com o risco de cada plataforma
      • Frame GOAWAY forçado
      • Encerramento imediato da conexão TCP
    • Para mitigar a variante sem cancelamento, recomenda-se que servidores HTTP/2 fechem conexões que excedam o limite de streams simultâneos
      • Podem fechar imediatamente
      • Ou podem fechar após um pequeno número de violações repetidas

Aplicabilidade ao HTTP/3

  • Devido a diferenças de protocolo, o Google não considera que esse método de ataque se aplique diretamente ao HTTP/3 (QUIC)
  • No momento, o Google não observa o HTTP/3 sendo usado como vetor de ataques DDoS em larga escala
  • Ainda assim, recomenda-se que implementações de servidores HTTP/3 adotem proativamente mecanismos que limitem a quantidade de trabalho realizada por uma única conexão de transporte
    • Em linha semelhante às mitigações de HTTP/2 discutidas

Coordenação do setor e CVE

  • Desde o início da investigação da Google DDoS Response Team, ficou claro que esse tipo de ataque poderia afetar amplamente todos os serviços que oferecem HTTP/2
  • O Google usou um grupo existente de divulgação coordenada de vulnerabilidades para liderar um processo coordenado de divulgação de vulnerabilidade
  • O processo de divulgação se concentrou em avisar grandes implementadores de HTTP/2
    • Empresas de infraestrutura
    • Fornecedores de software de servidor
  • O objetivo do aviso antecipado era permitir o desenvolvimento de mitigações e a preparação alinhada ao cronograma de divulgação coordenada
  • No passado, essa abordagem já levou à aplicação ampla de proteções por provedores de serviço ou ao fornecimento de atualizações de software para diversos pacotes e soluções
  • Durante o processo de divulgação coordenada, CVE-2023-44487 foi reservado para rastrear correções em várias implementações HTTP/2

O que operadores de serviços HTTP/2 devem fazer

  • Esse ataque pode causar impacto significativo em serviços de qualquer porte
  • Todo provedor que ofereça serviços HTTP/2 deve avaliar sua exposição a essa questão
  • Patches e atualizações de software para servidores web comuns e linguagens de programação podem estar disponíveis agora ou em breve
  • Recomenda-se aplicar as correções disponíveis o mais rápido possível
  • Para clientes do Google Cloud, junto com patches de software, recomenda-se o uso do Application Load Balancer e do Google Cloud Armor
    • O Google Cloud Armor vem protegendo o Google e usuários existentes do Google Cloud Application Load Balancing

Leituras relacionadas

1 comentários

 
GN⁺ 2023-10-11
Opiniões no Hacker News

  • Threads relacionadas em andamento:
    O maior ataque DDoS até agora, com pico de mais de 398 milhões de requisições por segundo - https://news.ycombinator.com/item?id=37831062
    Vulnerabilidade zero-day no HTTP/2 causa ataque DDoS recorde - https://news.ycombinator.com/item?id=37830998

  • É bom ver que a equipe do HAProxy aparentemente já tinha identificado e mitigado esse tipo de problema no HTTP/2 em 2018: https://www.mail-archive.com/haproxy@formilux.org/msg44134.h...

  • Em uma implementação típica de servidor HTTP/2, mesmo para requisições canceladas, ainda é preciso fazer bastante trabalho, como alocar novas estruturas de dados de stream, fazer parsing da consulta, descompactar cabeçalhos e mapear recursos da URL
    Em implementações de proxy reverso, a requisição pode ser encaminhada por proxy para o servidor de backend antes que o frame RST_STREAM seja processado. Já o cliente quase não paga custo algum para enviar a requisição, criando uma assimetria de custo explorável entre servidor e cliente
    É surpreendente que isso não tenha sido previsto no design do HTTP/2. Ataques de amplificação já eram bem conhecidos em outros protocolos. É igualmente surpreendente que esse ataque só tenha aparecido tão tarde, embora talvez o HTTP/2 não estivesse implantado de forma ampla o suficiente até recentemente para ser um alvo valioso

    • Estritamente falando, isso não é um ataque de amplificação. Está mais para uma forma muito mais eficiente de usar uma conexão TCP
    • Também fiquei surpreso, mas, olhando a linha do tempo, o RST_STREAM já existia nas versões iniciais do SPDY, e o SPDY parece ter sido projetado por volta de 2009
      Ataques como o Slowloris surgiram quase na mesma época, mas não eram amplamente conhecidos então. Por outro lado, SYN cookies foram introduzidos em 1996, então há claramente precedentes históricos para ataques em que a vítima paga Y e o atacante paga X
    • Como acontece com a maioria dessas coisas, é bem provável que muitas pessoas sem importância já tenham percebido e testado isso
      O ponto incomum é que alguém tentou seriamente contra o Google

  • No fim, precisamos do HTTP/2 para entregar anúncios, rastreadores e frameworks de frontend inchados mais rapidamente. Agora ele também entrega ataques mais rapidamente

    • O HTTP/2 torna a experiência de navegação em conexões de alta latência muito mais tolerável. Em geral, também torna o carregamento de páginas web mais rápido
      Felizmente, o HTTP/1.1 ainda funciona. Se você não gosta desse protocolo, pode ativar HTTP/1.1 quando quiser nas configurações do navegador e no servidor web
    • Você quer dizer que não precisávamos do HTTP/2? Se for isso, qual seria uma alternativa realista?

  • Mais um motivo para manter os protocolos de base pequenos. O HTTP/2 existe há mais de 10 anos se incluirmos o SPDY, e esse tipo de ataque está aparecendo pela primeira vez
    Fico curioso para saber que surpresas podem estar escondidas em HTTP/3 e QUIC

    • DNS é um protocolo pequeno e, ainda assim, é abusado por atacantes DDoS do mundo inteiro em ataques de reflexão
    • O QUIC não considerou adequadamente ataques de amplificação no design, e as pessoas que levantaram essa preocupação no início foram ignoradas
    • O HTTP/2 é bem pequeno

  • “Cancelamento” também deveria entrar na lista de “problemas difíceis da ciência da computação”
    Como os outros itens dessa lista, por exemplo erros de diferença de 1 ou invalidação de cache, não é realmente absurdamente difícil, mas é fácil subestimar e deixar passar. Se gastássemos no design de destruição, limpeza, desmontagem e cancelamento pelo menos metade do tempo que gastamos com criação, construtores e inicialização, acho que haveria muito menos bugs de esgotamento de recursos

    • O async do Rust é muito bom porque consegue cancelar imediatamente um Future em qualquer ponto de await, sem cooperação de chamadas individuais, cancelando junto toda a pilha de chamadas
    • Em bibliotecas C, isso certamente é verdade. O cancelamento de threads POSIX é o tipo de recurso cuja mera existência faz suas implicações se espalharem por todos os lugares

  • Quero lembrar a todos que o Google é a empresa que criou o HTTP/2
    Agora eles falam como se estivessem nos salvando heroicamente de um problema que eles mesmos criaram, mas não mencionam a parte em que foram eles que o criaram. Que cara de pau dessas empresas de tecnologia. A Microsoft fez isso por décadas também

    • Eles estavam tentando resolver um problema que não existia

  • Alguém pode explicar o que há de novo neste ataque em comparação com uma enxurrada comum de requisições?

    • Depende do que você considera um ataque de “enxurrada de requisições”
      No HTTP/1.1, era possível enviar uma requisição por tempo de ida e volta[0]. Com a multiplexação do HTTP/2, é possível enviar 100 por tempo de ida e volta. Neste ataque, é possível enviar, na prática, um número infinito de requisições por tempo de ida e volta. Espero que o diagrama do artigo mostre a diferença, mas talvez você esteja se referindo a outro tipo de ataque
      [0] Se considerarmos o pipelining do HTTP/1.1, dá para eliminar um fator de tempo de ida e volta, mas clientes reais quase nunca usam pipelining HTTP/1.1, então seu uso por si só vira um sinal muito claro de tráfego malicioso
    • A nova técnica descrita evita o limite máximo de requisições por segundo por cliente que um atacante consegue fazer o servidor processar
      Ao enviar requisições e resets de stream dentro de uma única conexão, é possível enviar mais requisições por conexão/cliente do que antes, o que pode tornar o ataque mais barato ou mais difícil de bloquear

  • O cabeçalho do blog fica pulando para fora e torna a página ilegível