A Cloudflare foi recentemente contatada por um grupo anônimo de investigadores de segurança que identificaram uma perigosa vulnerabilidade de ampliação de transmissão através das suas pesquisas sobre o protocolo QUIC na Internet. Esta falha, que poderia ser explorada para desencadear ataques devastadores, foi rapidamente abordada pela equipa da Cloudflare, que trabalhou em estreita colaboração com os investigadores através do seu programa público de recompensas por bugs, resultando numa correção eficaz e definitiva da vulnerabilidade.
UMA FALHA QUE PODERIA TER IMPACTO GLOBAL!
Desde o momento em que a vulnerabilidade foi relatada, a Cloudflare tomou medidas implacáveis para garantir a segurança da sua infraestrutura. De acordo com uma análise rigorosa, a falha foi totalmente corrigida e o vetor de ampliação deixou de existir, eliminando qualquer possibilidade de exploração por hackers mal-intencionados.
O QUE ESTAVA EM JOGO? ENTENDA O ATAQUE!
O QUIC é um protocolo de transporte da Internet encriptado por padrão, oferecendo funcionalidades semelhantes ao TCP (Transmission Control Protocol) e ao TLS (Transport Layer Security), mas com uma sequência de estabelecimento de conexão mais curta, reduzindo latências. Este protocolo opera sobre UDP (User Datagram Protocol), o que aumenta a sua velocidade e eficiência.
Os investigadores descobriram que um único pacote QUIC Initial direcionado a um endereço de transmissão poderia gerar uma avalanche de respostas iniciais. Esta situação não apenas sobrecarregava a CPU dos servidores, mas também podia ser explorada para ataques de reflexão e ampliação, tornando-se uma potencial arma de destruição digital.
PORQUE ESTA FALHA ERA TÃO PERIGOSA?
Diferentemente de TCP e TLS, onde existem duas interações de handshake para validar um IP antes da troca de dados, o QUIC permite que um atacante falsifique um endereço IP cliente e induza o servidor a realizar operações criptográficas e a enviar dados a um IP vítima, caracterizando um ataque de reflexão.
O padrão RFC 9000 descreve os riscos desse comportamento e sugere limites anti-ampliação, como restringir as respostas a um máximo de três vezes o tamanho dos pacotes recebidos. Além disso, um servidor pode validar um endereço antes do handshake através do envio de pacotes Retry, mas isso adiciona um atraso na sequência QUIC, tornando-a menos vantajosa comparativamente ao TCP.
COMO O ATAQUE FOI POSSÍVEL? DESCUBRA A FALHA NO BROADCAST!
Em redes IPv4, o endereço final de qualquer sub-rede é reservado como um endereço de transmissão (broadcast), que permite que uma mensagem seja “ouvida” por todos os dispositivos da rede. Essa funcionalidade, essencial para a descoberta de dispositivos, pode ser explorada para ataques de DDoS, pois multiplica o impacto de um pacote enviado.
Routers normalmente bloqueiam pacotes vindos de fora da sub-rede para endereços de broadcast locais. No entanto, quando um endereço de broadcast não é tratado localmente como tal, protocolos como BGP (Border Gateway Protocol) continuam a encaminhar tráfego externo até ele. Isto significa que um endereço de broadcast pode comportar-se como um IP normal na Internet, permitindo ataques massivos.
COMO A CLOUDFLARE DETETOU O PROBLEMA?
A Cloudflare utiliza Anycast, o que significa que cada servidor da rede pode servir conteúdo de qualquer site alojado na plataforma. Para isso, os servidores precisam de escutar todos os endereços Anycast atribuídos, utilizando a interface loopback.
Aqui está um exemplo do que foi encontrado na tabela de roteamento local da Cloudflare:
$ ip route show table local
local 10.0.0.0/8 dev lo proto kernel scope host src 10.0.0.1
local 10.0.0.1 dev lo proto kernel scope host src 10.0.0.1
broadcast 10.255.255.255 dev lo proto kernel scope link src 10.0.0.1
local 192.168.1.2 dev eth1 proto kernel scope host src 192.168.1.2
broadcast 192.168.1.255 dev eth1 proto kernel scope link src 192.168.1.2
local 172.16.0.0 dev lo proto kernel scope host src 172.16.0.0
local 172.16.0.0/24 dev lo proto kernel scope host src 172.16.0.0
broadcast 172.16.0.255 dev lo proto kernel scope link src 172.16.0.0O problema? O prefixo anycast 172.16.0.0/24 estava vinculado à interface loopback, o que significava que o endereço final da gama era tratado como um endereço de broadcast, causando a explosão de respostas QUIC quando explorado!
A SOLUÇÃO RÁPIDA E EFICAZ DA CLOUDFLARE!
A forma mais simples de corrigir este problema era desativar a funcionalidade de broadcast para o último endereço de cada gama.
Para isso, foi removida a rota de broadcast com um simples comando:
$ sudo ip route del 172.16.0.255 table localE para garantir que esta remoção acontecesse em todos os servidores, foi implementada a seguinte lógica no sistema de implementação da Cloudflare:
{%- for lo_route in lo_routes %}
{%- if lo_route.type == "broadcast" %}
{%- do remove_route({
"dev": "lo",
"dst": lo_route.dst,
"type": "broadcast",
"src": lo_route.src,
}) %}
{%- endif %}
{%- endfor %}O QUE SIGNIFICA ISTO PARA A SEGURANÇA DA INTERNET?
Esta vulnerabilidade pode afetar outras infraestruturas que utilizem serviços UDP multiworker em redes com prefíxos roteáveis. Administradores de redes e profissionais de segurança devem rever as suas configurações para evitar ataques semelhantes.
A Cloudflare reafirma o seu compromisso com a segurança digital, garantindo que as suas inovações continuem a proteger milhões de utilizadores pelo mundo!
