Vulnerabilidade de redefinição rápida no HTTP/2 causa o maior DDoS já registrado

• O Google mitigou um DDoS em escala recorde, com 398 milhões de requisições por segundo.
  • O número de requisições geradas nos 2 minutos do ataque foi maior do que o tráfego mensal da Wikipédia.
• Esse ataque foi causado por uma nova vulnerabilidade do HTTP/2 chamada Rapid Reset.
  • Ela explora o multiplexing de streams e o recurso de cancelamento de requisições do funcionamento do HTTP/2.
  • Um único cliente pode criar um número ilimitado de requisições, desde que a largura de banda da rede permita.
    • Normalmente, ataques DoS de camada 7 dependem de RTT e do número de conexões simultâneas, o que limita a quantidade de requisições que um cliente pode gerar.
    • Mas esse método permite gerar requisições muito rapidamente ao cancelá-las imediatamente após a criação.
  • Diferentemente dos maiores DDoS já vistos anteriormente, esse ataque pode ser eficaz com um número pequeno de dispositivos.
  • Essa vulnerabilidade pode ser consultada em CVE-2023-44487 e recebeu pontuação CVSS de 7,5, considerada severa.
• Outros provedores, como Cloudflare e AWS, também sofreram ataques DDoS de 201 milhões de RPS e 155 milhões de RPS, respectivamente.
  • A Cloudflare informou que o ataque foi realizado por uma botnet com cerca de 20 mil máquinas.
    • Os DDoS gigantes de antes normalmente eram realizados por botnets com dezenas de milhares a milhões de dispositivos.
• Servidores web como Nginx e Caddy estão aplicando patches rapidamente.
  • Curiosamente, o HAProxy resolveu esse problema em 2018.

[kuroneko]

• Thread no HN no link acima
• Thread relacionado no HN
  • Google - Como funciona: o novo ataque DDoS de "Rapid Reset" no HTTP/2
• Thread relacionado no HN
  • Cloudflare - Ataque DDoS recorde causado por vulnerabilidade zero-day no HTTP/2

Quase 400 milhões de requisições por segundo... realmente assustador.
Era uma vulnerabilidade em implementações de HTTP/2, e também é impressionante que Google, Cloudflare, AWS e outros tenham conseguido mitigá-la.

O mais curioso para mim é que o HAProxy resolveu esse problema em 2018.
Na época, eles não identificaram nem corrigiram essa vulnerabilidade especificamente, mas ao revisar isso depois, descobriram que a questão levantada em 2018 trazia a ideia que acabava resolvendo essa vulnerabilidade.

De qualquer forma, quem usa servidor web deveria atualizar para uma versão em que essa vulnerabilidade já tenha sido corrigida.