Articolo Pubblicazioni

Code Red e Nimda (2001): i worm che resero urgente la gestione delle patch

di · Pubblicato il 15 ottobre 2001

Abstract

Nell’estate del 2001 due worm hanno colpito i server web Microsoft IIS e le reti aziendali di tutto il mondo. Code Red, a luglio, ha sfruttato una vulnerabilità corretta da Microsoft un mese prima. Nimda, a settembre, ha combinato cinque diversi modi di propagazione. L’articolo spiega i due casi e ciò che insegnano sull’aggiornamento dei sistemi e sulla difesa in profondità.

Vincenzo Calabrò | Code Red e Nimda (2001): i worm che resero urgente la gestione delle patch
 

Code Red

Il 18 giugno 2001 Microsoft ha pubblicato il bollettino MS01-033 per una vulnerabilità di tipo buffer overflow nel componente di indicizzazione di Internet Information Services, il server web di Windows. Un mese dopo, il 13 luglio, è comparso un worm che la sfruttava. La versione del 19 luglio si è diffusa con una velocità mai vista. In circa quattordici ore ha infettato oltre 350.000 server. Sui siti in inglese il worm sostituiva la pagina principale con la scritta «Hacked By Chinese!». Era programmato per lanciare, in una fase successiva del mese, un attacco di negazione del servizio contro il sito della Casa Bianca, che ha cambiato il proprio indirizzo per evitarlo.
Il worm viveva solo in memoria e un riavvio lo eliminava, ma i server non aggiornati venivano reinfettati poco dopo. All’inizio di agosto è comparso Code Red II, che sfruttava la stessa vulnerabilità ma installava una backdoor, lasciando ai server un accesso amministrativo remoto per chiunque.

Nimda

Il 18 settembre 2001, una settimana dopo gli attentati di New York, è comparso Nimda, il nome di admin scritto al contrario. La sua caratteristica principale era l’uso combinato di più vie di propagazione:
  1. posta elettronica, con un allegato readme.exe che, a causa di una vulnerabilità di Internet Explorer, poteva essere eseguito alla sola visualizzazione del messaggio;
  2. attacco ai server IIS tramite una vulnerabilità di attraversamento delle directory e tramite le backdoor lasciate da Code Red II;
  3. modifica dei siti web infetti, che servivano ai visitatori un codice capace di infettare i browser non aggiornati;
  4. copia nelle cartelle condivise in rete, con file che si attivavano all’apertura;
  5. creazione di account e condivisioni per mantenere l’accesso.
In poche ore Nimda è diventato il worm più diffuso in circolazione. A differenza di Code Red ha colpito anche le postazioni degli utenti e si è propagato all’interno delle reti aziendali, superando i firewall perimetrali che bloccavano gli accessi dall’esterno.

La lezione sulle patch

Entrambi i worm hanno sfruttato vulnerabilità per cui esisteva già una correzione. I rimedi c’erano. Mancava la rapidità nell’applicarli. Le organizzazioni impiegavano spesso settimane o mesi a installarli, per paura di malfunzionamenti, per mancanza di personale o semplicemente perché non sapevano quali server avessero. Gli amministratori hanno scoperto che una vulnerabilità pubblicata diventa un attacco di massa nel giro di poche settimane, e che quel margine si accorcerà.
Una gestione delle patch efficace richiede alcuni elementi:
  • un inventario dei sistemi e del software installato, compresi i servizi attivati per impostazione predefinita come IIS su molti server Windows;
  • una fonte affidabile e rapida di informazioni sulle vulnerabilità, come i bollettini dei produttori e degli organismi di risposta agli incidenti;
  • una procedura di prova e installazione con tempi definiti, più rapida per le vulnerabilità critiche;
  • la verifica che le correzioni siano davvero installate su tutti i sistemi.

La lezione sulla difesa in profondità

Nimda ha mostrato che un perimetro protetto offre poca difesa quando l’interno è vulnerabile. Una volta entrato da un messaggio di posta o da un portatile collegato alla rete, il worm si diffondeva tra server e postazioni. Servono quindi difese a più livelli, con filtri sulla posta, aggiornamento dei browser e dei client, antivirus sulle postazioni e sui server, disattivazione dei servizi non necessari, condivisioni con permessi limitati e segmentazione della rete.

Come capire se un server è stato colpito

I due worm lasciano tracce riconoscibili, utili a chi deve verificare i propri sistemi:
  • nei log di IIS, Code Red compare come una richiesta al file default.ida seguita da una lunga sequenza di caratteri ripetuti, la lettera N per la prima versione e la lettera X per Code Red II;
  • Code Red II copia l’interprete dei comandi nella cartella degli script del server web con il nome root.exe, e la sua presenza indica una backdoor attiva;
  • Nimda lascia nelle cartelle condivise e nelle directory dei siti file con estensione .eml e .nws e copie di sé con il nome admin.dll, e modifica le pagine web aggiungendo un codice che richiama il file readme.eml;
  • un traffico anomalo in uscita sulla porta 80 da un server che dovrebbe solo ricevere richieste è il segnale più semplice di un’infezione in corso.
Per i server su cui Code Red II o Nimda hanno avuto accesso amministrativo, la scelta più prudente è la reinstallazione completa dal supporto originale, seguita dall’applicazione di tutte le correzioni prima del ricollegamento alla rete. Una semplice pulizia lascia il dubbio che l’attaccante abbia installato altro sfruttando la backdoor.

Il ruolo della comunità

La risposta a Code Red ha visto una collaborazione rapida tra produttori, centri di risposta agli incidenti come il CERT/CC, fornitori di connettività e ricercatori. L’analisi del codice, pubblicata in poche ore da un’azienda di sicurezza, ha permesso di capire che il worm avrebbe attaccato un indirizzo fisso e di predisporre la contromisura. Organismi governativi e privati statunitensi hanno lanciato un appello pubblico congiunto per l’aggiornamento dei server. Questa capacità di cooperazione è stata decisiva e va mantenuta, anche in Italia, con contatti stabili tra chi gestisce reti e servizi.

Disattivare ciò che non serve

Molti server colpiti da Code Red non avevano bisogno di IIS. Era installato e attivo per impostazione predefinita, e i loro amministratori non sapevano nemmeno di gestire un server web. Rimuovere i servizi inutili riduce la superficie d’attacco più di qualsiasi altro intervento. È una regola antica dell’amministrazione dei sistemi, che questi worm hanno reso evidente a tutti.
 
Vedi anche: l’articolo del 2000 ILOVEYOU (2000), l’articolo del 2003 SQL Slammer (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