SQL Slammer: o worm de 376 bytes que parou a internet em 2003

No sábado, 25 de janeiro de 2003, pouco antes das 5h30 UTC, um pacote minúsculo começou a circular pela internet. Dez minutos depois, a maior parte dos servidores vulneráveis do planeta já estava infectada e links inteiros estavam saturados. O SQL Slammer (também chamado Sapphire) cabia em apenas 376 bytes, menos que este parágrafo, e ainda hoje é o exemplo clássico de quão rápido um worm pode andar.

Qual era a falha explorada pelo Slammer

O alvo era o Microsoft SQL Server 2000 e o MSDE (a versão embutida em vários aplicativos). Esses programas escutam a porta UDP 1434 para o chamado SQL Server Resolution Service, que ajuda clientes a descobrir instâncias na rede. Uma falha de buffer overflow nesse serviço permitia executar código enviando uma única mensagem malformada.

A falha foi corrigida pelo boletim MS02-039 (CVE-2002-0649), cerca de seis meses antes do worm. O código de prova de conceito havia sido mostrado por David Litchfield, o pesquisador que descobriu o problema, em uma apresentação na Black Hat. Ou seja: correção pública, exploração conhecida, e muita gente sem aplicar.

O que é o SQL Slammer?

O SQL Slammer é um worm que explorava o buffer overflow do SQL Server (MS02-039) e se espalhava por um único pacote UDP de 376 bytes, sem arquivo, sem anexo e sem clique de ninguém. Não tem relação com SQL Injection, que é uma falha em aplicações web. Aqui o ataque era direto contra o serviço do banco de dados.

Por que ele foi tão rápido?

Dois detalhes de projeto explicam a velocidade, segundo o estudo "The Spread of the Sapphire/Slammer Worm", publicado pelo CAIDA:

• UDP, sem conexão. Não existe handshake para esperar. O worm "atira e esquece": cada máquina infectada dispara cópias para endereços IP aleatórios o mais rápido que a placa de rede permitir.
• Tudo em um pacote. Como o código cabia numa mensagem só (404 bytes no total com os cabeçalhos), o limite não era a latência, e sim a largura de banda do link da vítima.

O resultado, ainda segundo o CAIDA: a população de infectados dobrava a cada 8,5 segundos no primeiro minuto, o pico passou de 55 milhões de varreduras por segundo em menos de 3 minutos, e mais de 90% dos hosts vulneráveis foram atingidos em cerca de 10 minutos. O estudo contou pelo menos 74.856 endereços IP distintos infectados, e o próprio texto avisa que é um piso, não um total.

Quais foram os efeitos do Slammer?

Ele não destruía dados: o estrago veio do volume de tráfego, que saturou links, derrubou servidores de banco de dados e afetou serviços que dependiam deles. O CAIDA cita voos cancelados, interferência em eleições e falhas em caixas eletrônicos entre as consequências relatadas, além de sites que perderam conectividade por causa da banda esgotada. Como o worm vivia só na memória e não gravava nada em disco, reiniciar o serviço o removia, mas a reinfecção vinha em segundos se a máquina continuasse exposta e sem patch.

O que dá para aprender e aplicar hoje

O Slammer repete o roteiro de outros casos que já contamos aqui: o Conficker e o Sasser, ambos explorando falha com patch disponível. Ações práticas:

• Nunca deixe banco de dados exposto à internet. A porta 1434 UDP (e a 1433 TCP) nunca deveria estar acessível de fora. Se precisa de acesso remoto, use VPN ou lista de IPs permitidos.
• Filtre por padrão. Um firewall que só libera o necessário teria barrado o worm na borda. No Ubuntu, o UFW em 5 passos mostra a lógica de "nega tudo, libera o que precisa".
• Tenha inventário. Muita gente nem sabia que tinha MSDE rodando, embutido em outro software. O que você não sabe que existe, você não atualiza.
• Aplique patch com prazo definido, principalmente em falha de execução remota sem autenticação.
• Segmente a rede para que uma máquina infectada não alcance todo o resto.

A lição maior

Em 1988, o Morris Worm mostrou que a internet podia ser derrubada por código que se copia sozinho. Em 2003, o Slammer mostrou que a janela de resposta tinha encolhido de dias para minutos: nenhum humano reage a tempo a um worm assim. A defesa precisa estar pronta antes, com patch, filtragem e inventário. Se quiser ver essa lógica no limite, leia sobre o WannaCry, que repetiu o padrão em 2017.

Fontes: CAIDA ("The Spread of the Sapphire/Slammer Worm", David Moore et al.), Wikipedia (SQL Slammer), F-Secure e boletim MS02-039 da Microsoft.