Um ataque DDoS HTTP/2 “Rapid Reset” divulgado pelo Google, Cloudflare e AWS. Google, Cloudflare e AWS divulgaram hoje uma nova vulnerabilidade de dia zero chamada ataque HTTP/2 Rapid Reset. Este ataque que está sendo visto no mundo real depende de uma fraqueza no protocolo HTTP2 para realizar ataques de negação de serviço distribuídos “hiper volumétricos”.
Cloudflare, AWS, Google e certamente outros grandes provedores de nuvem foram desafiados por esses ataques nos últimos meses – alguns dos quais ataques DDoS estão agora na faixa de 200 a quase 400 milhões de solicitações por segundo. O Google Cloud relatou um recorde de 398 milhões de RPS como resultado deste ataque agora chamado de ataque HTTP/2 Rapid Reset.
O blog do Google Cloud tem um ótimo artigo sobre essa nova divulgação de segurança.
Ataque DDoS HTTP/2 “Rapid Reset” divulgado pelo Google, Cloudflare e AWS. O ataque HTTP2 Rapid Reset é resumido como:
“O protocolo HTTP/2 permite que os clientes indiquem ao servidor que um fluxo anterior deve ser cancelado enviando um quadro RST_STREAM. O protocolo não exige que o cliente e o servidor coordenem o cancelamento de forma alguma, o cliente pode fazê-lo unilateralmente. O cliente também pode assumir que o cancelamento terá efeito imediatamente quando o servidor receber o quadro RST_STREAM, antes que quaisquer outros dados dessa conexão TCP sejam processados.
Este ataque é denominado Rapid Reset porque depende da capacidade de um endpoint enviar um RST_STREAM frame imediatamente após enviar um frame de solicitação, o que faz com que o outro endpoint comece a funcionar e, em seguida, redefina rapidamente a solicitação. A solicitação é cancelada, mas deixa a conexão HTTP/2 aberta.
…
O ataque HTTP/2 Rapid Reset baseado nesse recurso é simples: o cliente abre um grande número de fluxos de uma 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.
A capacidade de redefinir fluxos imediatamente permite que cada conexão tenha um número indefinido de solicitações em andamento. Ao cancelar explicitamente as solicitações, o invasor nunca excede o limite do número de fluxos abertos simultâneos. O número de solicitações em andamento não depende mais do tempo de ida e volta (RTT), mas apenas da largura de banda de rede disponível.
Em uma implementação típica de servidor HTTP/2, o servidor ainda terá que realizar uma quantidade significativa de trabalho para solicitações canceladas, como alocar novas estruturas de dados de fluxo, analisar a consulta e fazer a descompactação do cabeçalho e mapear a URL para um recurso. Para implementações de proxy reverso, a solicitação pode ser enviada por proxy para o servidor back-end antes que o quadro RST_STREAM seja processado. O cliente, por outro lado, quase não pagou custos pelo envio das solicitações. Isso cria uma assimetria de custos explorável entre o servidor e o cliente.”
Mais informações sobre HTTP2 Rapid Reset podem ser encontradas no blog CloudFlare.