About these ads

Archive

Posts Tagged ‘SCADA’

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…

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?

La Cabala dentro il virus

November 23, 2010 6 comments

Ho già parlato di Stuxnet, il virus prototipo delle nuove Cyber-guerre, che la leggenda vuole essere stato creato da un paese nemico dell’Iran per sabotare i piani di sviluppo nuclerare di quest’ultimo.

Diffusione del worm, Symantec W32.Stuxnet Dossier, versione 1.3 novembre 2010

Ieri sera leggendo il report di sicurezza Q3 2010 di McAfee sullo stato delle minacce, mi sono imbattuto in una notizia curiosa riguardante Stuxnet (che ha ovviamente vinto il poco ambito premio di peggiore minaccia del 2010) secondo la quale all’interno del malware delle centrali nucleari sarebbero celati alcuni indizi  che, hanno consentito di risalire all’origine del malware .

Prima di addentrarci nella questione, è opportuna una doverosa premessa: la numerologia, ovvero lo studio della possibile relazione mistica o esoterica tra i numeri e le caratteristiche o le azioni di oggetti fisici ed esseri viventi sovente gioca brutta scherzi. Personalmente la considero una delle forme in cui si manifesta l’operazione del reverse engineering, ovvero quel processo usato ormai in molte sfere della scienza che tenta di ricostruire un fenomeno scientifico a partire dalle conclusioni. In parole povere: sapendo come deve evolvere un determinato fenomeno e quali sono le conclusioni, viene costruito un modello ad-hoc che giunga esattamente alle conclusioni riscontrate. Forzando volutamente il paragone, la stessa cosa è applicabile per date, eventi e oscure coincidenze: armatevi di una qualsiasi data, un evento accaduto e un motore di ricerca, e sicuramente sarà possibile trovare dietro quei numeri qualche oscura profezia o qualche improbabile teoria del complotto (chi non ricorda le storie su Bill Gates anticristo, o le oscure coincidenze celate dietro la data dell’11 settembre 2001).

Ma torniamo a Stuxnet e alla sua origine “artificiale” e fantapolitica. La natura bellica del malware (ed in particolare la sua origine da Israele) ha origine da tre indizi riscontrati dai ricercatori, consistenti in altrettanti messaggi oscuri celati dentro le righe di codice del malware: una pianta e due date.

  • Myrtus;
  • 9 maggio 1979;
  • 24 giugno 2012.

La regina di Persia:

Ester davanti ad Assuero, Konrad Witz, 1445-1450, Basilea, Kunstmuseum

Myrtus è il nome di un file all’interno del codice di Stuxnet (il driver del rootkit include il path b:\myrtus\src\objfre_w2k_x86\i386\guava.pdb) e richiama apparentemente una innocua pianta da cui si ricava un gustoso liquore (in realtà anche la pianta guava appartiene alla famiglia del Mirto). Se tuttavia si scava un po’ più in profondità si scopre che il mirto ha per gli Ebrei un significato particolare in quanto richiama il nome di Ester, una eroina ebraica del V secolo a.C. le cui gesta sono descritte nel Libro di Ester. Ester, il cui vero nome era Hadassa (termine che in ebraico significa esattamente Mirto) divenne la sposa del sovrano Assuero (riconosciuto dagli storici con Serse I il re di Persia, ovvero il moderno Iran), ed ha il merito di avere evitato una congiura perpetrata dal perfido consigliere del re Haman, congiura avente come scopo la distruzione del popolo Ebreo. Da allora è stata istituita la festa del Purim, corrispondente al Carnevale Ebreo, e soprattutto nella tradizione giudaica Ester è vista come strumento della volontà di Dio per impedire la distruzione del popolo giudaico.

Piccola parentesi: l’etimologia del nome Ester è incerta, per alcuni deriva dal termine usato dai Medi per indicare, guarda a caso, il mirto, per altri deriva dal termine Ishtar che significa stella in Assiro, ad ogni modo le radici non sono in contraddizione poiché il mirto era chiamato anche fiore a stella. Mi fermo qui ma non posso fare a meno di notare che Ester ha la stessa radice del termine Ishtar con cui i Persiani chiamavano Venere (o Astarte), e chissà che anche il termine “star” che nella lingua anglosassone significa stella non derivi da Ester (o Ishtar) definita “più bella di una stella della notte”.

Ad ogni modo tornando al parallelismo con il virus Stuxnet non si può fare a meno di notare che:

Ester (mirto) sventa un complotto persiano contro il popolo ebreo, ovvero Stuxnet (myrtus) sventa un complotto iraniano (l’odierna persa) contro il popolo ebreo.

 

La data che venne dal passato:

Tre ricercatori Symantec hanno scoperto che il codice di Stuxnet contiene uno strano indicatore cablato al suo interno consistente in una stringa numerica “19790509” che il malware scrive nel registro della macchina infetta e che ha un duplice scopo: indicare che l’host è stato infettato, oppure, se già presente la chiave di registro, impedire l’infezione della macchina vittima.

Habib Elghanian

Ai più attenti non sarà sfuggito che la stringa numerica in questione rappresenta una data; secondo la notazione anglosassone difatti 19790509 corrisponde al 9 maggio 1979. E qui la numerologia la fa da padrona: il 9 maggio 1979 è considerata una data storica per la comunità ebraica in Iran (guarda a caso ancora l’Iran) poiché in quella data è stato ucciso Habib Elghanian, importante uomo d’affari israeliano e soprattutto leader della comunità Ebrea in Iran. L’importanza storica di quell’evento è  particolarmente infausta poiché da allora cominciò l’esodo di 100.000 membri della comunità di Ebrei in Iran.

Certo l’ipotesi di una vendetta informatica a 30 anni di distanza (che richiama il torto subito dal paese vittima) è intrigante, anche se, a onor del vero, il tutto appare poco più che una speculazione, anche se suffragata dalla numerologia.

 

Ritorno al futuro:

Gli stessi ricercatori hanno scoperto che il virus Stuxnet è programmato per “spegnersi” il 24 giugno 2012. Non essendo un bravo numerologo o cabalista non ho trovato nessun evento particolare per questa data se non il termine della fase dei quarti di finale dei campionati europei di calcio del 2012 e l’evento astronomico della cosiddetta “Grand Cross“, ovvero l’incrocio tra Plutone in Capricorno e Uranio in Ariete.

Naturalmente poiché la data di harakiri di Stuxnet fa riferimento al 2012, un accostamento con la presunta fine del mondo del 21 dicembre 2012 non poteva mancare. Ed in effetti secondo alcune interprestazioni, in verità piuttosto scettiche,  il 24 giugno sarebbe la data di inizio di questa fase di rinnovamento.

Voi che ne dite? Pensate che le tracce siano mere coincidenze o indizi appositamente inseriti (ma in questo caso manca ancora l’interpretazione del 24 giugno 2012)? Oppure ritenete che Stuxnet rappresenti l’opera di un programmatore smanettone con conoscenze degli ambienti SCADA, l’hobby delll’astronomia e della botanica (myrtus potrebbe essere la trasposizione di MyRTUs, termine comunemente indicato in ambito SCADA per indicare le Remote Terminal Unit), nato il 9 maggio 1979 (e che magari ha fissato la data di nozze per il 24 giugno 2012)? Si accettano scommesse…

Come ti impoverisco l’Uranio con un virus…

November 19, 2010 8 comments

Da tempo la televisione ed il cinema ci hanno abituato a improbabili (almeno fino a qualche tempo fa) scenari, in cui altrettanto improbabili cyber-terroristi partono alla conquista del mondo utilizzando la rete per rubare segreti o sabotare infrastrutture critiche.

Il tutto parte da lontano: già dal 1983, quando internet era appena agli albori, War Games e Superman III mostrarono ai curiosi adolescenti figli degli anni ’80, quali danni si potevano fare con i bit. Se War Games disegna in modo un po’ ingenuo e romantico la figura del “protoHacker”, in Superman III, il compianto Cristopher Reeve nei panni dell’eroe di Krypton affronta un supercomputer concepito con lo scopo esplicito si sabotare le  infrastrutture Critiche (centrali petrolifere e relative petroliere) per bloccare la società civile e ottenere il controllo del mondo (energia, comunicazioni, etc.).

Ai tempi fui sorpreso, non riuscivo proprio a concepire un computer che potesse bloccare tutti i pozzi petrofileri del mondo. Oggi, a più di 20 anni di distanza devo ammettere che Richard Donner fu un ottimo profeta: le minacce informatiche alle infrastrutture critiche che regolano “l’ordine mondiale” (energia, trasporti, economia, etc.) sono una realtà consolidata e destinata ad assumere sempre maggiore importanza nel panorama della sicurezza informatica. Così importanti da spingere qualcuno ad affermare che le guerre del futuro si combatteranno a colpi di bit piuttosto che a colpi di armi.

Il 2010 è stato un anno particolarmente significativo per questo trend: all’inizio di quest’anno McAfee, uno dei più importanti player di sicurezza informatica, ha stilato un report inerente al livello di esposizione delle infrastrutture critiche nell’epoca della guerra informatica. Il documento, redatto in base a questionari anonimi compilati da 600 responsabili di sicurezza e IT di 14 paesi delinea un quadro piuttosto allarmante: oltre la metà dei dirigenti interpellati (54%) aveva dichiarato di aver subito un attacco di tipo Denial Of Service e soprattutto, il 59% (in Italia il 45%) riteneva che negli eventi fossero coinvolti rappresentanti di governi stranieri (caso emblematico è l’attacco informatico di cui fu vittima l’Estonia nel 2007 e che causò per alcune settimane il blocco dei principali siti, istituzionali, economici e di informazione del paese baltico).

Il report di McAfee conteneva, tra le altre informazioni, due sinistre profezie: la forma di attacco più diffusa allora era risultata essere l’infezione da virus o malware, subita dall’89% degli intervistati ed inoltre nello stesso report  veniva segnalato il basso livello di sicurezza dei sistemi SCADA o ICS (Industrial Control System – Sistemi di Controllo industriale) ovvero quei sistemi utilizzati per il monitoraggio delle infrastrutture critiche.

Le due indicazioni precedenti contengono l’essenza della minaccia informatica che nel corso del 2010 ha cambiato le regole del gioco delinenando le caratteristiche delle infezioni virali di nuova generazione nell’epoca del cyber-terrorismo.

Sto parlando naturalmente di Stuxnet, una infezione virale di nuova concezione espressamente creata per infettare sistemi di controllo industriale non connessi in rete (partendo da una chiavetta USB), e di espandersi utilizzando 6 vulnerabilità Microsoft (delle quali 2 di tipo 0-Day) con 7 diversi vettori:

  1. Replica su dispositivi Mobili
  2. Vulnerabilità del protocollo SMB (MS08-067);
  3. Diffusione tramite share di rete;
  4. Replica utilizzando una vulnerabilità dello spooler di stampa Windows (MS10-061);
  5. Possibilità di replicarsi mediante WinCC – l’applicazione utilizzata per il controllo e la gestione dei sistemi ICS Siemens;
  6. Possibilità di iniettare codice su un file Step 7, il software utilizzato per la programmazione dei sistemi di controllo Siemens,
  7. Infine (last but not least), possibilità di crere una rete peer-to-peer all’interno di una LAN per l’aggiornamento e la gestione del vettore di infezione.

In sostanza quindi Stuxnet agisce come un rootkit per i sistemi SCADA Siemens.

Analizzando bene le caratteristiche del vettore di infezione, la parabola di stuxnet si tinge di giallo (in tutti i sensi) e sembra essere uscita da un romanzo di Michael Crichton. In un post pubblicato di recente, Symantec ha rilevato che lo scopo di Stuxnet è quello di alterare il normale ciclo di funzionamento per i convertitori di frequenza utilizzati nei SIstemi di Controllo Industriale. In ambito ICS i convertitori di frequenza sono apposite unità di alimentazione che hanno lo scopo di cambiare la frequenza del segnale e in output, ad esempio per aumentare la velocità di un motore. In particolare Stuxnet agisce per convertitori di frequenze operanti a cicli elevati  (tra 807 Hz e 1210 Hz), variando la frequenza (e quindi la velocità di funzionamento del motore) per brevi periodi su scale di mesi, alterandone il comportamento e di fatto sabotando l’infrastruttura. (E’ comunque quantomeno curioso il fatto che alla stessa conclusione sia giunta quasi in contemporanea, una azienda di sicurezza tedesca).

Dove sta il giallo? Oltre che nella livrea Symantec che ha risolto l’arcano, il giallo risiede nel fatto che le frequenze in oggetto sono compatibili con quelle utilizzate negli impianti di arricchimento dell’Uranio. Come se non bastasse inoltre, il maggiore livello di diffusione del virus è localizzato in… Iran (con circa 60.000 host infetti, dei quali, quasi il 70% con software Siemens).

Naturalmente queste “coincidenze”, unite al fatto che il virus in oggetto è talmente raffinato da aver probabilmente richiesto risorse ingenti in fase di sviluppo (e una approfondita conoscenza degli “internals” dell’architettura SCADA), fanno pensare che alla base dell’attacco non ci sia un hacker smanettone in cerca di fama, quanto piuttosto una nazione desiderosa di frenare le velleità nucleari di un paese nemico.

Attualmente l’infezione è contenuta, tuttavia è importante notare lo scenario delineato; non solo Stuxnet ha una architettura di una complessità mai vista prima per un virus, ma per la prima volta sembrerebbe che il malware sia stato esplicitamente creato per scopi cyber-militari.

Che sia il primo passo di una nuova guerra combattuta a colpi di tasti? E’ possibile! Certo è che, a prescindere da considerazioni politiche, la scena di Indipendence Day in cui Jeff Goldbum sconfigge gli alieni iniettando un malware nella nave madre non mi stupisce più di tanto (diversamente da quanto fece nell’ormai lontano 1996). Certo mi sono sempre chiesto (e mi chiedo tutt’ora) se anche gli alieni utilizzassero il TCP-IP come protocollo di comunicazione… Ma questa è un’altra storia…

Follow

Get every new post delivered to your Inbox.

Join 2,714 other followers