Resumo

  • A Microsoft publicou em julho de 2002 uma correção para o serviço de resolução do SQL Server 2000; mesmo assim, o Slammer encontrou em janeiro de 2003 uma população exposta e infectou mais de 90% dos hosts vulneráveis alcançáveis em dez minutos, segundo a CAIDA.
  • O episódio mostrou que adoção não pertence a uma autoridade única: o fabricante corrige, distribuidores revelam cópias incorporadas do MSDE, donos de aplicações mudam processos em execução e operadores de rede preparam contenção limitada para agir antes de uma aprovação humana.

O que aconteceu seis meses antes

O Security Bulletin MS02-039 foi publicado pela Microsoft em 24 de julho de 2002. O SQL Server 2000 Resolution Service usava a porta UDP 1434 para informar aos clientes onde encontrar instâncias nomeadas de banco de dados. Duas funções não limitavam corretamente a entrada. Um pedido preparado podia ultrapassar um buffer de pilha e executar código com as permissões da conta do serviço SQL Server.

O alcance incluía SQL Server 2000 e Microsoft Desktop Engine 2000. O boletim oferecia patch, versão de arquivo para conferência e uma mitigação clara: bloquear UDP 1434 quando o serviço não fosse necessário. O patch cumulativo do MS02-061, publicado em 16 de outubro, também continha a correção.

Essa linha do tempo prova que a Microsoft produziu uma resposta. Não prova que uma instalação independente a adotou. O fabricante não escolhia a janela de manutenção do cliente, não sabia onde cada produto de terceiros havia embutido o MSDE e não conseguia obrigar um processo remoto a carregar os novos bytes. Em todo servidor no qual a versão antiga continuava ativa e acessível, era ela que exercia autoridade.

Running-Code Primacy evita a confusão. O documento define uma possibilidade corrigida. O processo carregado revela a realidade.

Um datagrama eliminou o tempo de espera

O Slammer, também chamado Sapphire, começou a se espalhar pouco antes das 05h30 UTC de sábado, 25 de janeiro de 2003. Seu corpo tinha 376 bytes. Com os cabeçalhos, a CAIDA descreve um pacote UDP/IP de 404 bytes. Ao atingir o serviço vulnerável, o pacote explorava o estouro e fazia o novo host enviar o mesmo corpo a endereços pseudoaleatórios na porta UDP 1434.

Não havia conexão a abrir nem resposta a aguardar. Um scanner em TCP perde tempo com sessões e timeouts. A rotina do Slammer seguia transmitindo, limitada sobretudo pela capacidade de saída do computador comprometido e de seu acesso à Internet.

A CAIDA observou diretamente cerca de 26 mil sondas por segundo em uma máquina e estimou média inicial de aproximadamente 4 mil por instância infectada. Perto do terceiro minuto, a taxa agregada passou de 55 milhões de sondas por segundo. Em dez minutos, mais de 90% dos hosts vulneráveis alcançáveis haviam sido infectados.

Os 74.856 endereços infectados distintos vistos nos primeiros 30 minutos são um limite inferior. Defeitos no gerador pseudoaleatório tornavam ciclos inteiros invisíveis para certos pontos de observação, e um registro importante foi interrompido depois de cerca de dois minutos e quarenta segundos. Não existe base para um total global exato. Existe base para afirmar que a fase decisiva terminou antes do rito normal de detecção, reunião, autorização e mudança.

O tráfego saía de dentro

Slammer não era reflexão de memcached. Não falsificava o endereço de uma vítima para induzir terceiros a enviar respostas maiores. Cada SQL Server comprometido originava suas próprias sondas. A variante analisada não carregava outra carga destrutiva; o envio agressivo já produzia indisponibilidade.

Em muitos locais, uma ou poucas máquinas ocupavam o primeiro gargalo compartilhado. Sistemas não vulneráveis perdiam conectividade porque dividiam o mesmo enlace. Volume, taxa de pacotes pequenos e grande variação de destinos pressionavam banda, filas, memória e CPU de equipamentos. As próprias infecções passaram a disputar capacidade entre si.

Uma política pensada apenas para impedir a entrada do atacante fica incompleta. Um runtime interno esquecido consegue consumir toda a saída da organização. Os primeiros controles úteis ficam perto do proprietário da rede: segmentação, observação de fluxo de saída, filas justas, limite de taxa e isolamento seletivo. Um serviço externo de limpeza não devolve a capacidade do primeiro enlace local já saturado.

MSDE chegava com outro nome

O MSDE 2000 podia ser instalado como motor de banco de dados de um produto maior. Uma empresa que não reconhecia “SQL Server” no inventário podia manter o Resolution Service em execução por causa de outra aplicação. O CERT/CC destacou que produtos contendo MSDE 2000 também eram afetados.

O conhecimento estava fragmentado. A Microsoft conhecia o componente. O distribuidor conhecia o pacote. O dono da aplicação conhecia a função de negócio. A equipe de rede enxergava UDP 1434. Nenhuma lista isolada respondia se o código vulnerável estava ativo.

O objeto da correção deve ser a identidade executável: processo que escuta, arquivo carregado, versão, produto instalador, responsável, clientes autorizados e caminhos de rede. Marcar um chamado como concluído não substitui essa reconciliação.

A republicação do MS02-061 acrescenta uma restrição operacional real. A Microsoft integrou uma correção adicional não relacionada à segurança e um novo instalador depois que a combinação original podia interferir em certas operações do SQL Server. Isso não torna aceitável a exposição. Mostra por que quem arca com a continuidade precisa testar a mudança, programá-la e confirmar o comportamento resultante.

O filtro ajudou depois que a corrida acabou

Segundo a CAIDA, muitos sites começaram a filtrar destino UDP 1434 dentro de uma hora. O caso facilitava a ação: assinatura clara, porta específica e pouco tráfego legítimo de Internet em várias redes. Mesmo nessas condições, o primeiro filtro humano apareceu depois que quase toda a população suscetível já estava infectada.

Filtrar continuou importante para reduzir varredura e recuperar conectividade. Não removeu a infecção e não necessariamente impediu propagação entre segmentos internos. A orientação da Cisco diferenciava ACLs em roteadores de controles capazes de atuar dentro de VLANs, além de reconhecer organizações que precisavam legitimamente da porta.

Automação útil não é autorização genérica. Uma política local pode agir quando uma assinatura precisa, a expansão súbita de destinos e uma taxa incompatível com a função do host aparecem juntas. Pode limitar temporariamente, colocar em quarentena ou mover o endpoint para um caminho restrito. Limiares, escopo, exceções, duração, evidência e reversão continuam sob decisão do operador.

A especificação mínima comum pede resultados estreitos: identificar o runtime afetado, remover alcance sem justificativa e impedir que um nó monopolize recurso compartilhado. Cada rede escolhe seus mecanismos.

A adoção produz quatro recibos

O fabricante entrega versão corrigida identificável e método viável de instalação. O distribuidor liga o componente embutido ao produto e ao cliente. O dono da aplicação demonstra versão carregada, dependência e exposição. O operador de rede demonstra em fluxo e exercício que um endpoint não toma o enlace inteiro.

Nenhum recibo quita o outro. Firewall esconde código vulnerável sem corrigi-lo. Patch não justifica serviço público desnecessário. Inventário envelhece. Quarentena ampla demais pode ser impossível de usar durante uma crise.

Essa divisão não exige que a Microsoft governe as redes dos clientes ou que operadores reescrevam o banco de dados. Cada ator expõe estado suficiente para a decisão seguinte, e o direito de executar permanece com quem suporta a interrupção e a recuperação.

Limites da evidência

As fontes sustentam um patch anterior, um worm em um único datagrama, pelo menos 74.856 endereços observados e uma fase crítica em minutos. Não mostram que toda instalação SQL Server ou MSDE estava exposta, que o limite inferior era o total mundial ou que cada interrupção noticiada seguiu a mesma cadeia.

Também não sustentam falsificação de origem, reflexão, roubo de dados ou payload destrutivo adicional na variante observada. A conclusão confiável é menor: patch publicado não retira autoridade do binário antigo que continua rodando. Quando propagação vence a permissão humana, poderes automáticos limitados precisam ser definidos antes e comprovados por versões, sockets, fluxos e exercícios.

Fontes