Articolo Pubblicazioni

SQL Slammer (2003): il worm che si diffuse in dieci minuti e la lezione sulle patch

di · Pubblicato il 24 febbraio 2003

Abstract

Il 25 gennaio 2003 un worm chiamato SQL Slammer ha infettato in pochi minuti decine di migliaia di server con Microsoft SQL Server 2000 o con il motore MSDE incluso in molti prodotti. La sua diffusione ha saturato reti in tutto il mondo, con effetti su bancomat, voli e servizi di emergenza. L’articolo spiega il meccanismo e le lezioni pratiche del caso.

Vincenzo Calabrò | SQL Slammer (2003): il worm che si diffuse in dieci minuti e la lezione sulle patch
 

Che cosa è successo

Sabato 25 gennaio 2003, poco dopo le 5.30 del mattino ora di Greenwich, un worm ha iniziato a diffondersi su Internet a una velocità senza precedenti. Secondo le analisi dei ricercatori, il numero di sistemi infetti raddoppiava ogni otto secondi e mezzo nei primi minuti. In circa dieci minuti è stato infettato il 90 per cento dei sistemi vulnerabili raggiungibili, stimati in circa 75.000. Il traffico generato ha saturato collegamenti e apparati di rete in molti paesi.

Il meccanismo

Il worm sfruttava una vulnerabilità di tipo buffer overflow nel servizio di risoluzione di Microsoft SQL Server 2000, in ascolto sulla porta UDP 1434. Microsoft l’aveva corretta nel luglio 2002 con il bollettino MS02-039. Il codice del worm stava in un solo pacchetto UDP di 376 byte. Non scriveva nulla sul disco. Una volta in memoria, generava indirizzi casuali e inviava lo stesso pacchetto il più velocemente possibile.
L’uso di UDP spiega la velocità. Un worm che usa TCP deve aprire una connessione con ogni bersaglio e attendere la risposta. Slammer inviava il pacchetto e passava subito al successivo, limitato solo dalla capacità della rete. Il traffico prodotto da pochi server infetti bastava a saturare la connessione di un’intera azienda.

Gli effetti

Il worm lasciava intatti i dati e non installava backdoor. Il traffico prodotto ha avuto comunque conseguenze rilevanti:
  • migliaia di bancomat di una grande banca statunitense sono rimasti fuori servizio;
  • alcune compagnie aeree hanno dovuto cancellare o ritardare voli per il blocco dei sistemi di prenotazione e di check-in;
  • in alcune aree degli Stati Uniti i servizi di emergenza hanno avuto problemi nella gestione delle chiamate;
  • in Corea del Sud l’accesso a Internet è stato interrotto per gran parte della popolazione per alcune ore;
  • molte reti aziendali sono rimaste bloccate finché i server infetti non sono stati isolati.

Il problema dei componenti incorporati

Molti amministratori non sapevano di avere SQL Server in rete. Il motore MSDE, una versione ridotta del database, era incluso in numerosi prodotti di Microsoft e di terze parti, come strumenti di sviluppo, applicazioni gestionali e software di amministrazione. Chi aveva installato quei prodotti aveva anche il servizio vulnerabile, senza esserne consapevole. Inoltre la correzione di luglio era difficile da applicare e alcuni aggiornamenti successivi la annullavano.

Le lezioni

Il caso conferma la lezione di Code Red e Nimda e la rende ancora più urgente:
  1. il tempo tra la pubblicazione di una vulnerabilità e un attacco di massa può essere breve, e l’attacco può completarsi in minuti, prima che qualsiasi intervento manuale sia possibile;
  2. l’inventario del software deve comprendere i componenti incorporati nei prodotti, oltre alle applicazioni principali;
  3. i servizi di database non devono essere raggiungibili da Internet, e i firewall dovrebbero bloccare in ingresso e in uscita le porte non necessarie, compresa la UDP 1434;
  4. il filtraggio del traffico in uscita limita i danni che un sistema infetto può causare ad altri;
  5. le correzioni devono essere facili da applicare e verificare, e i produttori hanno la responsabilità di renderle tali.

Prevedere l’imprevedibile

Slammer è stato fermato più dalla saturazione delle reti che da interventi umani. Nessun amministratore ha avuto il tempo di reagire durante i dieci minuti decisivi. Questo cambia il modo di pensare la difesa. Le misure che contano sono quelle già attive prima dell’attacco, cioè sistemi aggiornati, servizi non esposti, regole di filtraggio restrittive e segmentazione della rete. La risposta agli incidenti resta necessaria per isolare i sistemi infetti, ripulirli e ripristinare il servizio, ed è impotente contro la diffusione iniziale di un worm così rapido. Le organizzazioni dovrebbero inoltre prevedere procedure per operare quando la rete è saturata, con canali di comunicazione alternativi tra i tecnici.

Che cosa fare subito

Per chi gestisce una rete aziendale le verifiche da fare dopo l’attacco sono poche e concrete:
  • cercare in rete tutti i sistemi che rispondono sulla porta UDP 1434, compresi quelli che nessuno ricorda di aver installato;
  • aggiornare SQL Server 2000 e MSDE con il Service Pack 3, che include la correzione, o con la patch specifica, verificando dopo l’installazione che la versione risulti aggiornata;
  • bloccare sul firewall perimetrale le porte UDP 1434 e TCP 1433 in entrambe le direzioni, salvo necessità documentate;
  • chiedere ai fornitori di software gestionale se i loro prodotti includono MSDE e come va aggiornato;
  • riavviare i sistemi infetti dopo averli isolati, perché il worm risiede solo in memoria, e applicare la correzione prima di ricollegarli.
L’ultimo punto ha una conseguenza pratica. Un server ripulito con il riavvio ma ancora vulnerabile viene reinfettato in pochi secondi, se resta raggiungibile da un sistema infetto.

Il filtraggio in uscita

Molte organizzazioni controllano con cura ciò che entra nella propria rete e lasciano uscire tutto. Slammer mostra il costo di questa scelta. Una regola che consente al traffico verso la porta 1434 di uscire solo dai sistemi che ne hanno bisogno avrebbe impedito ai server infetti di saturare la connessione e di colpire altri. Lo stesso vale per altri protocolli usati dai worm per diffondersi. Il filtraggio in uscita è anche una forma di responsabilità verso il resto della rete.
 
Vedi anche: l’articolo del 2001 Code Red e Nimda (2001), l’articolo del 2003 OWASP Top 10 (2003) e l’articolo del 2017 WannaCry e NotPetya (2017).
 
Vincenzo Calabrò | Ingegnere informatico specializzato in sicurezza informatica e investigazioni digitali. Funzionario informatico del Ministero dell'Interno; su incarico autorizzato si occupa di sicurezza informatica e di perizie informatiche forensi. Autore di articoli e saggi. Lecturer, Speaker, Trainer.
Profili: Google Scholar · ORCID · ResearchGate · Academia.edu · CyberSecurity360 · AgendaDigitale · ICT Security Magazine · LinkedIn