Hoje cedo, a Cloudflare, juntamente com o Google e a Amazon AWS, divulgaram a existência de uma nova vulnerabilidade de dia zero chamada de ataque “HTTP/2 Rapid Reset”. Este ataque explora uma fraqueza no protocolo HTTP/2 para gerar ataques enormes e hipervolumétricos de negação de serviço distribuída (DDoS). A Cloudflare mitigou uma série desses ataques nos últimos meses, incluindo um ataque três vezes maior do que qualquer ataque anterior que observamos, que ultrapassou 201 milhões de solicitações por segundo (rps). Desde o final de agosto de 2023, a Cloudflare mitigou mais de 1.100 outros ataques com mais de 10 milhões de rps — e 184 ataques que foram superiores ao nosso recorde anterior de DDoS de 71 milhões de rps.
Este dia zero forneceu aos agentes de ameaças uma nova ferramenta crítica no seu canivete suíço de vulnerabilidades para explorar e atacar as suas vítimas numa magnitude nunca vista antes. Embora às vezes complexos e desafiadores de combater, esses ataques deram à Cloudflare a oportunidade de desenvolver tecnologia desenvolvida especificamente para mitigar os efeitos da vulnerabilidade de dia zero.
Se você estiver usando Cloudflare para mitigação de DDoS HTTP, você estará protegido. E abaixo, incluímos mais informações sobre esta vulnerabilidade e recursos e recomendações sobre o que você pode fazer para se proteger.
Desconstruindo o ataque: o que todo CSO precisa saber
No final de agosto de 2023, nossa equipe na Cloudflare percebeu uma nova vulnerabilidade de dia zero, desenvolvida por um agente de ameaça desconhecido, que explora o protocolo HTTP/2 padrão — um protocolo fundamental que é crítico para o funcionamento da Internet e de todos os sites. Este novo ataque de vulnerabilidade de dia zero, denominado Rapid Reset, aproveita o recurso de cancelamento de fluxo do HTTP/2, enviando uma solicitação e cancelando-a imediatamente repetidamente.
Ao automatizar esse padrão trivial de “solicitar, cancelar, solicitar, cancelar” em escala, os agentes de ameaças são capazes de criar uma negação de serviço e derrubar qualquer servidor ou aplicativo que execute a implementação padrão de HTTP/2. Além disso, uma coisa crucial a notar sobre o ataque recorde é que 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 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.
Os agentes de ameaças usaram botnets em conjunto com a vulnerabilidade HTTP/2 para amplificar solicitações em taxas nunca vistas antes. Como resultado, nossa equipe na Cloudflare passou por alguma instabilidade intermitente nas bordas. Embora nossos sistemas tenham conseguido mitigar a grande maioria dos ataques recebidos, o volume sobrecarregou alguns componentes da nossa rede, impactando o desempenho de um pequeno número de clientes com erros intermitentes 4xx e 5xx — todos os quais foram rapidamente resolvidos.
Depois de mitigarmos com sucesso esses problemas e interrompermos possíveis ataques a todos os clientes, nossa equipe iniciou imediatamente um processo de divulgação responsável. Iniciamos conversas com colegas do setor para ver como poderíamos trabalhar juntos para ajudar a levar adiante nossa missão e proteger a grande porcentagem da Internet que depende de nossa rede antes de liberar esta vulnerabilidade ao público em geral.
Cobrimos os detalhes técnicos do ataque com mais detalhes em uma postagem separada no blog: HTTP/2 Rapid Reset: desconstruindo o ataque recorde.
Como a Cloudflare e a indústria estão impedindo esse ataque?
Não existe “divulgação perfeita”. Impedir ataques e responder a incidentes emergentes exige que as organizações e as equipes de segurança vivam com uma mentalidade de suposição de violação – porque sempre haverá outro dia zero, novos grupos de atores de ameaças em evolução e novos ataques e técnicas nunca antes vistos.
Esta mentalidade de “presumir a violação” é uma base fundamental para a partilha de informações e para garantir, em casos como este, que a Internet permaneça segura. Enquanto a Cloudflare enfrentava e mitigava esses ataques, também trabalhávamos com parceiros do setor para garantir que o setor como um todo pudesse resistir a esse ataque.
Durante o processo de mitigação desse ataque, nossa equipe da Cloudflare desenvolveu e desenvolveu novas tecnologias especificamente para impedir esses ataques DDoS e melhorar ainda mais nossas próprias mitigações para este e outros ataques futuros de grande escala. Estes esforços aumentaram significativamente as nossas capacidades globais de mitigação e resiliência. Se você usa Cloudflare, temos certeza de que você está protegido.
Nossa equipe também alertou parceiros de software de servidores web que estão desenvolvendo patches para garantir que esta vulnerabilidade não possa ser explorada – verifique seus sites para obter mais informações.
As divulgações nunca são uma só e estão feitas. A força vital da Cloudflare é garantir uma Internet melhor, o que decorre de casos como estes. Quando temos a oportunidade de trabalhar com os nossos parceiros industriais e governos para garantir que não haja impactos generalizados na Internet, estamos a fazer a nossa parte para aumentar a resiliência cibernética de todas as organizações, independentemente da dimensão ou vertical.
Quais são as origens do HTTP/2 Rapid Reset e desses ataques recordes à Cloudflare?
Pode parecer estranho que a Cloudflare tenha sido uma das primeiras empresas a testemunhar estes ataques. Por que os agentes de ameaças atacariam uma empresa que possui algumas das defesas mais robustas contra ataques DDoS do mundo?
A realidade é que a Cloudflare muitas vezes detecta ataques antes que eles atinjam alvos mais vulneráveis. Os atores de ameaças precisam desenvolver e testar suas ferramentas antes de implantá-las. Os agentes de ameaças que possuem métodos de ataque que quebram recordes podem ter muita dificuldade em testar e compreender quão grandes e eficazes eles são, porque não têm a infraestrutura para absorver os ataques que estão lançando. Devido à transparência que compartilhamos sobre o desempenho de nossa rede e às medições de ataques que eles poderiam obter de nossos gráficos públicos de desempenho, esse ator de ameaça provavelmente estava nos atacando para compreender as capacidades da exploração.
Mas esses testes e a capacidade de detectar o ataque antecipadamente nos ajudam a desenvolver mitigações para o ataque que beneficiam nossos clientes e a indústria como um todo.
De CSO para CSO: O que você deve fazer?
Sou CSO há mais de 20 anos, recebendo inúmeras divulgações e anúncios como este. Mas seja Log4J, Solarwinds, EternalBlue, WannaCry/NotPetya, Heartbleed ou Shellshock, todos esses incidentes de segurança têm algo em comum. Uma tremenda explosão que se espalha pelo mundo e cria uma oportunidade de perturbar completamente qualquer uma das organizações que liderei — independentemente do setor ou do tamanho.
Muitos deles foram ataques ou vulnerabilidades que talvez não tenhamos conseguido controlar. Mas independentemente de o problema ter surgido de algo que estava sob meu controle ou não, o que diferenciou qualquer iniciativa bem-sucedida que liderei daquelas que não se inclinaram a nosso favor foi a capacidade de responder quando vulnerabilidades de dia zero e explorações como esta são identificados.
Embora eu desejasse poder dizer que o Rapid Reset pode ser diferente desta vez, não é. Estou ligando para todos os CSOs — não importa se vocês passaram pelas décadas de incidentes de segurança que eu passei ou se este é seu primeiro dia de trabalho — este é o momento de garantir que vocês estejam protegidos e de reforçar sua equipe de resposta a incidentes cibernéticos .
Mantivemos as informações restritas até hoje para dar ao maior número possível de fornecedores de segurança a oportunidade de reagir. No entanto, em algum momento, o responsável passa a ser divulgar publicamente ameaças de dia zero como essa. Hoje é esse dia. Isso significa que, a partir de hoje, os atores da ameaça estarão amplamente cientes da vulnerabilidade do HTTP/2; e inevitavelmente se tornará trivial explorar e dar início à corrida entre defensores e ataques – primeiro a corrigir versus primeiro a explorar. As organizações devem assumir que os sistemas serão testados e tomar medidas proativas para garantir a proteção.
Para mim, isso lembra uma vulnerabilidade como o Log4J, devido às muitas variantes que surgem diariamente e que continuarão a se concretizar nas próximas semanas, meses e anos. À medida que mais pesquisadores e atores de ameaças experimentam a vulnerabilidade, poderemos encontrar diferentes variantes com ciclos de exploração ainda mais curtos que contêm desvios ainda mais avançados.
E assim como o Log4J, gerenciar incidentes como esse não é tão simples quanto “executar o patch, agora está pronto”. Você precisa transformar o gerenciamento de incidentes, a aplicação de patches e a evolução de suas proteções de segurança em processos contínuos — porque os patches para cada variante de uma vulnerabilidade reduzem o risco, mas não o eliminam.
Não pretendo ser alarmista, mas serei direto: você deve levar isso a sério. Trate isso como um incidente totalmente ativo para garantir que nada aconteça à sua organização.
Recomendações para um novo padrão de mudança
Embora nenhum evento de segurança seja idêntico ao seguinte, há lições que podem ser aprendidas. OSC, aqui estão as minhas recomendações que devem ser implementadas imediatamente. Não apenas neste caso, mas nos próximos anos:
- Entenda a conectividade externa da sua rede externa e de parceiros para corrigir quaisquer sistemas voltados para a Internet com as mitigações abaixo.
- Entenda a proteção de segurança existente e os recursos necessários para proteger, detectar e responder a um ataque e remediar imediatamente quaisquer problemas que você tenha em sua rede.
- Certifique-se de que sua proteção DDoS resida fora do seu data center, pois se o tráfego chegar ao seu data center, será difícil mitigar o ataque DDoS.
- Certifique-se de ter proteção DDoS para aplicativos (camada 7) e firewalls de aplicativos da Web. Além disso, como prática recomendada, certifique-se de ter proteção DDoS completa para DNS, tráfego de rede (camada 3) e firewalls de API
- Certifique-se de que os patches do servidor web e do sistema operacional sejam implantados em todos os servidores web voltados para a Internet. Além disso, certifique-se de que toda a automação, como compilações e imagens do Terraform, sejam totalmente corrigidas para que versões mais antigas de servidores da Web não sejam implantadas na produção por meio de imagens seguras por acidente.
- Como último recurso, considere desligar o HTTP/2 e o HTTP/3 (provavelmente também vulneráveis) para mitigar a ameaça. Este é apenas o último recurso, porque haverá problemas significativos de desempenho se você fizer downgrade para HTTP/1.1
- Considere um provedor secundário de DDoS L7 baseado em nuvem no perímetro para obter resiliência.
A missão da Cloudflare é ajudar a construir uma Internet melhor. Se você está preocupado com seu estado atual de proteção contra DDoS, teremos o maior prazer em fornecer nossos recursos e resiliência contra DDoS gratuitamente para mitigar quaisquer tentativas de um ataque DDoS bem-sucedido. Conhecemos o estresse que vocês estão enfrentando, pois lutamos contra esses ataques nos últimos 30 dias e tornamos nossos já melhores sistemas de classe ainda melhores.
Texto original em HTTP/2 Zero-Day vulnerability results in record-breaking DDoS attacks