About these ads

Archive

Posts Tagged ‘Infrastrutture Critiche’

Sono Rimasto di Stuxnet…

March 1, 2011 1 comment

Dietro ogni incontro, anche il più impensabile, si nasconde un fatto divertente. Durante una delle riunioni di lavoro di oggi, uno dei partecipanti, lettore del blog, mi ha casualmente raccontato che pochi giorni or sono, durante una attività professionale di tutt’altro tipo, si era imbattuto in Stuxnet, il famigerato Virus delle Centrali Nucleari. Dal momento che il malware era stato prontamente rilevato dall’Antivirus a bordo del Notbeook, non ho resistito alla tentazione e gli ho chiesto se la sua macchina recava ancora i segni dell’infezione.

Il risultato è davanti ai vostri occhi e in effetti devo ammettere che alla visione dell’immagine sottostante mi sono leggermente emozionato perché finalmente, dopo tanto parlarne, mi sono indirettamente imbattuto anch’io nel terrore dello SCADA e delle Infrastrutture Critiche, nonché indiscusso protagonista del panorama di sicurezza informatica del 2010.

Domanda facile facile: secondo voi quale è stato il meccanismo di infezione tra quelli disponibili dal Malware? Mentre indovinate la facile risposta vi invito comunque a non preoccuparvi: l’incontro ravvicinato del terzo tipo non è avvenuto in una centrale nucleare…

About these ads

Smart Grid? Dumb Security!

February 27, 2011 3 comments

Gli eventi che stanno sconquassando il Vecchio Continente ai suoi confini meridionali ripropongono purtroppo l’immancabile litania del problema energetico che lega indissolubilmente l’Occidente ai paesi produttori di petrolio in cui, guarda a caso, il livello dei diritti civili (e indirettamente la stabilità politica) è sempre inversamente proporzionale ai barili di petrolio prodotti.

Tra le soluzioni che l’occidente (cosiddetto) evoluto sta approntando per far fronte alle necessità di ottimizzare i consumi energetici, rientrano le cosiddette Smart Grid, ovvero le reti di distribuzione energetica intelligente, che costituiscono uno degli ingredienti fondamentali per il raggiungimento degli obiettivi Europei  del pacchetto clima-energia “20-20-20”. Approvato nel 2008, il pacchetto prevede entro il 2020 la riduzione del 20% delle emissioni di gas serra rispetto ai livelli del 1990, l’aumento dell’efficienza energetica del 20%, e che il 20% di produzione di energia elettrica provenga da fonti rinnovabili. Per il Belpaese questi obiettivi si traducono nel raggiungimento, da un livello del 5,2% nel 2005, ad un livello di produzione di energia da fonti rinnovabili del 17% entro il 2020.

Una Smart Grid altro non è che una griglia energetica che utilizza tecnologie proprie del mondo IP per consentire comunicazioni bidirezionali, coordinamento e controllo finalizzati ad una redistribuzione intelligente e dinamica dell’energia elettrica per far fronte ad eventuali picchi di consumo, oppure per ottimizzare la fornitura a fronte di cali improvvisi di consumo. In sostanza una rete di informazioni (basata su IP) viene sovrapposta ad una rete elettrica tradizionale, rendendo i nodi di consumo in grado di comunicare con la rete di distribuzione al fine di rendere l’intera struttura distribuita, resiliente, sicura e reattiva nei confronti delle richieste dei consumatori e delle possibilità di offerta degli operatori.

Da un punto di vista concettuale, una smart grid è per tutto assimilabile ad Internet:

  • E’ gerarchica nella sua struttura e possiede punti di demarcazione (ovvero di passaggio) tra diversi (Internet) Service Provider ben definiti;
  • La rete di generazione e trasmissione è assimilabile ad un backbone;
  • All’interno di aree geografiche limitrofe, le utility produttrici di energia distribuiscono l’energia agli utenti finali su Neighborhood Area Network (NAN) o Field Area Network (FAN), equivalenti alle Metropolitan Area Network (MAN) proprie del mondo IP.
  • La linea di demarcazione tra la rete di distribuzione e il consumatore (domestico o industriale) è rappresentata dall’Advanced Metering Infrastructure (AMI), che equivale ad un contatore elettronico di ultima generazione in grado di effettuare comunicazione bidirezionale con la rete di distribuzione. In ambito IP l’AMI corrisponde esattamente al ruoter di accesso (Customer Equipment) dall’ultimo miglio alla rete del provider a cui le nostre connessioni internet ci hanno ormai abituato;
  • All’intero di una casa o di un ufficio la Smart Grid si appoggia su una Home Area Network (HAN) o su una Building Area Network (BAN), concetti equivalenti approssimativamente ad una LAN di piano o LAN di palazzo. Aree più vaste delimitate da un AMI vengono chiamate Infrastructure Area Network (IAN)  e corrispondono aii cosiddetti campus del mondo IP).

Fino a qui le belle notizie: una rete Smart Grid è resiliente, distribuita, dinamica, consente di ottimizzare i consumi e sensibilizzare gli utenti sul valore dell’energia grazie alle funzioni per cui è stata concepita, ovvero:

  • Riprendersi autonomamente da perturbazioni (sbalzi e interruzioni di corrente);
  • Sensibilizzare gli utenti su un utilizzo più efficiente dell’energia;
  • Migliorare la qualità dell’energia in linea con le attuali esigenze di consumo;
  • Funzionare con diverse possibilità di generazione e consumo;
  • Permettere la creazione di nuovi prodotti, servizi e mercati
  • Ottimizzare l’utilizzo delle risorse.

Da qui in poi le brutte notizie: una rete Smart Grid, generalmente è composta da tecnologie eterogenee di 15/20 anni fa (è questo il tipico ciclo di vita dei componenti). Tecnologie eterogenee (e sovente non proprio di ultimissima generazione) che utilizzano il protocollo IP per trasportare le informazioni e che sfortunatamente non sono state create per garantire i livelli di sicurezza richiesti dall’apertura garantita dal mondo Internet. Se da un lato il protocollo IP costituisce l’intelligenza del sistema che consente ai vari nodi di pensare come un unico ecosistema, l’apertura verso questa intelligenza ha un prezzo costituito dal dover abbracciare inconsapevolmente le minacce annidate tra i pacchetti. Queste minacce nel caso di una Smart Grid potrebbero significare, nel peggiore dei casi, la possibilità di rendere indisponibile l’intera rete o una parte consistente di essa.

Pensandoci bene, dal punto di vista della connettività, le reti Smart Grid rappresentano un salto verso l’ignoto, ed è interessante il parallelismo con la rete Internet: nata per interconnettere i computer continentali di Oltreoceano, nessuno avrebbe potuto prevedere una simile diffusione, una simile influenza nella cultura e nella vita di tutti (e un simile impatto dei problemi di sicurezza da essa scaturiti). A peggiorare ulteriormente il quadro concorre l’evidenza che i sistemi di controllo delle Smart Grid, come il vituperato Supervisory Control and Data Acquisition, (esatto proprio lo SCADA già compromesso nel caso di Stuxnet) saranno costretti a raggiungere un livello di complessità notevole per essere in grado di gestire il proliferare delle smart grid e i dati raccolti  dalle stesse (provo un sottile brivido al pensiero dei relativi problemi di Privacy): “old-school SCADA that’s been bolted into some sort of a newer technology“.

La conseguenza è che le utility di energia stanno di fatto costruendo una nuova Internet, un vero e proprio universo parallelo, come lo definisce il National Institute of Standards and Technology (NIST), che, sulla scia dei problemi di sicurezza ha rilasciato appositi standard e specifiche per la cyber-sicurezza dei sistemi di controllo smart-grid.

Dei problemi di sicurezza delle Smart Grid si è parlato anche all’ultima RSA Conference 2011. Allo stato attuale il problema principale è rappresentato dall’obsolescenza della tecnologia (il tipico ciclo di vita è di 15/20 anni) dalla frammentazione della stessa tecnologia e delle competenze: le utility hanno centinaia di standard e protocolli differenti, e tipicamente le risorse che gestiscono le infrastrutture hanno  poche competenze IT. Questo rende difficile anche la convergenza tra le diverse discipline, come se ad una convergenza tra le tecnologie, di distribuzione dell’energia e di controllo basato su IP, non fosse corrisposta una analoga convergenza tra le strutture di gestione e questo un po’ anche per ragioni culturali: chi gestisce le utility ha poca fiducia su chi proviene dal mondo IT abituato a mettere le mani a destra e manca, e tende di conseguenza a tenere la gestione del proprio mondo chiusa.

Ma quali sono gli attacchi a cui potrebbero essere vulnerabili le Smart Grid?

Chi si ricorda “Una Poltrona Per Due” ricorderà il goffo tentativo di aggiotaggio dei fratelli Duke (interpretati da Ralph Bellamy e un impareggiabile Don Ameche) basato sulla conoscenza in anticipo del prezzo delle arance finalizzato a speculazioni borsistiche. Arance a parte nel caso di una Smart Grid lo scenario non sarebbe molto diverso: un attaccante potrebbe manipolare i dati della griglia intrufolandosi virtualmente all’interno di una substation di distribuzione e intercettando le comunicazioni tra substation, operatori, e fornitori di elettricità. Poiché questi dati sono usati dagli operatori per fissare i prezzi dell’elettricità e per bilanciare la domanda e offerta di energia, nel migliore dei casi gli operatori potrebbero fare milioni di dollari a spese dei contribuenti (prevedendo e influenzando artificialmente il costo dell’energia alterando le richieste), nel peggiore dei casi potrebbero rendere la griglia instabile causando blackout. Il perché è facilmente comprensibile sulla base del processo di fatturazione di una smart grid: tipicamente gli operatori fissano il prezzo dell’energia un giorno prima in base ai dati raccolti su disponibilità e necessità dei clienti, e sulla base delle stesse previsioni preparano l’infrastruttura a sostenere il consumo che verrà fatturato il giorno successivo. Ovviamente è sufficiente manipolare i dati per creare necessità artificiose, alterare i prezzi e con tutta probabilità diventare milionari scommettendo in borsa sul prezzo dell’energia (ti piace vincere facile…)

Questo è teoricamente possibile già oggi, ma basta chiudere gli occhi e pensare ad un futuro non troppo lontano che già si delineano gli scenari prossimi venturi: ad esempio le stazioni di ricarica delle autovetture elettirche, tutti punti deboli e interconnessi, in cui un singolo point of failure, aperto al mondo esterno e quindi accessibile, potrebbe compromettere l’intera infrastruttura.

Come uscire dal tunnel? Sicuramente con investimenti tecnologici che applichino nativamente agli elementi di una Smart Grid le funzioni di sicurezza proprie del mondo IP (a cominciare dalla cifratura), con un nuova impostazione interdisciplinare che elimini le barriere tra gestori delle utility e gestori delle infrastrutture IT, e soprattutto con un approccio strategico che integri le funzioni di analisi del rischio e gestione del rischio a tutti i livelli della griglia.

Una mano in questo senso verrà sicuramente con il programma NERC CIP (North American Electric Reliability Corp.’s Critical Infrastructure Protection Plan), piano recentemente aggiornato che raccoglie oltre 100 standard e stabilisce i requisiti per la protezione degli elementi critici di una Smart Grid, avendo come punto di partenza ed elemento chiave proprio la sicurezza delle infrastrutture IT.

Con la sete di energia, l’instabilità che caratterizza certe zone del globo, e l’evidenza che le guerre si stanno spostando sulle scacchiere virtuali, c’è da essere certi che sentiremo molto spesso parlare delle Smart Grid… E non solo per gli indubbi vantaggi energetici…

Report Symantec Q4 2010: Fate Presto… Prima che la sicurezza SCADA!

February 16, 2011 1 comment

Symantec è particolarmente attiva in questo scorcio del 2011, così, dopo la pubblicazione del Dossier Stuxnet aggiornato, ha appena rivelato alla comunità di sicurezza il Symantec Intelligence Quarterly Report: October – December, 2010 che è interessante analizzare, notando, come questo si discosti notevolmente dall’analogo report recentemente pubblicato dalla livrea rossa di McAfee, principale concorrente del produttore di sicurezza di Cupertino.

Il titolo del report è tutto un programma: “Targeted Attacks on Critical Infrastructures” e riassume quelle che sono state le caratteristiche, dal punto di vista della sicurezza, di questo fine 2010: i cybercriminali si sono concentrati sulla creazione di malware targeted (ovvero ritagliato su misura) per danneggiare infrastrutture critiche.

Gli attacchi cosiddetti targeted sono perpetrati verso una specifica organizzazione o una specifica categoria di utenti e per questo sono notevolmente pericolosi ed efficaci, anche se usano tecniche tradizionali come phishing o link malevoli, essendo ritagliati su misura per l’infrastruttura obiettivo o anche per le abitudini o caratteristiche comportamentali degli utenti.

Attacchi di questo tipo, definiti anche Advanced Persistent Threat, trovano purtroppo una vasta gamma di applicazioni che spaziano dal furto di dati confidenziali finalizzato al profitto (ad esempo la sottrazione di credenziali bancarie), sino all’interferenza con le operazioni , se non in un vero e proprio sabotaggio dell’infrastruttura obiettivo. In molti casi, come ci ha dimostrato il 2011 (ed in particolare il mai troppo abusato Stuxnet) per ottenere lo scopo è sufficiente infettare un solo host (il famigerato paziente 0) per poi utilizzarlo come ponte involontario e catalizzatore per l’ondata di attacchi successiva.

E quindi cosa è accaduto nel 2010? La risposta è relativamente semplice, come dimostrato dal Trojan Hydraq (aka Operation Aurora secondo la nomenclatura adottata dal concorrente McAfee): una volta scoperte le potenzialità dei targeted attack i Cyber-criminali ne hanno utilizzato l’energia distruttiva verso le Infrastrutture Critiche.

A sostegno di questa tesi, il documento cita appunto i casi di Hydraq e Stuxnet. Il primo è inizialmente nato come un targeted attack facente leva su una Vulnerabilità del browser di casa Microsoft (advisory number 979352) con lo scopo finale di sottrarre informazioni alla vittima ed inviarle ad un server di comando e controllo. Questo attacco, che ha caratterizzato l’inizio del 2010 si è da subito tinto di giallo, non tanto per il mistero, quanto per i sospetti che sia stata proprio la Cina ad utilizzarlo con lo scopo di rubare credenziali di dissidenti dagli Account di Google.

Del secondo sappiamo tutto, addirittura Stuxnet era talmente targeted e così interconnesso con l’infrastruttura vittima, a tal punto che, secondo i ricercatori Symantec, sono passate solo 12 ore dalla prima compilazione alla prima infezione.

Curiosamente (ma fino a un certo punto) il report Symantec non cita Night Dragon, il malware scoperto dal concorrente McAfee che a mio avviso incarna meglio di chiunque altro, nel corso dell’ultimo trimestre 2010, il concetto del targeted attack rivolto a specifiche facility (questa volta un malware con il vizio del petrolchimico) e soprattutto facente uso di metodi tradizionali (SQL Injection e soprattutto download di malware tramite tecniche di Spearphishing) al fine di penetrare le barriere iniziali di protezione ed addentrarsi intimanente all’interno della rete verso le casseforti virtuali dove sono custoditi i segreti tecnici ed economici dell’organizzazione.

Gli attacchi di tipo targeted si fanno particolarmente pericolosi quando, come nel caso di Stuxnet. incrociano il mondo SCADA (Supervisory Control and Data Acquisition), ovvero quei processi e tecnologie che sottendono al monitoraggio e controllo delle Infrastrutture Critiche e dell’Industria, e che proprio per questo motivo, soprattutto in un momento turbolento come quello che stiamo vivendo, potrebbero essere al centro dell’attenzione di paesi nemici o singoli individui guidati da motivazioni ideologiche e politiche.

La pericolosità di SCADA non è nuova (si legga ad esempio questo articolo della stessa Symantec risalente al 2006), tuttavia nel 2010, è assurta alla ribalta grazie a Stuxnet e agli eventi successivi. Solo nell’ultimo trimestre dell’anno passato Symantec ha documentato 10 vulnerabilità pubbliche di SCADA, sulle 15 totali scoperte nel corso dell’anno. Ma non facciamoci troppe illusioni… Anche se numericamente esigue a causa della natura elitaria delle ricerche di sicurezza su questa tecnologia,  l’impatto di queste vulnerabilità è immane e un malintenzionato che volesse sfruttarle saprebbe bene come rendere il proprio attacco targeted per i punti deboli di SCADA, tra i quali Symantec ha annoverato nel 2010:

  • Tre vulnerabilità nell’interfaccia Web CGI dei prodotti Intellicom Netbiter webSCADA WS100 e WS200. Le vulnerabilità rilevate non sono di poco conto poiché consentono di caricare ed eseguire codice arbitrario ed accedere di conseguenza ad informazioni potenzialmente sensibili;
  • Una vulnerabilità di tipo SQL-injection all’interno della pagina di login del sistema SCADA Industrial Technology System (ITS). La vulnerabilità in oggetto consente di compromettere l’applicazione modificando la struttura del database sottostante;
  • Tre vulnerabilità di tipo buffer-overflow per il server DATAC RealWin SCADA. Grazie a questo insperato aiuto un attaccante è in grado di eseguire codice sul server;
  • Ulteriori tre vulnerabilità sono state scoperte nel prodotto Ecava IntegraXor, di cui due di tipo remote code-execution e una terza di tipo directory-traversal. “Ambetre” le vulnerabilità di questo prodotto possono essere utilizzate da un malintenzionato per eseguire codice arbitrario o accedere a informazioni sensibili ivi contenute.

Purtroppo la situazione è ulteriormente complicata dal fatto che una architettura SCADA non deve fare i conti con le sole proprie vulnerabilità intrinseche ma è costretta a portarsi dietro anche il pesante fardello delle vulnerabilità ereditate dai sistemi operativi ospitanti (sovente Microsoft) o dal middleware e database utilizzato per l’applicazione SCADA.

L’applicazione pratica di una vulnerabilità SCADA in una infrastrutture critica è presto detta, ed il caso di Stuxnet ne è emblematico: i sistemi di controllo industriale (di cui SCADA costituisce un esempio) sono utilizzati all’interno delle infrastrutture critiche per controllare i processi operativi quotidiani. In particolare sono essenziali per controllare e processare le informazioni inviate dai sensori ed attuare di conseguenza le necessarie azioni e comandi di risposta. A questo compito si aggiungono il monitoraggio degli ambienti operativi per verificare che le attività vengono sempre effettuate all’interno dei parametri di sicurezza (sono quindi in grado di prevenire condizioni pericolose per l’uomo quali: surriscaldamento, aumento dei livelli di tossicità, incendi o potenziali sovraccarichi).

Un sistema di controllo compromesso da un malware potrebbe non essere in grado di riconoscere le condizioni di pericolosità o anche di non contrastarle efficacemente, se non addirittura di sabotare deliberatamente e in maniera subdola l’infrastruttura come nel caso di Stuxnet. Le conseguenze potrebbero essere disastrose e portare ad eventi come quello (involontario) della città di Lake Havasu rimasta a secco per un guasto nel sistema di monitoraggio delle pompe d’acqua (Luglio 2010).

E quindi?

E quindi Symantec suggerisce di limitare l’esposizione delle reti che ospitano sistemi SCADA, possibilmente  isolandole dal resto del Globo. Nel caso in cui ciò non fosse possibile, il traffico verso il mondo esterno andrebbe limitato ai soli protocolli richiesti non disdegnando di proteggere ulteriormente gli accessi individuali mediante VPN IPSec autenticate ed eventualmente integrando la difesa con tecnologie di protezione di tipo endpoint sui sistemi operativi ospitanti (che comunque andrebbero sempre aggiornate) e con sistemi di Intrusion Detection & Prevention per le minacce di rete.

Dal punto di vista infrastrutturale la sicurezza di una infrastruttura SCADA è ulteriormente minata dal fatto che spesso, a causa della complessità, non è possibile creare un ambiente di test. Inoltre le interruzioni di servizio andrebbero limitate al minimo indispensabile poiché spesso sono costose se non addirittura distruttive. Suggeriti invece i test che possono essere fatti in linea, senza interrompere l’operatività quali passive asset discovery e vulnerability scanning, mentre tutte le operazioni di aggiornamento (Antivirus e pezze patch di sistema operativo) dovrebbero essere effettuate con la massima cura e con il massimo supporto dei produttori dei sistemi di controllo per minimizzare rischi e tempi di down.

Last But Not Least, non trascurare le attività di audit e policy compliance…

Cybereventi Di Guerra

January 28, 2011 Leave a comment

In un recente articolo ho commentato uno studio dell’OCSE secondo il quale le probabilità di una Cyberwar sono piuttosto basse,  se non in combinazione di eventi particolarmente catastrofici su scala planetaria.

In realtà la tesi non è nuova, ed era già stata portata alla ribalta, con termini ancora più espliciti (la Cyberguerra altro non è che una montatura e le probabilità non sono superiori a quelle di una invasione terrestre), dal noto guru e security evangelist Bruce Scneier.

Già proprio così, sembra proprio che dovremo rassegnarci a confinare esclusivalmente al grande schermo le scacchiere mondiali in cui i Cyber Eserciti si combattono a colpi di bit. Però una curiosità rimane: cosa significa  in termini pratici che una Cyberguerra avrebbe conseguenze su scala globale solamente in concomitanza di altri eventi? E quali sarebbero gli impatti?

Ci sono tante domane irrisolte anche in una vita breve come la vostra

recitava David Lo Pan, il cattivo dello splendido quanto incompreso Grosso Guaio a Chinatown.

Fortunatamente non è il nostro caso, poiché all’interno del rapporto dell’OCSE si trova una curiosa tabella in cui gli autori hanno provato ad ipotizzare diversi scenari caratterizzati da Cyber eventi, e le relative conseguenze. Di seguito un riassunto, da me rielabolato, dal quale si decuce che gli eventi con maggiore impatto sono quelli in concomitanza con pandemie umane e bancarie.

Tabella 1: Conseguenza di una compromissione dell’infrastruttura Internet

Tabelle 2, 3 e 4: Impatto di eventi Cyber-relati in concomitanza con eventi macroscopici

L’impatto della Pandemia umana agisce come catalizzatore della Cyber Minaccia per via del minore numero di risorse sane in grado di gestire l’evento. Per contro l’effetto di cyber-eventi potrebbero essere particolarmente devastanti in presenza di una pandemia bancaria, o meglio una crisi finanziaria, acuendo il disagio sociale e l’impossibilità per governi e singoli individui di accedere, ad esempio, ai propri depositi (una interpretazione questa un po’ forzata).

Nel caso di altri eventi naturali su scala globale, sino ad oggi le infrastrutture si sono sempre riprese in tempi relativamente brevi.

Virus e Servizi Segreti (Ancora Su Stuxnet)

January 16, 2011 2 comments

Il complesso di Dimona (Foto Getty Images)

E’ di questa mattina la notizia, secondo il New York Times, che il famigerato malware Stuxnet, il virus delle centrali nucleari, sarebbe stato sviluppato da un team composto da Israeliani e Americani (con la collaborazione indiretta degli ingegneri tedeschi di Siemens) presso il complesso israleliano di Dimona, nel bel mezzo del deserto del Negev.

Lo sviluppo di questo terribile malware sarebbe partito nel 2009. Il virus, assurto alla ribalta nel 2010, ha messo in ginocchio un quinto delle centrali nuclerari iraniane ed avrebbe raggiunto parzialmente il suo scopo (molte centrifughe sono state arrestate prima dell’insorgere di danni irreversibili) secondo il quotidiano d’Oltreoceano, riuscendo però a tardare la realizzazione della bomba sino al 2015.

Stuxnet, che prefigura il modello di infezione informatica Advanced Persistent Threat, che nel 2011 turberà i nostri sogni, aveva da subito attirato l’attenzione dei ricercatori di tutto il mondo sia per la sua complessità tecnica (7 vettori di infezione, l’utilizzo massiccio di vulnerabilità 0-day, la possibilità di falsificare certificati ed infine la conoscenza approfondita della tecnologia Siemens relativa alle centrifughe colpite), sia per i presunti richiami all’Antico Testamento più o meno nascosti all’interno del codice.

La complessità alla base del malware è presumibilmente dovuta al fatto che all’inizio del 2008, Siemens avrebbe collaborato con uno dei principali laboratori statunitensi, in Idaho, al fine di identificare le vulnerabilità dei computer che controllano le macchine industriali vendute da Siemens in tutto il mondo. Macchine Industriali che l’Intelligence d’Oltreoceano aveva identificato essere componenti chiave degli impianti di arricchimento dell’Uranio iraniani.

Siemens sostiene comunque che il programma (confermato dall’Idaho National Laboratory) era parte delle attività di routine volte a rendere sicuri dai Cyber-attacchi i propri sistemi che presiedono alle Infrastrutture Critiche, e ad ogni modo non avrebbe dato all’Idaho National Laboratory, parte del Dipartimento dell’Energia responsabile per gli armamenti nucleari USA, la possibilità di identificare i buchi del sistema utilizzati da Stuxnet nel 2010. I risultati sono stati riassunti in questa presentazione mostrata a luglio 2008 al Siemens Automation Summit presso Chicago. Il laboratorio americano, interrogato sulla questione, si è difeso indicando che la presentazione, sebbene contenesse schemi dettagliati, non mostrava come utilizzare le vulnerabilità, rifiutandosi nel contempo di fornire indicazioni relativamente agli aspetti classificati delle attività effettuate congiuntamente con Siemens. Siemens, dal canto suo, ha commentato la nitizia indicando che la presentazione non recava informazioni relative all’ubicazione delle centrifughe. Sta di fatto che la presentazione è recentamente scomparsa dal proprio sito Web.

L’origine politica del progetto partirebbe dagli ultimi mesi dell’Amministrazione Bush, che a gennaio 2009 avrebbe autorizzato (secondo il NYT) un programma nascosto per sabotare i sistemi elettronici ed informatici del complesso iraniano di Natanz, il principale centro di arricchimento dell’Uranio. Al suo insediamento, il Presidente Obama, appena informato del programma, ne avrebbe accelerato lo sviluppo secondo fonti dell’Amministrazione vicine agli strateghi responsabili dei piani volti a contrastare la strategia nucleare iraniana.

Naturalmente gli israeliani, preoccupati dai pericolosi sviluppi della situazione iraniana, non si lasciarono sfuggire l’occasione sviluppando una strategia di contrasto della minaccia iraniana congiunta con gli USA e differente da quella militare sostenuta sino ad allora.

Stuxnet o non Stuxnet, recentemente sia il Segretario di Stato Americano Hilary Clinton, sia il direttore uscente del Mossad, Meir Dagan, hanno confermato separatamente (rispettivamente il 10 e 7 gennaio) la propria convinzione di un ritardo (o meglio di un arretramento di alcuni anni) nei piani di sviluppo nucleare dell’Iran. Ma mentre la signora Clinton ha fatto riferimento alle sanzioni pilotate dagli USA, sanzioni che avrebbero reso difficile all’Iran procurarsi i componenti, e più in generale commerciare con altri paesi della comunità internazionale; il Signor Dagan ha annunciato al Knesset (il parlamento isreaeliano) l’improvviso insorgere di difficoltà tecnologiche in grado di ritardare la preparazione di una bomba iraniana sino al 2015. Da notare che sino ad allora gli israeliani erano stati fermamente convinti dello stato avanzato di realizzazione del programma nucleare iraniano e che il Mossad è stato accusato dall’Iran di essere la longa manus dietro agli attentati in cui è rimasto ucciso Majid Shahriari, scienziato nucleare iraniano e Fereydoon Abbasi, altro scienzato nucleare, è rimasto ferito.

Gli argomenti della spy story ci sono tutti: CIA, Mossad, lo spettro della Guerra Nucleare, il tutto condito con un pizzico di malware, Cyberwar e… perchè no di Sacre Scritture. Sarà davvero l’ultima puntata della storia?

Ancora Su Stuxnet (II Parte)

December 19, 2010 3 comments

Sto veramente invecchiando…

Lunedì 29 novembre, ero con David, dopo una riunione stavamo cercando di seppellire una improbabile pizza con un caffè, e siamo rimasti colpiti da un passaggio veloce su SkyNews 24 in cui si riportava una dichiarazione di Ahmadinejad, presidente della Repubblica Islamica dell’Iran, relativa ad una infezione informatica che ha preso d’assalto le proprie Centrali Nucleari. Naturalmente entrambi abbiamo subito pensato a Stuxnet, il virus informatico di cui ho ampiamente discusso. Ho pensato di approfondire la notizia nel corso della giornata, ma alla fine ho avuto il tempo solamente per una fugace occhiata: probabilmente mi è passata inosservata o meglio è stata messa in silenzio dall’eco mediatico relativo a fiducia del governo e bunga bunga vari.

Stamattina, dopo 20 giorni, stavo sfogliando la Rete alla ricerca del sonno perduto, ovviamente non sono riuscito a ritrovare il sonno ma in compenso mi sono imbattuto casualmente in una interessantissima discussione sull’argomento ospitata dal gruppo Italian Security Professional di Linkedin, e ho scoperto (meglio tardi che mai) cosa è accaduto il 29 novembre 2010.

In quella data, in un attentato a Teheran è stato ucciso Majid Shahriari, scienziato nucleare iraniano. Quasi comtemporaneamente a Teheran, lo stesso giorno, in un attentato analogo un altro scienziato coinvolto nel programma nucleare iraniano, Fereydoon Abbasi, è rimasto ferito.

Ci sono alcune discordanze tra gli articoli che ho trovato, sia relative alla modalità dell’attentato, sia relative all’effettivo coinvolgimento della vittima nel programma nucleare iraniano, tuttavia il collegamento con l’affaire del virus delle centrali sorge spontaneo. Boutade mediatica, effettiva guerra alle centrali nucleari iraniane da parte di Israele o mere coincidenze? Ai posteri (ma non troppo) l’ardua sentenza…

Ancora su Stuxnet

November 28, 2010 Leave a comment

Probabilmente questo punto desterà l’interesse del mio carissimo amico e collega, esperto di sicurezza informatica, nonché affermatissimo giornalista di aviazione David Cenciotti. Rileggendo con più attenzione il Report Symantec su questo temibilissimo Malware, a pagina 38 è riportata una indicazione che gli farà senz’altro piacere:

 

However, there are some additional interesting clues. For example, code added to OB35 uses a magic marker value of 0xDEADF007 (possibly to mean Dead Fool or Dead Foot—a term used when an airplane engine fails) to specify when the routine has reached its final state.

 

Ancora non sono state rilevate correlazioni, probabilmente si tratta di una mera coincidenza o di un valore arbitrario (per quanto suggestivo evocatore di oscuri presagi 0xDEADF007 corrisponde al numero decimale 3735941127 espresso in forma esadecimale). E’ comunque doveroso notare il fatto che il messaggio viene stabilito dal codice di Stuxnet, pertanto non è stato scelto a caso.

E ancora tutti i blocchi del codice Step7, il software utilizzato per programmare il PLC dei Sistemi di Controllo Industriale Siemens, presentano tutti la stessa data del 23 settembre 2001. Anche in questo caso non è ancora stata trovata nessuna corrispondenza. Che sia solo una ulteriore mera coincidenza oppure la data ha veramente un significato recondito?

Follow

Get every new post delivered to your Inbox.

Join 3,091 other followers