A Google registrou o maior ataque DDoS em sua infraestrutura, com uma intensidade de 398 milhões de solicitações por segundo. O novo ataque supera em 7 vezes a intensidade do ataque DDoS recorde anterior, onde os invasores conseguiram criar um fluxo de 47 milhões de solicitações por segundo. Para comparação, todo o tráfego da Web é avaliado em 1 a 3 bilhões de solicitações por segundo. Além do Google, empresas como Amazon e Cloudflare também enfrentaram o ataque. A possibilidade de um novo ataque está relacionada à descoberta de uma vulnerabilidade no protocolo HTTP/2 (CVE-2023-44487), que permite, com uma carga mínima no cliente, direcionar um enorme fluxo de solicitações ao servidor.
A nova técnica de ataque é chamada de 'Rapid Reset' e se aproveita das ferramentas de multiplexação de canais oferecidas pelo HTTP/2, permitindo a formação de um fluxo de solicitações dentro de uma conexão já estabelecida, sem abrir novas conexões de rede e sem esperar pela confirmação de recebimento dos pacotes. A vulnerabilidade é considerada uma consequência de uma falha no protocolo HTTP/2, cuja especificação afirma que, ao tentar abrir um número excessivo de fluxos, apenas os fluxos que excedem o limite devem ser anulados, mas não todo o conexão de rede.
De maneira semelhante aos métodos de ataque anteriores realizados no HTTP/2, o novo ataque também cria um grande número de fluxos dentro de uma única conexão. A principal diferença é que, em vez de aguardar uma resposta após cada solicitação enviada, um quadro com o sinalizador RST_STREAM é enviado imediatamente após cada solicitação, cancelando a requisição. O cancelamento da solicitação em um estágio inicial ajuda a evitar o tráfego de retorno em direção ao cliente e a contornar as limitações existentes nos servidores HTTP sobre o número máximo de fluxos que podem ser abertos simultaneamente dentro de uma única conexão HTTP/2. Assim, no novo ataque, o volume de solicitações direcionadas ao servidor HTTP não depende mais das latências entre o envio da solicitação e o recebimento da resposta (RTT, round-trip time), mas apenas da largura de banda do canal de comunicação.
Como o ataque na lado do cliente pode ser realizado simplesmente enviando solicitações sem receber respostas, o ataque pode ser realizado com custos mínimos. Por exemplo, um ataque registrado pela Cloudflare, de 201 milhões de solicitações por segundo, foi realizado com um botnet relativamente pequeno de 20 mil computadores. No lado servidor os custos para processar as solicitações recebidas são significativamente mais altos, apesar de seu cancelamento, pois é necessário realizar operações como alocação de estruturas de dados para novos fluxos, análise da solicitação, descompactação do cabeçalho e correspondência de URL com o recurso. Em um ataque a proxies reversos, o ataque pode se espalhar para os backends, já que o proxy pode redirecionar a solicitação para o backend antes do processamento do quadro RST_STREAM.
Um ataque pode ser realizado apenas em servidores vulneráveis que suportam HTTP/2 (script para verificar a manifestação da vulnerabilidade em servidores, conjunto de ferramentas para realizar o ataque). No caso do HTTP/3, ataques ainda não foram registrados e a possibilidade de sua realização não foi totalmente analisada, mas representantes do Google recomendam que os desenvolvedores servidores adicionem à implementação do HTTP/3 medidas de proteção semelhantes às implementadas para bloquear ataques ao HTTP/2.
Susceptibilidade à vulnerabilidade e disponibilidade de correções para servidores HTTP e proxies:
- nginx (anúncio, esclarecimento de que a vulnerabilidade não se manifesta completamente no nginx na configuração padrão, pois o ataque esbarra no limite de solicitações por conexão (ou seja, após cada 1000 solicitações, a conexão será redefinida). A correção inclui uma proteção adicional para limitar a intensidade das solicitações através da diretiva 'limit_req').
- No HAProxy, uma proteção efetiva contra o limite de streams HTTP/2 foi adicionada em 2018 e está em vigor desde a versão 1.9-dev.
- Apache httpd (gera uma carga específica no httpd, mas não se espalha para os backends e é limitada pelos limites de conexões dos clientes em vigor desde 2016).
- mod_h2 para Apache httpd.
- caddy
- envoy
- golang (problema resolvido nas versões Go 1.21.3 e 1.20.10).
- h2o (patch).
- grpc-go
- hyper (a vulnerabilidade não se manifesta).
- jetty (corrigido nas versões 12.0.2, 11.0.17, 10.0.17 e 9.4.53.v20231009).
- netty
- nghttp2 (corrigido na versão 1.57.0).
- Facebook proxygen
- .NET e ASP.NET Core (a vulnerabilidade afeta o servidor http ASP.NET Core Kestrel).
- Node.js
- proxygen
- swift-nio-http2 (corrigido na versão 1.28.0).
- Apache Tomcat (corrigido nas versões 11.0.0-M12, 10.1.14, 9.0.81, 8.5.94).
- Apache Traffic Server (corrigido na ramificação 9.2.x).
Fonte: opennet.ru
