Maior ataque DDoS da história chegou a 398 milhões de rps
(cloud.google.com)- Enquanto a escala dos ataques DDoS cresce rapidamente, em agosto de 2023 o Google mitigou um ataque que atingiu o pico de 398 milhões de rps, 7,5 vezes maior que o recorde do ano anterior, de 46 milhões de rps
- Os atacantes usaram a técnica Rapid Reset, que explora a multiplexação de streams do HTTP/2, afetando várias empresas de infraestrutura da internet
- A onda de ataques começou no fim de agosto de 2023 e continuou em setembro, tendo como alvo grandes provedores de infraestrutura, incluindo serviços do Google, a infraestrutura do Google Cloud e clientes
- O Google absorveu o ataque na borda da rede e atualizou seus sistemas de defesa; clientes do Application Load Balancer e do Cloud Armor também recebem proteção baseada na mesma infraestrutura
- Servidores, proxies, servidores de aplicação e balanceadores de carga que oferecem suporte a HTTP/2 podem ser afetados pela CVE-2023-44487, portanto é necessário verificar a exposição e aplicar patches dos fornecedores
Escala do ataque e técnica Rapid Reset
- A equipe de resposta a DDoS do Google identificou, nos últimos anos, uma tendência de crescimento exponencial na escala dos ataques DDoS
- O ataque bloqueado em agosto de 2023 foi 7,5 vezes maior que o maior recorde do ano anterior
- Chegou ao pico de 398 milhões de requests per second (rps)
- O maior ataque DDoS registrado em 2022 foi de 46 milhões de rps
- Esse ataque, que durou 2 minutos, gerou mais requisições do que o total de visualizações de páginas reportado pela Wikipedia durante todo o mês de setembro de 2023
- A técnica central foi o novo HTTP/2 Rapid Reset, que usa o recurso de multiplexação de streams do HTTP/2
Alvos do ataque e impacto nos serviços
- A onda recente de ataques começou no fim de agosto de 2023 e continuou sendo observada durante setembro
- Os alvos incluíram grandes provedores de infraestrutura
- Serviços do Google
- Infraestrutura do Google Cloud
- Clientes do Google
- O Google manteve os serviços em operação por meio de balanceamento de carga global e infraestrutura de mitigação de DDoS
- Em colaboração com parceiros do setor, identificou o mecanismo do ataque e coordenou medidas de mitigação para proteger o Google, seus clientes e a internet como um todo
Método de mitigação do Google e proteção para clientes Cloud
- A investigação mostrou que o ataque usava a técnica Rapid Reset, baseada no recurso de multiplexação de streams do amplamente usado protocolo HTTP/2
- O Google mitigou o ataque na borda da rede
- Usou investimentos em capacidade de borda para garantir que os serviços do Google e de clientes, em geral, não fossem afetados
- Depois de entender melhor o método de ataque, desenvolveu mitigações
- Atualizou proxies e sistemas de defesa contra negação de serviço para reduzir essa técnica de forma eficiente
- O Application Load Balancer e o Cloud Armor do Google Cloud usam a mesma infraestrutura de hardware e software que o Google utiliza para oferecer seus próprios serviços voltados para a internet
- Aplicações web e serviços voltados para a internet de clientes Cloud que usam esses serviços também recebem proteção semelhante
CVE-2023-44487 e resposta conjunta do setor
- Logo após detectar os ataques iniciais em agosto, o Google aplicou estratégias adicionais de mitigação e coordenou uma resposta conjunta do setor com provedores de nuvem e mantenedores de software que implementaram stacks do protocolo HTTP/2
- Durante os ataques, informações sobre o ataque e métodos de mitigação foram compartilhados em tempo real
- Essa colaboração resultou em patches e técnicas de mitigação usados por vários grandes provedores de infraestrutura
- O novo método de ataque e potenciais vulnerabilidades em diversos proxies, servidores de aplicação e balanceadores de carga comuns, tanto open source quanto comerciais, foram divulgados em um processo coordenado de divulgação responsável
- A vulnerabilidade coletiva relacionada a esse ataque é rastreada como CVE-2023-44487
- A severidade é High
- A pontuação CVSS é 7.5/10
Quem pode ser afetado e ações necessárias
- Empresas ou indivíduos que oferecem workloads baseados em HTTP na internet podem estar expostos ao risco deste ataque
- Aplicações web, serviços e APIs sobre servidores ou proxies capazes de se comunicar via HTTP/2 podem ser vulneráveis
- As organizações devem verificar se seus servidores com suporte a HTTP/2 não estão vulneráveis
- Se você opera ou gerencia servidores com suporte a HTTP/2, sejam eles open source ou comerciais, deve aplicar os patches relevantes dos fornecedores assim que estiverem disponíveis
- Os patches dos fornecedores para a CVE-2023-44487 são medidas que limitam o impacto desse vetor de ataque
Recomendações de defesa em ambientes Google Cloud
- Defender contra ataques DDoS em grande escala é difícil e, para manter serviços em operação durante ataques de médio porte ou maiores, independentemente da aplicação de patches, é necessário um investimento significativo em infraestrutura
- Organizações que operam serviços no Google Cloud podem usar os investimentos de capacidade em escala global da Cross-Cloud Network para entregar e proteger aplicações
- Clientes do Google Cloud que expõem serviços por meio de Application Load Balancer global ou regional são protegidos pelo Cloud Armor always-on DDoS protection
- Ataques que exploram vulnerabilidades como a CVE-2023-44487 são rapidamente mitigados
- Mesmo que o Cloud Armor always-on DDoS protection consiga absorver a maior parte das centenas de milhões de requisições por segundo na borda da rede do Google, milhões de requisições indesejadas por segundo ainda podem passar
- Para lidar com ataques de Layer 7, recomenda-se implantar custom security policies do Cloud Armor, regras proativas de rate limiting e Adaptive Protection baseado em IA
- Informações técnicas sobre a onda atual de ataques DDoS podem ser encontradas em Análise do ataque DDoS HTTP/2 Rapid Reset
1 comentários
Opiniões do Hacker News
The novel HTTP/2 'Rapid Reset' DDoS attack - https://news.ycombinator.com/item?id=37830987
HTTP/2 Zero-Day Vulnerability Results in Record-Breaking DDoS Attacks - https://news.ycombinator.com/item?id=37830998
Ainda assim, se o resultado é apenas incomodar empresas de tecnologia dos EUA e seus clientes por algumas horas, não entendo muito bem por que isso continua acontecendo.
Com essa reputação, recebem dinheiro de clientes menos limpos que querem atacar concorrentes; às vezes esse cliente é um governo, às vezes é uma empresa suspeita. No ano passado, houve muitos casos de empresas de criptomoedas atacando os sites umas das outras.
As pessoas que fazem esse tipo de coisa costumam ter alto nível técnico, mas, por causa do lugar onde vivem ou do ambiente em que cresceram, muitas vezes têm poucas oportunidades de ganhar dinheiro com essa habilidade.
Se for um atacante avançado, ele está testando capacidade e resposta. O Taliban, no passado, pagava crianças para soltar fogos de artifício fora das bases para verificar táticas, técnicas e procedimentos defensivos, e isso também tinha o efeito de tornar as pessoas menos sensíveis a sons de tiros.
Um adversário realmente bom sabe fazer o segundo parecer o primeiro.
No caso da botnet Mirai, alguns dos criadores também operavam uma empresa de mitigação de DDoS. Ou seja, vendiam a arma de um lado e, do outro, vendiam a defesa contra ela.
Às vezes a motivação também é reputação, brincadeira ou o desafio de criar a própria botnet.
Seja contra infraestrutura de internet em larga escala ou contra uma empresa específica, fico curioso se alguém que já participou desse tipo de ataque seria corajoso ou louco o bastante para criar uma conta temporária e contar suas motivações.
A intenção não era deixar o site-alvo lento, mas eles queriam extrair dados em uma velocidade que tornava o custo de servidor insustentável para um cliente pagante real.
Esse tipo de ataque é diferente de um ataque DDoS real, mas na minha experiência é muito mais comum, e pode ser mitigado com relativa facilidade usando algo como Cloudflare ou Akamai; por isso, costumo recomendar isso aos clientes.
Será que pessoas da Cloudflare, Google e AWS entram em uma videoconferência em tempo real, coordenam entre si e fazem a mitigação, ou cada um observa de longe o que está acontecendo nos outros lugares enquanto se concentra em resolver o próprio problema?
Desta vez, todos perceberam que estavam vendo a mesma coisa e, como o impacto poderia ser muito grande para alvos menores, trabalharam juntos para entender o problema e coordenar a resposta de segurança com todos os fornecedores de servidores web.
Será que é apenas ter largura de banda de entrada suficiente para aguentar alguns Gb/s e ainda deixar capacidade sobrando para o tráfego legítimo?
Grande parte do tráfego DDoS não é HTTP de verdade, mas tráfego lixo que enche o “cano” em direção a um endereço IP. Links maiores e vários servidores distribuídos geograficamente ajudam. Há também casos como floods TCP SYN, que apenas abrem conexões TCP para esgotar as portas disponíveis. Muitas vezes, esse tipo de requisição anormal pode ser tratado por vários proxies reversos simples na frente do servidor
Consultas mais sofisticadas, que aparentemente enviam tráfego HTTP normal, acabam precisando ser processadas. Pode ser respondendo pelo cache, inserindo um CAPTCHA para desacelerar o atacante e identificar o tráfego legítimo, ou aplicando limitação de taxa. A ideia é decidir se a requisição é legítima antes de encaminhá-la ao servidor real, e várias ferramentas podem ser implantadas para isso
O servidor pode ser configurado para descartar tudo que não seja tráfego vindo da Cloudflare, e esse método é eficiente
Em geral, o tráfego interno entre data centers do Google é muito maior do que qualquer volume que alguém consiga enviar como DDoS, então sempre dá para encontrar uma forma de lidar com ele
Mas nem todo DDoS é baseado em capacidade. Alguns abusam de funcionalidades básicas do protocolo, como ataques slow loris
https://www.cloudflare.com/learning/ddos/ddos-attack-tools/s...
Neste caso, poderia ser algo como reconhecer que o cliente está redefinindo streams rapidamente e enviar esse tráfego para uma faixa mais lenta, ou filtrá-lo por completo
https://blog.cloudflare.com/zero-day-rapid-reset-http2-recor...
“Um ponto essencial a observar sobre o ataque recorde é que uma botnet de porte médio, composta por cerca de 20.000 máquinas, esteve envolvida”
Parece que, se todos os grandes provedores fizessem isso, poderiam inserir uma pequena página tipo Turnstile antes do próximo site da Cloudflare que a pessoa visitar
Se houver um dispositivo infectado na minha rede, eu gostaria de saber, e hoje não tenho nenhum monitoramento real para detectar isso. Não é uma solução completa, mas pelo menos avisar o usuário de que há um problema seria um bom começo