.
Uma vulnerabilidade de dia zero no protocolo HTTP/2 foi explorada para lançar o maior ataque distribuído de negação de serviço (DDoS) já registrado, de acordo com a Cloudflare.
Ultrapassando 398 milhões de solicitações por segundo, acredita-se que o ataque seja cinco vezes maior que o Registro anterior de 71 milhões de solicitações por segundo. Google, Cloudflare e AWS lideraram uma divulgação coordenada de vulnerabilidade na terça-feira para a falha rastreada como CVE-2023-44487 ou Reinicialização rápida.
Todos os três têm monitorado ataques na camada de aplicação (camada 7) muito maiores do que o considerado normal há meses, com pico de atividade em agosto, disseram eles. O trio estava interessado em descobrir exatamente como essa enxurrada de tráfego estava sendo gerada. Quem quer que estivesse lançando esses ataques queria sobrecarregar seus alvos com pacotes, fazendo com que os sistemas ficassem offline para usuários legítimos.
A análise da Cloudflare revelou que os cibercriminosos estavam explorando a fraqueza mencionada no HTTP/2 usando uma rede menor do que o normal de bots controlados por criminosos, o que explica em parte o enorme número de solicitações por segundo.
“Uma coisa crucial a ser observada sobre o ataque recorde é que ele envolveu uma botnet de tamanho modesto, composta por cerca de 20.000 máquinas. A Cloudflare detecta regularmente botnets que são ordens de magnitude maiores do que isso – compreendendo centenas de milhares e até milhões de máquinas, “o negócio disse.
“O fato de uma botnet relativamente pequena gerar um volume tão grande de solicitações, com o potencial de incapacitar praticamente qualquer servidor ou aplicativo que suporte HTTP/2, ressalta o quão ameaçadora essa vulnerabilidade é para redes desprotegidas.”
Todos os três provedores de serviços publicaram mitigações e implementaram novas tecnologias para proteção contra ataques de Rapid Reset no futuro.
Como funciona a reinicialização rápida
O método depende da multiplexação de fluxo, um recurso do protocolo HTTP/2 que permite que várias solicitações HTTP sejam enviadas a um servidor em uma única conexão TCP. Essas solicitações são transmitidas em série para o servidor ao longo dessa conexão; o servidor coleta os fluxos de solicitações, processa-os e responde. Portanto, quando seu navegador abre uma página, ele pode disparar solicitações separadas para todo o conteúdo da página em série nessa conexão. Supõe-se que isso seja mais eficiente do que a abordagem tradicional do HTTP/1.x, que normalmente envolve gastar tempo e recursos para estabelecer múltiplas conexões TCP paralelas para buscar coisas de um servidor. HTTP/2 faz tudo em uma conexão.
Uma característica da capacidade de streaming do protocolo é a capacidade de enviar uma solicitação e logo depois cancelar essa solicitação, uma ação conhecida como redefinir o fluxo da solicitação. Quando um cliente faz uma solicitação e a cancela, o servidor desiste de processar a solicitação enquanto mantém a conexão HTTP/2 aberta. Isso evita ter que abrir e fechar múltiplas conexões TCP e é útil para buscar um carregamento de imagens em uma página e depois cancelar aquelas que não estão visíveis se a janela já tiver passado por elas, por exemplo.
Um ataque DDoS normal baseado em HTTP/2 envolveria os invasores abrindo o maior número possível desses fluxos e aguardando respostas a cada solicitação do servidor ou proxy antes de disparar outra enxurrada de solicitações e repetir isso indefinidamente. Existem apenas alguns fluxos que um servidor permite uma conexão TCP, portanto, ele pode aceitar apenas 100 fluxos por vez. O principal aqui é que o invasor espere que essas cerca de 100 respostas cheguem antes de enviar outra carga de solicitações.
Os ataques de redefinição rápida contornam esse limite, permitindo que muito mais solicitações inundem um servidor. É tão simples quanto enviar uma solicitação em um stream e, em seguida, redefinir rapidamente o stream, cancelar a solicitação e manter a conexão aberta. O servidor começa a processar essas solicitações e depois para. Como cada solicitação foi cancelada, ele não conta no número máximo de fluxos permitidos. Você apenas continua disparando uma solicitação e redefinindo rapidamente seu fluxo, e faz isso quantas vezes puder, e agora o servidor está tendo que iniciar e interromper um número esmagador de solicitações inúteis.
Google explica aqui como os invasores podem garantir que um grande número de solicitações permaneça em andamento, sem nunca exceder o número máximo de fluxos permitidos pelo servidor. A largura de banda da rede passa a ser o fator que determina o número de solicitações que podem ser feitas, ao invés do tempo de ida e volta (RTT).
“O cliente abre um grande número de fluxos de uma só vez, como no ataque HTTP/2 padrão, mas em vez de esperar por uma resposta a cada fluxo de solicitação do servidor ou proxy, o cliente cancela cada solicitação imediatamente”, como explica Juho Snellman, engenheiro do Google. e Daniele Iamartino colocou.
Essas solicitações canceladas exigem muito trabalho desnecessário do servidor, custando tempo e dinheiro para processar coisas sem nunca enviar nada de volta, enquanto o cliente, ou neste caso o invasor, paga “quase nenhum custo” pelo envio.
Essencialmente, o processo permite que os invasores inundem os servidores com mais solicitações do que nunca, levando a ataques DDoS em maior escala e difíceis de mitigar.
Variantes
Embora os criminosos por trás dessa onda de ataques não sejam conhecidos, o Google observou algumas variantes do método de ataque. Não está claro se estes foram realizados por grupos diferentes ou pelo mesmo grupo experimentando métodos diferentes.
Uma das melhores variantes não cancelou imediatamente as transmissões. Ele abriu um lote de streams de uma vez e os cancelou após esperar um período de tempo, depois abriu outro grande lote de streams e repetiu o processo.
O Google disse que esse método pode contornar as mitigações que envolvem a limitação do número de quadros de redefinição de fluxo que podem ser enviados por segundo, mas ainda foi menos eficaz do que o Rapid Reset original.
A segunda variante tenta abrir mais fluxos do que o servidor permite, sem cancelá-los de forma alguma – um método que pode contornar alguns gargalos RTT cliente-proxy e RTT servidor proxy, mas é improvável que seja processado pela maioria dos servidores HTTP/2, Google diz.
Mitigações
A Cloudflare fez alterações em seu serviço de mitigação de DDoS para combater ataques de Rapid Reset, disponibilizando-o para todos os clientes. AWS disse aqueles que desenvolveram uma arquitetura forte resistente a DDoS usando CloudFront e AWS Shield não terão afetado a disponibilidade de seus aplicativos devido às medidas que a Amazon tomou para derrotar os ataques de Rapid Reset quando eles começaram a aparecer.
O Google explicou que há várias maneiras de implementar mitigações para ataques de Rapid Reset, mas desencorajou o uso de frames GOAWAY, conforme recomendado em Especificação do HTTP/2 para fechar conexões.
Eles não estão configurados para lidar com o tipo de atividade vista em ataques de Rapid Reset e não devem ser usados sozinhos, disse o gigante da web, mas podem e devem ser usados para limitar a criação de fluxos. Consulte os links acima para obter mais informações técnicas.
“As mitigações para esse vetor de ataque podem assumir várias formas, mas principalmente giram em torno do rastreamento de estatísticas de conexão e do uso de vários sinais e lógica de negócios para determinar a utilidade de cada conexão”, disse a equipe do Google.
“Por exemplo, se uma conexão tiver mais de 100 solicitações com mais de 50% das solicitações canceladas, ela poderá ser candidata a uma resposta de mitigação. A magnitude e o tipo de resposta dependem do risco para cada plataforma, mas as respostas podem variam desde quadros GOAWAY forçados, conforme discutido antes, até o fechamento imediato da conexão TCP.
“Para mitigar a variante sem cancelamento deste ataque, recomendamos que HTTP/2 os servidores devem fechar conexões que excedam o limite de fluxo simultâneo. Isto pode ocorrer imediatamente ou após um pequeno número de reincidências.” ®
.
