O Google registrou o maior ataque DDoS já sofrido por sua infraestrutura, com uma intensidade de 398 milhões de requisições por segundo. Este novo ataque é sete vezes mais intenso que o recorde anterior, no qual os atacantes conseguiram gerar uma avalanche de 47 milhões de requisições por segundo. Para efeito de comparação, estima-se que todo o tráfego da web seja de 1 a 3 bilhões de requisições por segundo. Além do Google, a Amazon e a Cloudflare também foram afetadas pelo ataque. O novo ataque foi possível devido à descoberta de uma vulnerabilidade no protocolo HTTP/2 (CVE-2023-44487), que permite que uma enorme quantidade de requisições seja direcionada ao servidor com uma carga mínima nos clientes.
A nova técnica de ataque, denominada "Rapid Reset", explora o fato de que os recursos de multiplexação de canais do HTTP/2 permitem a geração de um fluxo de requisições dentro de uma conexão existente, sem a necessidade de abrir novas conexões de rede ou aguardar a confirmação de pacotes. Acredita-se que a vulnerabilidade seja consequência de uma falha no protocolo HTTP/2, cuja especificação estabelece que, ao tentar abrir fluxos em excesso, apenas os fluxos que excedem o limite devem ser descartados, em vez de toda a conexão de rede ser fechada.
Semelhante aos métodos de ataque HTTP/2 usados anteriormente, o novo ataque também cria um grande número de fluxos em uma única conexão. A principal diferença é que, em vez de esperar por uma resposta, cada solicitação enviada é seguida por um quadro com o sinalizador RST_STREAM, que cancela imediatamente a solicitação. O cancelamento antecipado da solicitação elimina o tráfego de retorno para o cliente e contorna as limitações do servidor HTTP quanto ao número máximo de fluxos abertos simultaneamente em uma única conexão HTTP/2. Portanto, no novo ataque, o volume de solicitações enviadas ao servidor HTTP não depende mais do tempo de ida e volta (RTT) entre o envio da solicitação e o recebimento da resposta, sendo limitado exclusivamente pela largura de banda do canal de comunicação.
Como um ataque do lado do cliente requer simplesmente o envio de solicitações sem receber respostas, o ataque pode ser realizado com sobrecarga mínima. Por exemplo, o ataque de 201 milhões de solicitações por segundo registrado pela Cloudflare foi realizado usando uma botnet relativamente pequena de 20 computadores. servidor O custo de processamento de solicitações recebidas é significativamente maior, mesmo após seu cancelamento, devido à necessidade de realizar operações como alocação de estruturas de dados para novos fluxos, análise da solicitação, desempacotamento do cabeçalho e correspondência da URL com o recurso. Ao atacar proxies reversos, o ataque pode se propagar para os servidores de backend, já que o proxy pode redirecionar a solicitação para o backend antes que o frame RST_STREAM seja processado.
O ataque só pode ser realizado em servidores vulneráveis que suportam HTTP/2 (script para verificar vulnerabilidades em servidores, ferramentas de ataque). Nenhum ataque foi detectado para HTTP/3 até o momento, e sua viabilidade ainda não foi totalmente analisada, mas representantes do Google recomendam que os desenvolvedores servidores Adicionar às implementações do HTTP/3 medidas de proteção semelhantes às implementadas para bloquear ataques ao HTTP/2.
Exposição e disponibilidade de patches para servidores e proxies HTTP:
- nginx (anúncio, esclarecimento de que a vulnerabilidade não é totalmente evidente na configuração padrão do nginx, pois o ataque seria limitado pelo limite de requisições de conexão (ou seja, a conexão seria reiniciada a cada 1000 requisições). A correção adiciona proteção adicional limitando a taxa de requisições por meio da diretiva "limit_req".
- O HAProxy adicionou proteção eficaz contra o limite de threads HTTP/2 excedido em 2018, e essa proteção está em vigor desde a versão 1.9-dev.
- Apache httpd (uma certa carga é criada no httpd, mas não se estende aos servidores de backend e é limitada pelos limites de conexão do cliente em vigor desde 2016).
- mod_h2 para Apache httpd.
- Caddie
- enviado
- golang (o problema foi corrigido nas versões 1.21.3 e 1.20.10 do Go).
- h2o (remendo).
- grpc-go
- hiper (a vulnerabilidade não se manifesta).
- cais (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).
- proxy do Facebook
- .NET e ASP.NET Core (o servidor HTTP Kestrel do ASP.NET Core é vulnerável).
- Node.js
- proxy
- 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).
- Servidor de tráfego Apache (corrigido na versão 9.2.x).
Fonte: opennet.ru
