Stuxnet: quando un malware sabotò un programma nucleare
Introduzione
Nell’estate del 2010, i tecnici dell’impianto di arricchimento dell’uranio di Natanz, in Iran, stavano affrontando un problema inspiegabile. Le centrifughe si rompevano. Non tutte insieme — sarebbe stato ovvio. Si rompevano lentamente, una alla volta, in modo casuale, come se avessero difetti di fabbricazione. I tecnici sostituivano i componenti, cercavano spiegazioni nei materiali, nei processi, nelle procedure operative. I monitor mostravano tutto nella norma. Gli strumenti di diagnostica non segnalavano nulla.
Nel frattempo, su un server a migliaia di chilometri di distanza, un malware stava registrando pazientemente i dati normali delle centrifughe da usare come copertura mentre inviava comandi che le distruggevano dall’interno.
Si chiamava Stuxnet, ed era qualcosa che il mondo non aveva mai visto.
Il bersaglio: il programma nucleare iraniano
Per capire Stuxnet bisogna capire il contesto geopolitico. Dal 2002, quando un gruppo di opposizione iraniano rivelò l’esistenza di impianti nucleari segreti, il programma nucleare dell’Iran era al centro delle preoccupazioni internazionali. Gli USA e Israele temevano che l’Iran stesse sviluppando armi nucleari sotto copertura di un programma civile.
L’impianto di Natanz, nel centro dell’Iran, era il cuore del programma di arricchimento. Conteneva migliaia di centrifughe IR-1 — macchine cilindriche alte circa due metri che giravano a 1.064 Hz (oltre 60.000 RPM) per separare l’isotopo U-235 dall’U-238 tramite la forza centrifuga. L’uranio arricchito era necessario sia per i reattori nucleari civili che — a livelli di arricchimento più alti — per le armi.
Il problema strategico per chi voleva fermare il programma: come si sabotano le centrifughe di un impianto che non è connesso a internet?
L’air gap: il problema da risolvere
Natanz era progettato assumendo che l’isolamento fisico fosse la difesa definitiva. La rete interna era completamente separata da internet — quello che i professionisti della sicurezza chiamano air gap. Nessuna connessione esterna, nessun accesso remoto. Per entrare fisicamente nel sistema, avresti dovuto essere fisicamente presente nell’impianto.
Stuxnet risolse questo problema in modo che sembrava impossibile fino al momento in cui fu scoperto.
Il vettore di infezione: le chiavette USB
La soluzione era elegante nella sua semplicità: se il sistema non poteva essere raggiunto via rete, si infettavano le persone che ci lavoravano.
Stuxnet si diffondeva tramite chiavette USB sfruttando una vulnerabilità zero-day in Windows — la CVE-2010-2568 — che permetteva l’esecuzione automatica di codice all’inserimento di una USB, senza che l’utente aprisse alcun file, senza che cliccasse su nulla. Bastava inserire la chiavetta in un computer Windows e il malware si installava silenziosamente.
La strategia era quella dell’supply chain infection: infettare le aziende che fornivano attrezzature e servizi all’impianto di Natanz. Un tecnico di manutenzione, un fornitore di componenti, un consulente esterno — chiunque lavorasse con Natanz e usasse normalmente una chiavetta USB tra i propri computer e quelli dell’impianto diventava un vettore involontario.
Quattro zero-day: la firma di uno stato nazione
Quando i ricercatori di sicurezza di Symantec e altri laboratori iniziarono ad analizzare Stuxnet nell’estate del 2010, rimasero letteralmente scioccati da quello che trovarono.
Il malware sfruttava quattro vulnerabilità zero-day di Windows in parallelo:
- CVE-2010-2568 — LNK file execution (la vulnerabilità USB)
- CVE-2010-2772 — Windows Task Scheduler
- CVE-2010-2729 — Windows Print Spooler
- CVE-2010-2743 — Windows kernel
Un singolo zero-day di Windows vale tra 100.000 e 500.000 dollari sul mercato nero. Usarne quattro contemporaneamente in un singolo malware era una spesa nell’ordine dei milioni di dollari, possibile solo per un’entità con risorse da stato nazione. Fino ad allora, i ricercatori non avevano mai visto un malware con più di un zero-day.
In aggiunta, il malware usava certificati digitali rubati — firmati da Realtek Semiconductor e poi da JMicron Technology — per sembrare driver legittimi al sistema operativo. Rubare certificati di firma di aziende taiwanesi reali richiedeva un’operazione di intelligence separata.
La payload: sabotaggio con precisione chirurgica
Stuxnet non era un malware che colpiva indiscriminatamente. Aveva una precisione chirurgica progettata per un singolo obiettivo.
Una volta all’interno di un sistema Windows, il malware cercava un software specifico: Siemens SIMATIC WinCC/STEP 7 — il software di programmazione per i PLC (Programmable Logic Controller) Siemens. I PLC sono i computer industriali che controllano i macchinari fisici: ricevono dati dai sensori e inviano comandi ai motori, alle valvole, ai sistemi di controllo.
Se trovava il software Siemens, analizzava la configurazione dei PLC collegati. La payload distruttiva si attivava solo se trovava questa configurazione precisa:
- PLC Siemens modello S7-315 o S7-417
- Collegati a inverter di frequenza (convertitori che controllano la velocità dei motori)
- Inverter prodotti da Fararo Paya (azienda iraniana) o Vacon (finlandese)
- Operanti in un range di frequenza tra 807 Hz e 1.210 Hz
Questa combinazione era quasi unica al mondo. Le centrifughe IR-1 di Natanz giravano esattamente a quella velocità, controllate esattamente da quel tipo di inverter Siemens. Era una firma di riconoscimento progettata per un singolo impianto specifico al mondo.
Il meccanismo di sabotaggio: il replay attack sui sistemi SCADA
Qui sta la parte più sofisticata e inquietante di Stuxnet.
Una volta identificata la configurazione corretta, il malware eseguiva una sequenza in tre fasi:
Fase 1 — Osservazione (13 giorni): il malware si installava silenziosamente e per tredici giorni non faceva nulla di visibile. Registrava i valori normali di tutti i sensori: velocità di rotazione, vibrazioni, pressioni, temperature. Costruiva un profilo del comportamento normale dell’impianto.
Fase 2 — Replay attack: quando iniziava la fase di sabotaggio, il malware intercettava la comunicazione tra i PLC e i sistemi di monitoraggio e sostituiva i dati reali con quelli registrati nella fase precedente. I monitor degli operatori continuavano a mostrare valori normali. I sistemi di allarme non scattavano. Dal punto di vista di ogni strumento di controllo, tutto funzionava perfettamente.
Fase 3 — Sabotaggio: mentre i monitor mostravano la normalità, Stuxnet inviava comandi anomali direttamente ai PLC. Prima portava la velocità delle centrifughe da 1.064 Hz a 1.410 Hz per 15 minuti — abbondantemente oltre i limiti operativi sicuri. Poi la abbassava bruscamente a 2 Hz per 50 minuti. Poi tornava alla velocità normale. Il ciclo si ripeteva.
Questo stress meccanico — accelerazioni e decelerazioni estreme e ripetute — causava usura strutturale. I cuscinetti si deterioravano. Le pareti delle centrifughe subivano deformazioni microscopiche. Le macchine si rompevano.
Dal punto di vista dei tecnici iraniani, le centrifughe sembravano avere difetti di fabbricazione. Alcune si rompevano fisicamente mentre erano in funzione — le pareti cedevano, le macchine esplodevano. I tecnici sostituivano i componenti, analizzavano i materiali, cercavano spiegazioni logistiche.
La scoperta
Nel giugno 2010, la società di sicurezza bielorussa VirusBlokAda trovò un malware insolito su sistemi in Iran e lo segnalò. Symantec, Microsoft e altri iniziarono l’analisi.
Nei mesi successivi, i ricercatori di Symantec pubblicarono un’analisi tecnica monumentale — 69 pagine — che divenne il documento di riferimento su Stuxnet. L’analisi stimò che la creazione del malware avesse richiesto tra sei mesi e un anno di lavoro da parte di un team di 5-10 persone altamente specializzate.
L’attribuzione: USA e Israele
Nessuno ha mai rivendicato ufficialmente Stuxnet. Ma le prove puntano in una direzione molto chiara.
Nel giugno 2012, il New York Times pubblicò un’inchiesta approfondita basata su interviste a funzionari americani e israeliani che confermava la paternità dell’operazione, chiamata internamente “Olympic Games”. L’operazione era stata avviata durante l’amministrazione Bush e continuata sotto Obama.
Obama, secondo le fonti del Times, aveva brevemente considerato di fermare l’operazione dopo che Stuxnet si era diffuso oltre Natanz ai sistemi di altre aziende in tutto il mondo. Un bug nel codice aveva permesso a Stuxnet di uscire dall’impianto attraverso il laptop di un ingegnere e di diffondersi su sistemi Windows in tutto il mondo — anche se la payload distruttiva si attivava solo con la configurazione Siemens specifica.
La collaborazione israeliana era evidente anche da un dettaglio tecnico: il codice conteneva un riferimento alla data ebraica del 9 di Av — una data di lutto nel calendario ebraico.
L’impatto stimato
Le stime sull’efficacia di Stuxnet variano. Il Institute for Science and International Security stima che il malware abbia distrutto circa 1.000 centrifughe su un totale di circa 5.000 operative a Natanz — circa il 20%. L’Iran ammise pubblicamente problemi tecnici al programma nucleare nel 2010, anche se non collegò esplicitamente i problemi a Stuxnet.
L’ex direttore della CIA Michael Hayden disse pubblicamente nel 2011 che Stuxnet era “un’azione di straordinaria abilità” e che aveva “rallentato” il programma nucleare iraniano. Il sito nucleare andò poi offline per diversi mesi.
L’impatto sulla sicurezza informatica: un prima e un dopo
Stuxnet ha ridefinito il concetto di cyberwarfare in modo permanente.
Prima di Stuxnet, il malware causava danni digitali: rubava dati, bloccava sistemi, criptava file. I danni erano virtuali — fastidiosi, costosi, ma reversibili.
Dopo Stuxnet, era dimostrato che il software può causare danni fisici irreversibili nel mondo reale. Una centrale elettrica che va offline non è un dato cancellato — è buio in città. Una centrifuga che esplode non è un file corrotto — è metallo e uranio sparso in un edificio.
Stuxnet aprì la discussione pubblica sulla sicurezza dei sistemi ICS/SCADA (Industrial Control Systems / Supervisory Control and Data Acquisition) — la categoria di sistemi che controllano infrastrutture critiche: centrali elettriche, impianti idrici, gasdotti, trasporti. Fino al 2010, questi sistemi operavano in un’oscurità quasi totale, assumendo che l’isolamento fisico fosse protezione sufficiente.
Stuxnet dimostrò che l’isolamento fisico può essere aggirato. E dimostrò anche qualcosa di più preoccupante: una volta che un’arma cibernetica esiste e viene usata, può essere studiata, riprodotta, adattata. Il codice di Stuxnet è pubblicamente disponibile. Le tecniche che usa sono documentate in dettaglio. Qualsiasi gruppo con le risorse e le competenze necessarie può costruire qualcosa di simile — e puntarlo altrove.
Il paradosso dell’arma che si diffonde
C’è un’ironia fondamentale nella storia di Stuxnet: è stato il primo caso in cui una potenza occidentale ha usato un’arma cibernetica offensiva sofisticata, dimostrando al mondo sia che era possibile sia come farlo.
Le stesse capacità sviluppate per sabotare Natanz sono ora nel catalogo concettuale di qualsiasi stato nazione con ambizioni cibernetiche offensive. Russia, Cina, Iran, Corea del Nord — tutti hanno programmi di cyberwarfare che devono qualcosa, concettualmente, a Stuxnet.
Il Pentagono ha poi formalmente classificato il cyberspace come “dominio di guerra” al pari di terra, mare, aria e spazio. Stuxnet è considerato il momento fondante di quella dottrina.
Conclusione
Stuxnet è il momento in cui la cybersecurity ha smesso di essere solo informatica e è diventata geopolitica. Ha dimostrato che un programma software — abbastanza sofisticato, abbastanza preciso, abbastanza paziente — può fare quello che i bombardieri non possono fare senza scatenare una guerra: fermare un programma nucleare senza vittime, senza esplosioni visibili, senza una dichiarazione di guerra.
Ha anche aperto un vaso di Pandora che non si chiuderà. Viviamo in un mondo in cui le infrastrutture critiche — la rete elettrica, l’acqua potabile, i trasporti, gli ospedali — sono gestite da sistemi informatici che qualcuno, da qualche parte, potrebbe aver già compromesso. La differenza tra un mondo che funziona e un mondo che si ferma può essere una riga di codice in un PLC Siemens.