Morris Worm — Quando il verme imparò a camminare sulla rete

Nel primo mattino di novembre 1988 la rete era ancora un luogo giovane: universitario, curiosamente aperto, connesso da cavi e fatica intellettuale. Non c’erano botnet industriali né mercati sotterranei per gli exploit; c’erano ricercatori, studenti, pochi amministratori di sistema che si scambiavano floppy e consigli di buon senso.

Eppure, in quel contesto fresco e ingenuo, qualcosa — un piccolo frammento di codice — decise di comportarsi come un organismo vivente: si replicò, esplorò, imparò a usare i suoi simili per propagarsi. Non era progettato per distruggere: voleva misurare la rete. Per sbaglio o per ardore, paralizzò università e centri di ricerca, segnando la nascita della sicurezza informatica e rendendolo un problema pubblico.

Questo è il Morris Worm: il verme che conosceva troppa curiosità.

BUG ARCHEOLOGY — EPISODIO 18

“Computer viruses are an urban legend in the making.”
— Peter Norton (sì, proprio quello dei Norton Utilities — frase risalente ai primissimi anni ‘90)

👶Introduzione per chi parte da zero

Negli anni ’80 il concetto di “Internet” come lo intendiamo oggi era una comunità accademica interconnessa e si faceva chiamare ARPANET. I computer parlavano tra loro per condividere risorse: file, tempo macchina, messaggi. Ogni macchina era un punto di servizio, spesso gestito da un universitario o da un gruppo di ricerca.

Un “worm” è un software che si copia da un computer a un altro senza bisogno che l’utente lo installi. Diverso da un “virus” (che infetta file) e diverso da un “trojan” (che si maschera da qualcosa di utile), il worm sfrutta fallimenti nei servizi di rete per spostarsi. Il Morris Worm, scoperto il 2 novembre 1988, fu uno dei primi esempi di worm che si diffuse su Internet su scala ampia — e con conseguenze che cambiarono procedure, leggi e organizzazione della sicurezza.

I. Il sintomo: la rete che rallenta fino a fermarsi

La mattina del 2 novembre molte macchine universitarie cominciarono a comportarsi in modo anomalo: risposte lente, processi che si moltiplicavano, servizi che cadevano. Gli amministratori vedevano CPU al 100%, code di processi inutilmente lunghe, e connessioni che si ripetevano come un eco.

In alcuni casi la macchina sembrava occupata a “telefonare” ad altre: connessioni in uscita ripetute, tentativi di login automatici. Non c’era uno schermo con scritto “sono un worm”: il comportamento era osservabile ma non immediatamente interpretabile.

Il risultato pratico fu un degrado delle risorse: sistemi accademici non rispondevano, terminali remoti diventavano inutilizzabili, e chi doveva lavorare non poteva farlo. Per molte università fu come avere una biblioteca chiusa per giorni.

II. L’autore e l’intenzione: Robert Tappan Morris (e la curiosità)

Dietro il codice c’era un nome: Robert Tappan Morris, studente di dottorato al MIT. Le sue intenzioni, stando a quanto dichiarato in seguito, non erano malevole. L’esperimento voleva stimare le dimensioni di Internet: quanti host erano connessi? Per farlo, Morris scrisse un programma in grado di replicarsi e di inviare copie di sé a macchine remote via alcuni servizi noti.

Quello che non prese completamente in considerazione furono gli effetti collaterali: la replica non aveva abbastanza controllo sulle istanze già presenti e alcune macchine eseguivano il codice più volte, causando un ciclo di replicazione incontrollato. L’effetto fu più simile a un incendio accidentale che a un attacco deliberato.

III. Il meccanismo: come si propagava il Morris Worm

Il Morris Worm sfruttava più vettori — una tecnica che gli permetteva di muoversi velocemente:

• Vulnerabilità di fingerd: fingerd era un demone che rispondeva a richieste “finger”. Il worm inviava input appositamente costruiti per eseguire shellcode remota su macchine con implementazioni vulnerabili.
• Debolezze di rlogin/rcp: tentativi di accesso sfruttando account con password deboli o assenti; il worm provava credenziali comuni e le chiavi per ottenere accesso.
• Bug nei servizi di suddivisione dei file: alcune versioni di sendmail e altri demoni presentavano possibilità di esecuzione di comandi remoti via exploit.

Combinando questi vettori e includendo una routine di replica che non verificava correttamente l’esistenza di esempi già presenti, il worm generava molteplici copie di sé sulla stessa macchina e saturava risorse. Era un comportamento combinatorio: più attacchi contemporanei, più ripetizioni, più consumo di CPU/memoria.

IV. Il contesto tecnico-sociale: una rete senza controllo

Nel 1988 non esistevano policy centralizzate per la gestione della sicurezza: amministratori diversi, equipaggiamenti eterogenei, scarsa visibilità su quali software fossero in esecuzione. Inoltre, molte macchine condividevano account e risorse.

Questa mancanza di governance rese la rete particolarmente fragile. Il codice si infiltra dove trova una superficie d’attacco; se la superficie è grande e poco monitorata, la replicazione diventa esponenziale. Infine, la comunità scarsamente instradata sulla gestione degli incidenti non era pronta a una risposta coordinata.

V. La scoperta e la reazione: dal panico alla costruzione di istituzioni

Quando il worm fu identificato come la causa, la risposta fu rapida — ma disordinata:

• Amministratori scolpirono soluzioni locali: reboot, kill di processi, rimozione manuale dei file del worm.
• Alcuni host furono isolati dalla rete per fermare la propagazione.
• La scala dell’incidente richiese cooperazione: università e centri di ricerca cominciarono a condividere informazioni per individuare firme del worm e procedure di rimozione.

Una delle conseguenze più durature fu la consapevolezza istituzionale: nacque la Computer Emergency Response Team (CERT), il primo centro di risposta agli incidenti coordinato (originariamente creato in risposta a questo episodio). La nascita del CERT segna un passaggio dalla gestione reattiva a un approccio organizzato alla sicurezza.

VI. Le implicazioni legali e morali

Robert Morris fu processato e, nel 1990, condannato: multato, con obbligo di servizio comunitario e condanna penale. Per la prima volta la legge si confrontò con un incidente informatico su scala decente: bisognava definire responsabilità, intenzioni e danni.

La vicenda aprì un dibattito etico: fino a che punto esperimenti di misurazione della rete sono accettabili? Quando la ricerca diventa pratica pericolosa? La questione non è solo storica: oggi gli esperimenti su reti e dispositivi distribuiti continuano a porre lo stesso problema, con implicazioni più ampie per privacy e infrastrutture critiche.

VII. I danni: misurare l’impossibile

Il Morris Worm non fu progettato per rubare dati o distruggere; però i costi furono concreti:

• Sistemi paralizzati in università e centri di ricerca per ore/giorni.
• Ore-uomo spese per recovery e analisi.
• Costi indiretti per perdita di produttività e progetti ritardati.
• La nuova necessità di investire in formazione, controlli e istituzioni.

La stima dei danni monetari è difficoltosa in retrospettiva, ma l’impatto culturale fu enorme: la sicurezza divenne una priorità tecnica e organizzativa.

VIII. Contromisure: cosa è cambiato (e cosa serve ancora)

Le lezioni pratiche emerse dal Morris Worm sono ancora valide:

Tecniche immediate e storiche:

• Patch e aggiornamenti: correggere vulnerabilità note evita vettori di replica.
• Gestione delle password: eliminare account con password deboli; usare autenticazione forte.
• Rate limiting e controllo dei processi: limitare la capacità di un singolo servizio di generare carico esplosivo.

Strategiche e organizzative:

• Inventario e visibilità: conoscere quali servizi girano su ogni host.
• Incident response: team dedicati, playbook e comunicazione coordinata.
• Normativa e responsabilità di ricerca: regole etiche per esperimenti che coinvolgono infrastrutture condivise.

IX. Le lezioni filosofiche: curiosità, responsabilità e la rete come bene condiviso

Il Morris Worm è una storia doppia: da una parte la stupenda curiosità scientifica — capire quanto grande fosse il nuovo mondo connesso — dall’altra la necessità di governare la curiosità stessa quando essa impatta comunità altrui.

Tre lezioni rimangono:

• La curiosità senza confini può nuocere: esperimenti distribuiti richiedono consenso o almeno mitigazioni preventive.
• La resilienza si costruisce prima: procedure, strumenti, e cultura contano più delle soluzioni d’urgenza.
• La rete è infrastruttura sociale: non è solo tecnologia; è un sistema di persone, istituzioni e pratiche che richiede fiducia e regole condivise.

X. Epilogo: archeologia di un verme che insegnò la prudenza

Il Morris Worm camminò, si riprodusse, si arrese alla concretizzazione delle regole. Oggi, mentre i malware si industrializzano e le supply chain si intrecciano come vasi di un’antica città, la storia del verme rimane un monito: dietro ogni riga di codice ci sono conseguenze reali.

Non demonizziamo la ricerca, ma non la lasciamo neppure senza freni. L’archeologo del bug scava per capire, non per condannare; trova tracce, ricostruisce comportamenti, e insegna come non ripetere gli stessi errori.

🧰 Bug Survival Kit – Morris Worm Edition

Cose da leggere, strumenti e pratiche per chi vuole scavare senza farsi sorprendere.

📚 Libri consigliati

• The Cuckoo’s Egg — Clifford Stoll (edizione inglese)
  Racconto personale da detective informatico: storia che ha formato intere generazioni su detection e risposta.
• Confessioni di un eretico high-tech – Clifford Stoll
  Il testo esplora le sue critiche all’uso indiscriminato della tecnologia nelle scuole, sostenendo l’importanza del contatto umano nell’insegnamento. È disponibile anche in formato digitale.
• Computer Security: Art and Science — Matt Bishop (edizione inglese)
  Un testo solido per comprendere principi e modelli di sicurezza.
• Cybersecurity and Cyberwar: What Everyone Needs to Know — P. W. Singer & Allan Friedman (edizione inglese)
  Buona panoramica storica e politica del dominio.

🔧 Tool utili (per la ricerca e la sopravvivenza)

• tcpdump / Wireshark — per catturare e analizzare traffico di rete.
• top/htop, ps — per monitorare processi e carichi CPU.
• tripwire / osquery — per integrità dei file e inventario degli asset.
• git — per versionare codice e annotare esperimenti (senza mai testare exploit su sistemi non autorizzati).

📜 Pratiche etiche

• Non testare exploit su infrastrutture pubbliche senza consenso.
• Predisporre ambienti isolati (sandbox, lab) per esperimenti.
• Documentare e condividere risultati con la comunità in modo responsabile.

📘 Glossario essenziale

ARPANET
La prima rete di computer collegati tra loro, l’antenato di Internet, creata negli anni ’60 e ’70.

Worm (verme informatico)
Un programma cattivo che si copia da solo e si diffonde tra i computer senza che nessuno lo fermi.

Exploit
Un trucco usato per far funzionare un programma in modo sbagliato e prendere il controllo di un computer.

Buffer Overflow
Un errore che succede quando un programma riceve più informazioni di quante ne possa gestire, causando problemi o aprendo una porta agli attacchi.

Remote Code Execution (RCE)
Quando un hacker riesce a far eseguire al computer cose che vuole lui, anche se è lontano.

CERT (Computer Emergency Response Team)
Un gruppo di esperti che aiutano a risolvere problemi di sicurezza sui computer quando succede qualcosa di brutto.

Backdoor
Una porta nascosta che permette agli hacker di entrare in un computer senza farsi vedere.

Payload
La parte del virus o worm che fa il vero danno, come cancellare file o rubare dati.

Phreaking
Un modo per “hackerare” i telefoni e usarli gratis o per altri scopi non autorizzati.