Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica tesi di laurea Impatto della diversity sulla protezione di infrastrutture critiche: un framework di valutazione Anno Accademico 2012/2013 relatore Ch.mo Prof. Domenico Cotroneo correlatore Ing. Antonio Pecchia candidato Davide Cioccia matr. M63/122 Indice Introduzione IX 1 Mission critical system: sistemi controllo industriale 1 1.1 Architettura di un sistema di controllo industriale . . . . . . . . . . . 2 1.2 Supervisory Control And Data Acquisition . . . . . . . . . . . . . . . 4 1.2.1 Architettura di un sistema SCADA . . . . . . . . . . . . . . . 7 1.2.1.1 Componenti 7 1.2.1.2 Macro-regioni 1.2.1.3 Protocolli utilizzati . . . . . . . . . . . . . . . . . . . 13 1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Infrastruttura presa in esame . . . . . . . . . . . . . . . . . . . . . . 14 2 Security nei sistemi di controllo 19 2.1 Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2 Risk Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2.1 2.3 Alcuni scenari passati . . . . . . . . . . . . . . . . . . . . . . . 23 APT: Advanced Persistent Threat . . . . . . . . . . . . . . . . . . . . 25 3 Stuxnet: “tecniche di guerra digitale” 32 3.1 Un po’ di storia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.2 Architettura del threat . . . . . . . . . . . . . . . . . . . . . . . . . . 36 I 3.2.1 Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.3 Diffusione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.4 Tecniche di injection nei processi . . . . . . . . . . . . . . . . . . . . 44 3.5 Installazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.5.1 P2P sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.5.2 Control & Command Server . . . . . . . . . . . . . . . . . . . 50 3.6 Escalation Privilege . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.7 Infezione del PLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.7.1 Processo di infezione del plc . . . . . . . . . . . . . . . . . . . 56 3.7.1.1 Checking degli SDB (System Data Block) . . . . . . 57 3.7.1.2 DP_RECV replacement . . . . . . . . . . . . . . . . 57 3.7.1.3 OB1/OB35 infection . . . . . . . . . . . . . . . . . . 57 3.8 Come Stuxnet deteriora le centrifughe . . . . . . . . . . . . . . . . . 59 3.9 Lavori presenti in letteratura . . . . . . . . . . . . . . . . . . . . . . . 61 3.9.1 Analisi quantitativa . . . . . . . . . . . . . . . . . . . . . . . . 62 3.9.2 Detection del malware . . . . . . . . . . . . . . . . . . . . . . 65 3.9.3 Analisi di sistemi critici attaccabili . . . . . . . . . . . . . . . 72 4 Metodologia e modello del sistema 77 4.1 Modelli 4.2 Metodologia di analisi utilizzata . . . . . . . . . . . . . . . . . . . . . 80 4.2.1 4.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 SAN Stochastic Activity Network . . . . . . . . . . . . . . . . 81 Modello realizzato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 4.3.1 Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4.3.1.1 Assunzioni del modello . . . . . . . . . . . . . . . . . 86 4.3.1.2 Tempi e probabilità scelti per il modello . . . . . . . 87 4.3.1.3 4.3.2 Stochastic Activity Network dell’Host . . . . . . . . 89 Engineering Station . . . . . . . . . . . . . . . . . . . . . . . . 92 4.3.2.1 Assunzioni del modello . . . . . . . . . . . . . . . . . 92 4.3.2.2 Tempi e probabilità scelti per il modello . . . . . . . 93 4.3.2.3 Stochastic Activity Network di una Engineering Station . . . . . . . . . . . . . . . . . . . . . . . . . 95 4.3.3 4.3.4 PLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 4.3.3.1 Assuzioni del modello . . . . . . . . . . . . . . . . . 97 4.3.3.2 Tempi e probabilità scelti per il modello . . . . . . . 98 4.3.3.3 Stochastic Acitivity Network di un PLC . . . . . . . 99 Architettura completa . . . . . . . . . . . . . . . . . . . . . . 100 5 Analisi e simulazione del modello 102 5.1 Simulazione del modello . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.2 Sensitivity Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 5.2.1 ANOVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 5.2.1.1 Applicazione di ANOVA al modello . . . . . . . . . . 107 5.3 Analisi ed esperimenti in presenza di diversity . . . . . . . . . . . . . 109 5.4 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Bibliografia 125 Elenco delle figure 1.1.1 Schema ICS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2.1 Componenti di un PLC . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.3.1 Architettura presa in esame . . . . . . . . . . . . . . . . . . . . . . . . 17 2.2.1 Interdipendenza tra i settori . . . . . . . . . . . . . . . . . . . . . . . . 23 2.2.2 Percentuale di perdita in caso di attacco ad uno dei settori nell’economia statunitense . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.2.3 Harm Reference Table . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.3.1 Evoluzione dei tool d’attaco e riduzione delle competenze di un attacker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.1.1 Diffusione del virus[14] . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.1.2 Diffusione geografica di Stuxnet[14] . . . . . . . . . . . . . . . . . . . 34 3.2.1 Export utilizzate da Stuxnet[14] . . . . . . . . . . . . . . . . . . . . . 37 3.3.1 Struttura di un file .LNK . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.4.1 Processi utilizzati da Stuxnet per l’injection . . . . . . . . . . . . . . 45 3.5.1 Export 15 utilizzata per la prima fase dell’installazione . . . . . . . . 46 3.5.2 Comunicazione P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.5.3 Alcuni comandi del C&C Server . . . . . . . . . . . . . . . . . . . . . 53 3.7.1 FSM del processo di corruzione di un PLC . . . . . . . . . . . . . . . 58 3.8.1 Flusso di infezione del PLC . . . . . . . . . . . . . . . . . . . . . . . . 61 IV 3.9.1 CTMs individuali del modello . . . . . . . . . . . . . . . . . . . . . . . 63 3.9.2 Modello BDMP della diffuzione del virus . . . . . . . . . . . . . . . . 65 3.9.3 HoneyFarm ibrida per la difesa contro worm . . . . . . . . . . . . . . 66 3.9.4 Clustering degli algoritmi . . . . . . . . . . . . . . . . . . . . . . . . . 67 3.9.5 Protocol Learning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 3.9.6 Ambiente simulativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 3.9.7 Risultato attacchi SMART GRID . . . . . . . . . . . . . . . . . . . . 74 3.9.8 Architettura presa in esame per il primo caso di studio . . . . . . . . 75 3.9.9 Architettura presa in esame per il secondo caso di studio . . . . . . . 76 4.1.1 Formalismi e potenza espressiva . . . . . . . . . . . . . . . . . . . . . 80 4.2.1 Elementi SAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.2.2 Attività e collegamenti in una rete SAN . . . . . . . . . . . . . . . . . 84 4.3.1 Possibilità di infezione di un host . . . . . . . . . . . . . . . . . . . . . 87 4.3.2 Rete SAN dell’Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 4.3.3 Collegamento tra Engineering Station e PLC . . . . . . . . . . . . . . 93 4.3.4 Rete SAN di una Engineering Station . . . . . . . . . . . . . . . . . . 96 4.3.5 SAN di un PLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 4.3.6 Composizione del modello . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.1.1 Probabilità di compromissione di un sistema mission critical sotto attacco Stuxnet-like . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.2.1 Calcolo del D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 5.2.2 Screening degli effetti sugli esperimenti effettuati sul modello. . . . . 109 5.3.1 Grafico della tabella 5.3 . . . . . . . . . . . . . . . . . . . . . . . . . . 111 5.3.2 Grafico della tabella 5.4 . . . . . . . . . . . . . . . . . . . . . . . . . . 112 5.3.3 Grafico della tabella 5.5 . . . . . . . . . . . . . . . . . . . . . . . . . . 113 5.3.4 Grafico della tabella 5.6 . . . . . . . . . . . . . . . . . . . . . . . . . . 114 5.3.5 Grafico della figura 5.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 5.3.6 Grafico della tabella 5.8 . . . . . . . . . . . . . . . . . . . . . . . . . . 117 5.3.7 Gragico tabella 5.9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 5.3.8 Probabilità di successo di un attacco Stuxnet-like su sistemi con diverse configurazioni e O.S.. . . . . . . . . . . . . . . . . . . . . . . . 119 5.3.9 Probabilità di like sistemi su successo con di un configurazioni attacco di Stuxnet- diversity su RestorePC,FirewallPermission,InfectOtherUSB . . . . . . . . . . . . . 121 5.4.1 Vulnerabilità in comune tra i diversi OS . . . . . . . . . . . . . . . . . 123 Elenco delle tabelle 2.1 Classificazione rischi e minacce . . . . . . . . . . . . . . . . . . . . . . 22 3.1 Stuxnet Timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.1 Probabilità e TTS delle attività del modello Host . . . . . . . . . . . 88 4.2 Probabilità e TTS delle attività del modello Engineering Station . . . 94 4.3 Probabilità e TTS delle attività del modello PLC . . . . . . . . . . . 98 5.1 Probabilità di attacco in 12 mesi 5.2 Valori di probabilità per la sensitivity analysis . . . . . . . . . . . . . 105 5.3 Probabilità di compromissione del sistema in presenza di diversity . . . . . . . . . . . . . . . . . . . . 104 sulla configurazione negli host . . . . . . . . . . . . . . . . . . . . . . 110 5.4 Probabilità di compromissione del sistema in presenza di diversity sulla configurazione nelle engineering station . . . . . . . . . . . . . . 112 5.5 Probabilità di compromissione del sistema in presenza di diversity nella enterprise network . . . . . . . . . . . . . . . . . . . . . . . . . 113 5.6 Probabilità di compromissione del sistema con diversity sul sistema operativo all’interno della Control Network . . . . . . . . . . . . . . . 114 5.7 Probabilità di compromissione del sistema con diversity sul Sistema Operativo e sui software utilizzati negli host della Enterprise Network 115 5.8 Probabilità di compromissione del sistema con diversity sul Sistema Operativo e sui software utilizzati negli host della Control Network . 116 VII 5.9 Probabilità di compromissione del sistema con diversity sul Server di gestione del DB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Introduzione Ci sono molti modi , nel XXI secolo, per combattere una guerra, al punto che la maniera classica, ovvero quella militare, ci appare superata e senza alcun interesse. Lo scalpore suscitato dalla Wehrmacht, durante il secondo conflitto mondiale, per la velocità di azione, la novità delle armi di moderna concezione, i piani di attacco imprevedibili ed efficaci o dall’imponente sbarco in Normandia, con il colossale dispiegamento di mezzi ed armi mai visto prima, sembrano lontanissimi e facenti parte di quel “secolo breve” ormai chiuso e lasciato definitivamente alle spalle. Oggi, le classiche forme di guerra, da quella economico-commerciale a quella diplomatica, , sono state affiancate, con i progressi in campo tecnologico, da strategie belliche a dir poco rivoluzionarie. Ultimamente, e non del tutto a caso, si fa un gran parlare di media e cyber wars, due nuove modalità di lanciare offensive contro Paesi che utilizzano le nuove tecnologie. Guerra totale e paralizzante, che senza spargere sangue di innocenti, mette in ginocchio il Paese sotto attacco. Andiamo però nel dettaglio e prendiamo come esempio il controverso programma nucleare iraniano. Teheran, come è noto , ha da tempo deciso di portare avanti un proprio programma atomico, ufficialmente pacifico, fatto questo, ritenuto intollerabile da Israele e dall’Occidente in generale, che non crede assolutamente ai proclami pacifisti della Repubblica Islamica mediorientale. Attaccare militarmente l’Iran però, cercando di prevenire il danno di una IX offensiva nucleare, non conviene; troppo alto sarebbe il prezzo da pagare in vite umane, e ,soprattutto, troppo imponderabili le conseguenze a cui si potrebbe andare incontro . E’ in questo scenario che nasce Stuxnet, forse la più potente cyber-weapon mai realizzata dall’uomo. Negli ultimi anni si è assistito ad un notevole aumento di attacchi condotti verso sistemi critici . La diffusione e l’importanza di stistemi di controllo industriale come base delle infrastrutture mondiali come energia,acqua, trasporti, telecomunicazioni, oleodotti, impianti di produzione e costruzione, ha contribuito al parallelo sviluppo di malware sempre più sofisticati capaci di danneggiare, o perfino distruggere, intere centrali e creare ingenti danni economici o fisici (basti pensare alle conseguenze di un’esplosione di una centrale nucleare) e tensioni diplomatiche tra Paesi diversi. Una vera e propria arma capace di colpire in ogni momento senza che nessuno se ne accorga. L’obiettivo della tesi riguarda lo studio e l’analisi di infrastrutture critiche attaccate da malware Stuxnet-like tramite l’utilizzo del formalismo delle reti SAN, con lo scopo di proporre un sistema intrusion-tolerant basato su meccanismi di diversity. Il lavoro di tesi si articola in cinque capitoli di cui nel seguito se ne fornisce una rapida descrizione: • Capitolo 1: introduce brevemente alcuni concetti sulle infrastrutture critiche. Vengono fornite alcune importanti definizioni e aspetti salienti che le contraddistinguono, partendo dalle funzionalità principali fino ad arrivare all’intero sistema. Infine viene fornita una descrizione dell’architettura presa in esame per lo svolgimento del lavoro • Capitolo 2: descrive lo stato dell’arte della sicurezza nei sistemi di controllo industriale, focalizzandosi sui rischi ed i danni causati, e che potrebbero causare, malware Stuxnet-like. Fornisce,infine, una panoramica sui lavori presenti in letteratura. • Capitolo 3: fornisce un’ampia descrizione del malware Stuxnet at- traversandone le diverse fasi e focalizzandosi sulle attività prese in considerazione. • Capitolo 4: fornisce ,in primis, una panoramica dei vari modelli presenti in letteratura per l’analisi della dependability di sistemi per poi focalizzarsi sul formalismo delle reti SAN. Vengono presentati i singoli modelli realizzati tramite SAN, ed una loro combinazione per la costruzione del modello finale. • Capitolo 5: descrive gli esperimenti effettuati ed i risultati ottenuti seguendo l’approccio proposto: Sensitivity Analysis Analisi dela varianza dei risultati della sensitivity analysis Studio dei tempi di fallimento Risultati con e senza diversity Capitolo 1 Mission critical system: sistemi controllo industriale Lo sviluppo, la sicurezza e la qualità della vita nei paesi industrializzati dipendono sempre più dal funzionamento, continuo e coordinato, di un insieme di infrastrutture che, per la loro importanza, sono definite Infrastrutture Critiche. Con il termine infrastruttura critica si intende un sistema, una risorsa, un processo, un insieme, la cui distruzione, interruzione, anche parziale o momentanea indisponibilità ha l’effetto di indebolire in maniera significativa l’efficienza di un intero Paese e di inibirne il normale funzionamento,il sistema economico-finanziario e sociale .Gli ambiti in cui si può parlare di Infrastrutture Critiche sono essenzialmente: • Produzione, trasmissione, distribuzione, dispacciamento dell’energia elettrica e di tutte le forme di energia, quali ad esempio il gas naturale • Telecomunicazioni e telematica; • Risorse idriche e gestione delle acque reflue; • Agricoltura, produzione delle derrate alimentari e loro distribuzione; • Sanità, ospedali e reti di servizi e interconnessione; 1 • Trasporti aereo, navale, ferroviario, stradale e la distribuzione dei carburanti e dei prodotti di prima necessità; • Banche e servizi finanziari; • Sicurezza, protezione e difesa civile (forze dell’ordine, forze armate, ordine pubblico); • Le reti a supporto del Governo, centrale e territoriale e per la gestione e delle Emergenze. La diffusione sempre maggiore di questi sistemi, anche se ha consentito di migliorare la qualità dei servizi erogati e contenerne i costi, ha tuttavia indotto in queste infrastrutture nuove e impreviste vulnerabilità, dovute sopratturro all’utilizzo di sistemi general-purpose. Guasti tecnici, disastri naturali ed eventi dolosi, se non addirittura terroristici, potrebbero avere degli effetti devastanti. 1.1 Architettura di un sistema di controllo industriale Un sistema di controllo industriale rappresenta il fulcro delle infrastrutture critiche, che si basano sempre più su sistemi di telecomunicazione per garantirne un pieno controllo anche da postazioni remote. Sulla base delle informazioni ricevute dalle stazioni infatti, è possibile inviare comandi (in maniera automatica o tramite operatore) direttamente agli strumenti di controllo atti a gestire il corretto funzionamento di elementi elettromeccanici. L’intero processo industriale è il fenomeno che gli operatori cercano di controllare. Esso può essere suddiviso in una serie di problemi di controllo più piccoli. Ad esempio un impianto di produzione di una particolare sostanza chimica in un reattore, può richiedere sia il controllo della temperatura e della pressione della reazione, sia il volume dei reagenti. Ciascun elemento può essere considerato un piccolo sotto-problema di controllo, risolto tramite controllori locali impegnati nella manutenzione di ciascuna variabile entro dei limiti operativi. Una generica architettura di un sistema di controllo può essere rappresentata tramite lo schema in Figura 1.1.1 Figura 1.1.1: Schema ICS In questo schema semplificato è possibile osservare come tutte le operazioni abbiano come fulcro centrale il Controller, che in questo caso è rappresentato dai PLCs. Il processo controllato può rappresentare ad esempio la rotazione di una ventola di raffreddamento, la tensione su un elemento elettrico, la temperatura interna di un reattore e così via. Per tenere sotto osservazionel’intero processo, un ICS è dotato di HMI (Human Machine Interface), sia locali che remote, che consentono all’operatore di prendere decisioni tempestive in base ai dati provenienti dal Controller. Le diverse misurazioni effettuate, vengono trasmesse dai sensori al controllore, il quale interpreta i segnali e genera i comandi da inviare agli attuatori. La HMI consente ad un ingegnere o all’operatore di configurare gli algoritmi di controllo ed i parametri nel controllore. La HMI fornisce inoltre la visualizzazione delle informazioni riguardanti lo stato del processo, compresi allarmi ed altri strumenti per il corretto ripristino in seguito a malfunzionamenti. Oltre alle generiche HMI, ci sono altri elementi che possono essere inclusi in una configurazione di un sistema di controllo industriale: • Sistemi di controllo distribuito (DCS) • PLC : computer di controllo del processo industriale • Supervisory Control And Data Acquisition (SCADA): sistemi altamente distribuiti per l’analisi ed il controllo dei dati provenienti dai sensori • Control Server: server che ospita i software per il controllo • Master Terminal Unit (MTU): componente che agisce come master in un sistema SCADA. • Remote Terminal Unit (RTU): unità di controllo progettato per supportare le stazioni di controllo SCADA • Dispositivi elettronici “intelligenti” (IED): sensore od attuatore capace di prendere decisioni • Historian Database: DB che registra tutte le informazioni di processo 1.2 Supervisory Control And Data Acquisition Focalizziamo la nostra attenzione sui sistemi SCADA, in quanto rappresentano i sistemi più colpiti negli ultimi tempi.Un sistema SCADA svolge tre funzionalità principali all’interno di un sistema di controllo industriale, ovvero: 1. Acquisizione 2. Supervisione 3. Controllo Acquisizione L’acquisizione dati entra nella definizione di sistema SCADA perché non è possibile eseguire funzioni di supervisione senza acquisire informazioni sullo stato in cui si trova il processo osservato, così come l’unico modo per orientarne il comportamento è quello di influenzare lo stato cambiando il valore dei parametri che lo caratterizzano. La funzione di acquisizione dati di un sistema SCADA è considerata generalmente una funzione di scambio puro e semplice di informazioni, tra la parte di sistema che realizza supervisione e controllo ed il processo controllato. Si assume che nessun processo decisionale abbia luogo tra le strutture di supervisione e controllo ed il processo controllato. Nei casi in cui questa condizione non è soddisfatta abbiamo sistemi che realizzano qualcosa di diverso (strutture ad intelligenza distribuita), rispetto ad un sistema SCADA inteso in senso classico. Supervisione La supervisione è la funzione per mezzo della quale un sistema SCADA rende possibile l’osservazione dello stato e dell’evoluzione del processo controllato. A questa funzione appartengono tutte le funzionalità di visualizzazione delle informazioni relative allo stato attuale del processo, di gestione delle informazioni storiche, di gestione degli stati che costituiscono eccezioni rispetto alla normale evoluzione del processo controllato. La funzione di supervisione è uno degli obiettivi di un qualsiasi SCADA. Questa funzione è una di quelle che caratterizzano un sistema, nel senso che un sistema che non permette di accedere alle informazioni di stato corrente e/o storiche del processo osservato e/o controllato non può essere classificato come sistema SCADA. Controllo La funzione di controllo rappresenta la capacità di un sistema di prendere decisioni, relative all’evoluzione dello stato del processo controllato, in funzione dell’evoluzione del processo medesimo. La modalità con la quale le procedure di controllo vengono realizzate, nell’ambito dell’intera architettura del sistema, dipende fortemente dal tipo di processo, perché esso può imporre scelte architetturali sia hardware che software. In questo senso, i sistemi SCADA sono comunemente intesi come sistemi che hanno, nella funzione di acquisizione dati, l’intera catena di acquisizione che dai sensori veicola informazioni al sistema di elaborazione ed archiviazione. Un largo uso di sistemi di supervisione e controllo è fatto nell’ambito del controllo del traffico (aereo, ferroviario, automobilistico), della gestione dei sistemi di trasporto dei fluidi (acquedotti, gasdotti, oleodotti, ...), della distribuzione dell’energia (reti di trasmissione dell’energia elettrica), della gestione delle linee di produzione che realizzano i processi industriali, del telerilevamento ambientale. Questo comporta il rispetto di requisiti molto stringenti per i sistemi di controllo. In particolare possiamo individuare tre caratteristiche fondamentali: • Realtime Il termine realtime si riferisce alla capacità del sistema di reagire alle sollecitazioni del processo con ritardi trascurabili rispetto alla dinamica evolutiva del processo stesso. Allo stesso tempo la reazione del sistema deve essere caratterizzata da tempi di elaborazione compatibili con quelli imposti dagli obiettivi del controllo. Un sistema real-time è sottoposto a vincoli molto stringenti in termini di tempo. In particolare bisogna rispettare le deadline previste durante l’esecuzione. • Reliability Nella realizzazione di un sistema è necessario tenere in considerazione l’affidabilità dei singoli componenti per provvedere alla eventuale implementazione di contromisure destinate a contenere l’influenza che un dato sottosistema ha sull’affidabilità dell’architettura complessiva. • Availability L’availability è la percentuale di tempo per la quale deve essere assicurato lo stato di esercizio del sistema, cioè il valore complementare della percentuale di tempo in cui il sistema è in stato di fermo a causa di guasti, manutenzioni, aggiornamenti, altro. La disponibilità può essere riferita all’intero sistema o a parti critiche dello stesso e, come le altre, è una caratteristica che si esprime in vincoli che differiscono in funzione del tipo di processo da controllare. 1.2.1 Architettura di un sistema SCADA Dopo aver esaminato le caratteristiche di un sistema di acquisizione e controllo dati, passiamo all’analisi di una generica architettura SCADA, focalizzando l’attenzione sui principali componenti che ne caratterizzano il comportamento. Possiamo subito fare una prima differenza tra componenti del sistema ed interconnessioni tra di essi. Analizzando architetture reali, un sistema SCADA si suddivide in diverse macro-regioni con differenti livelli di sicurezza e differenti dispositivi : 1.2.1.1 Componenti Un sistema SCADA è costituito principalmente da: • RTU Una RTU (acronimo di Remote Terminal Unit - Unità Terminale Remota) è un dispositivo elettronico di controllo a microprocessore che interfaccia oggetti del mondo fisico a un sistema di controllo distribuito o uno SCADA attraverso la trasmissione di dati acquisiti dalla strumentazione collegata al sistema di supervisione. In alcune occasioni la RTU è indicata come remote telemetry unit - unità telemetrica remota. La RTU può essere interfacciata con il sistema di supervisione centrale con diversi mezzi di comunicazione - in genere seriale (RS232, RS485, RS422), Ethernet. GPS o GPRS. Generalmente le RTU sono in grado di supportare i protocolli standard (Modbus, IEC 60870-5 -101/103/104, DNP3 , IEC 60870-6 -ICCP, IEC 61850 , ecc) per interfacciare qualsiasi software di terze parti. In alcune applicazioni di controllo, le RTU sono in grado di pilotare unità esterne di campo attraverso una uscita digitale. Le principali applicazioni di una RTU sono: monitoraggio ambientale monitoraggio stazioni di pompaggio monitoraggio siti minerali sistemi di allarme monitoraggio impianti petroliferi,nucleari • MTU È il componente principale di un’architettura SCADA, in quanto riceve tutte le informazioni provenienti dalle singole RTU e le smista ai diversi dispositivi di controllo ed alle HMI. Opera mediante procedure schedulate eseguite ad intervalli di tempo preimpostati ed è munito di dispositivi di archiviazione dati e di backup. Tipicamente "parla" con l’Host System o su rete di comunicazione locale, o per via seriale utilizzando trasmissioni a distanza. Recentemente i sistemi Scada hanno visto una evoluzione strutturale,con l’unione delle funzioni di Host System e di Mtu in una unica entità (tipicamente un PC). Oggi il concetto di Mtu come unità separata è in qualche modo superato, ma si ritiene opportuno continuare a considerarlo perché a volte è presente o previsto in particolare circostanze. Infatti si parla di Operator System, come una macchina capace di offrire operazioni tipiche di un HMI e di un MTU. Un Operator System consente la conduzione sicura del processo da parte del personale operativo. L’operatore può sorvegliare lo svolgimento del processo attraverso diverse viste ed intervenire all’occorrenza con comandi opportuni. La base per questo è costituita da Operator Station perfettamente sintonizzate tra loro per sistemi monostazione (OS Single Station) e per sistemi multistazione in architettura Client-Server. Gli OS client potrebbero anche essere remoti e non presenti all’interno della stessa architettura. I server svolgono anche funzioni client, in quanto permettono l’accesso a dati contenuti in altri server. Essi possono essere collegati tramite una semplice rete Ethernet. Ogni OS fa anche da archivio a breve termine delle informazioni basato sull’utilizzo del database Microsoft SQL-Server. Queste informazioni potranno poi essere dislocate in archivi a lungo termine. • PLC I dispositivi atti ad interagire con il processo fisico sono detti PLC (Programmable Logic Controllers) ed hanno il compito di controllare il processo rispettando tempi molto stretti che potremmo definire critici. La prima azione che il PLC compie è la lettura degli ingressi del portale,ovvero intendiamo tutti gli ingressi sia digitali che analogici, on board o su bus di campo (schede remote collegate al PLC o con una rete di comunicazione). Dopo aver letto tutti gli ingressi, il loro stato viene memorizzato in una memoria che è definita "Registro immagine degli ingressi". A questo punto le istruzioni di comando vengono elaborate in sequenza dalla CPU e il risultato viene memorizzato nel "Registro immagine delle uscite". Infine, il contenuto dell’immagine delle uscite viene scritto in output. Poiché l’elaborazione delle istruzioni si ripete continuamente, si parla di elaborazione ciclica; il tempo che il controllore impiega per una singola elaborazione viene detto tempo di ciclo (solitamente varia da 10 a 100 millisecondi). Figura 1.2.1: Componenti di un PLC I PLC possono essere collegati tra di loro tramite reti che sfruttano standard industriali come Profibus, Profinet, Modbus, EGD, DeviceNet. Il PLC per rispondere ai suoi compiti deve essere programmato. La programmazione del PLC è effettuata normalmente con un PC sul quale un software specializzato permette di creare programmi da scaricare nella memoria della CPU del PLC. Questi software di programmazione possono leggere il programma direttamente dalla memoria della CPU, e visualizzare il programma sul PC. Normalmente le istruzioni vengono scritte su PC, scaricate sul PLC, e salvate sul PC stesso, per ulteriori modifiche o per sicurezza. Per quanto riguarda la scrittura delle varie operazioni, abbiamo due tipi di linguaggi proposti dagli standard: Linguaggi grafici: ∗ Ladder Diagram ∗ Sequential Function Chart Linguaggi testuali ∗ Testo strutturato ∗ Istruction List Un PLC può prendere decisioni in base ai valori ricevuti dai sensori ed effettuare azioni tramite l’utilizzo di attuatori. • HMI Una HMI ha il compito di fornire trend, dati diagnostici ed informazioni di gestione, come procedure di manutenzione programmata, informazioni logistiche, schemi dettagliati per un particolare sensore o di una macchina, e guide per la risoluzione dei problemi. Il sistema HMI presenta solitamente le informazioni al personale tramite interfaccia grafica, detta quadro sinottico. Ciò significa che l’operatore può vedere una rappresentazione schematica dell’impianto controllato. I quadri sinottici possono essere costituiti da grafica lineare e simboli schematici per rappresentare elementi di processo, o possono essere costituiti da fotografie digitali di apparecchiature di processo a cui sono sovrapposti simboli animati. Il pacchetto per il sistema HMI SCADA in genere include un programma di disegno che gli operatori o il personale di manutenzione del sistema utilizzano per modificare il modo in cui vengono rappresentati questi punti nell’interfaccia. Queste rappresentazioni possono essere semplici come sullo schermo un semaforo, o complesso come un display che rappresenta la posizione di tutti gli ascensori in un grattacielo o tutti i treni su una linea ferroviaria. Una parte importante della maggior parte delle implementazioni SCADA è la gestione degli allarmi. Il sistema controlla se le condizioni di allarme siano soddisfatte, per determinare quando un alert si verifica . Una volta che un alert è stato rilevato, vengono effettuate delle operazioni per riportare il sistema in normale operatività. Il sistema SCADA può automaticamente controllare se il valore in un punto di riferimento si trova al di fuori dei valori limite associati a tale punto. Esempi di indicatori di allarme sono una sirena, una finestra pop-up box su uno schermo, o una zona colorata o lampeggiante su uno schermo (che potrebbe agire in modo simile al "serbatoio vuoto" luce in una macchina). In ogni caso , il ruolo dell’ indicatore di allarme è di attirare l’attenzione dell’operatore alla parte del sistema ’in allarme’ in modo che possa essere intrapresa l’azione appropriata. 1.2.1.2 Macro-regioni All’interno di uno SCADA system, è possibile individuare diverse regioni con livelli di sicurezza sempre più stringenti. In particolare è possibile isolare quattro zone: 1. Enterprise Network L’Enterprise Network (detta anche Corporate Network) è la zona che ospita business users e sistemi di pianificazione (come ad esempio sistemi ERP). In particolare, in questa sottorete ogni host gode di un accesso ad Internet ed è in comunicazione con la rete sottostante. Tutti gli host in questa rete non possono modificare i sistemi di controllo di processo ma possono verificarne il comportamento tramite HMI e strumenti di data-mining. 2. Perimeter Network Al suo interno sono presenti server che forniscono patch sia agli elementi della Control Network che della Enterprise Network. Inoltre è possibile ritrovare Database per la raccolta delle informazioni provenienti dalla Control Network. 3. Manifacturing Operations Network Rappresenta la zona di scambio informazioni tra l’Enterprise Network e la Control Network. Ospita server per la genstione delle informazioni ed operazioni di data mining. 4. Control Network Rappresenta la rete di controllo del processo fisico, tramite la quale è possibile inviare comandi ai PLC e modificarne il comportamento. Al suo interno ritroviamo le Engineering Station e server per la raccolta e l’elaborazione dei dati. 1.2.1.3 Protocolli utilizzati Per realizzare i collegamenti tra le macro-regioni, si utilizzano principalmente due diversi standard: 1. IEEE 802.3 (Industrial Ethernet) Industrial Ethernet si è affermato anche come standard dominante nella tecnologia delle reti industriali. Con uno standard tecnico universalmente valido alla base, i produttori sono in grado di combinare tra loro le reti estese e le parti d‘impianto che stanno a monte. Le carateristiche principali per cui si effettua una scelta del genere sono: • Interoperabilità dei sistemi • Accesso diretto dei dati di produzione nell’ambiente ufficio, non più interfacce • Fornitura e gestione semplificate delle parti di ricambio • Know-how unico (funzionamento e riparazione). Il know-how disponibile per la gestione di reti Ethernet può essere utilizzato anche in fabbrica. • Velocità superiore e maggiore larghezza di banda offrono nuovi spazi per diverse applicazioni (ad esempio per la trasmissione di dati di immagini o per uso parallelo di risorse di rete). • Lo standard TCP/IP di Ethernet consente interfacce web, ad esempio per manutenzione o messa a punto della macchina. • Tecnologia Web-Based orientata al futuro. 2. Profibus Profibus non è altro che una rete di comunicazione monomaster multi slave. Permette la riduzione del cablaggio richiesto tra i nodi costituenti la rete in quanto necessita del posizionamento di un unico cavo. Generalmente viene utilizzato per connettere un master come un PLC ad I/O remoti. I cavi profibus sono schermati, generalmente si presentano di colore viola, sotto la guaina viola c’è la schermatura e dentro una coppia di cavi di colore rosso e verde. La topologie di rete implementabile può essere solo seriale. I dati vengono veicolati nella rete attraverso una politica token ring. Profibus è l’acronimo di Process Field Bus. Si tratta di un bus di campo (field bus) messo a punto nel 1989 da un consorzio di diverse aziende tra le quali Siemens. Le sue applicazioni sono nel campo dell’automazione industriale e di processo. Abbiamo tre famiglie differenti per quanto riguarda questo tipo di bus: • Profibus-DP è stato sviluppato dalla siemens per estendere il campo applicativo di profibus all’ambito di sensori / attuatori • Profibus-FMS È il risultato di un progetto congiunto promosso dal Ministero Tedesco per la scienza e la tecnica con principali aziende tedesche leader nel settore (Siemens,Bosch e Moller) • Profibus-PA Nasce grazie a Siemens per migliorare la sicurezza e l’interfunzionalità di sistemi di campo nell’industria di processo. 1.3 Infrastruttura presa in esame Per condurre lo studio di questa tesi, è stata presa in considerazione una ricostruzione ipotetica del sistema SCADA interno alla centrale nucleare di Natanz, ricostruito dalla società Tofino Security e da alcuni studi presenti in letteratura. Sono state effettuate alcune analisi sulle diverse implementazioni presenti e sono state rilevate delle differenze nei collegamenti tra Enterprise Network e Control Network. In alcune documentazioni, le due LAN non presentano alcuna separazione, in quanto collegate tramite router industriali, mentre ,in altre, la separazione tra le due viene effettuata tramite un Air Gap, ovvero una vera e propria divisione fisica delle due zone d’interesse. Air Gap Un air Gap è una misura di sicurezza tra due PC o due reti, che devono essere straordinariamente sicuri. Si tratta di un vero e proprio isolamento fisico da altre LAN e da reti pubbliche come Internet. Lo scambio di dati in presenza di un air gap può avvenire solo tramite dispositivi removibili come flash USB, Hard Disk esterni, CD,DVD e simili. In alcuni casi però, non si tratta di una vera e propria separazione fisica ma prevede l’uso di elementi crittografici dedicati, che possono evitare il tunneling di pacchetti o la variazione di dimensione. Nel caso di una separazione fisica si parla di “Sneaker-net”, facendo riferimento al fatto di dover indossare delle scarpe da ginnastica per trasferire i dati da un PC ad un altro. Per realizzare un modello semplificato rispondente ad un’architettura reale, sono state prese in considerazione entrambe le soluzioni. In pratica si è supposto che il passaggio di dati tra Enterprise network e Control Network possa avvenire soltanto tramite l’utilizzo di dispositivi removibili e lettura da database. All’interno della ricostruzione sono state prese in considerazione tre elementi differenti: • Operator System (OS) • Automation System (AS) • Engineering System (ES) L’OS permette la sicura interazione tra l’operatore ed il processo sotto controllo. L’operatore può , con varie tecniche, analizzare i dati provenienti dal processo e manipolarli. L’OS consiste in un’architettura client-server che può essere implementata all’interno di una stessa piattaforma o in remoto. L’AS è il nome dato alla classe di PLC utilizzati per il processo fisico. In particolare il termine comprende sia la parte software utilizzata per il controllo del PLC che il dispositivo stesso. L’ES consistono in un software che è responsabile di configurare i diversi PLC presenti all’interno della Control Network. In particolare le funzioni svolte da questi terminali sono molteplici: • Hardware di controllo che include disposistivi di i/o • Reti di comunicazione • Funzioni automatizzate per processi continui e batch • funzionalità HMI • Applicazioni sicure (Safety Integrated for Process Automation) • Diagnostica ed attività di management • Processi batch Questi tre elementi presenti all’interno di un sistema SCADA sono stati collocati a loro volta in tre aree differenti viste nel paragrafo precedente: • Enterprise Network • Manifacturing Operation Network • Control Network Figura 1.3.1: Architettura presa in esame Andiamo ad analizzare i singoli elementi dell’architettura presa in esame: Host della Enterprise Network : Si tratta di PC con sistema operativo Windows dotato di connessione ad internet. Le funzionalità svolte da questo tipo di macchina sono: • HMI (Human Machine Interface) • Office Workstation • Interfaccia allarmi e pianificazione manutenzione • Application Server • Print Server Connessione Internet Engineering Station: questo tipo di macchina rappresenta l’unico mezzo per programmare i PLC e ricevere dati da essi. È proprio tramite questi PC che Stuxnet riesce a modificare il comportamento dei PLC e compromettere la mission del sistema. Database Server che raccoglie tutte le informazioni sul processo industriale e consente la memorizzazione dei progetti Step7 destinati ai PLC. PLC Dispositivo USB. Indica l’unica possibilità di trasferimento dati tra la Enterprise Network e Control Network. Capitolo 2 Security nei sistemi di controllo I processi di controllo ed i sistemi SCADA, sono da sempre stati considerati immuni da attacchi di rete, grazie all’utilizzo di hardware specifici e reti proprietarie. Ma proprio negli ultimi anni l’apertura dell’architettura a standard internazionali come Ethernet, TCP/IP, e tecnologie web, ha reso sempre più “appetibili” questi sistemi. Il concetto di SCADA nasce con lo scopo di garantire requisiti come: • Affidabilità • Massimizzazione delle funzionalità • Rispetto tempi critici • Lungo ciclo di vita • Disponibilità ma mai con requisiti di sicurezza. Come risultato, le prestazioni, l’affidabilità, la flessibilità dei sistemi distribuiti di controllo risultavano molto robusti, mentre la sicurezza presentava enori falle. Questo rende alcune reti SCADA potenzialmente vulnerabili a interruzioni del servizio, reindirizzamento di processo, o manipolazione dei dati operativi che potrebbero provocare problemi di sicurezza pubblica e gravi perturbazioni alle infrastrutture 19 critiche. Proteggere i sistemi e le informazioni è oggigiorno fondamentale in ogni attività , in quanto i danni che possono causare gli errori nei sistemi di controllo possono essere davvero catastrofici (basti pensare ad un incidente all’interno di una centrale nucleare , o ad un blackout di infrastrutture per il controllo del traffico aereo). 2.1 Risk Analysis L’Analisi del Rischio è un complesso processo di analisi e valutazione dei rischi, caratterizzato da una serie di valutazioni eseguite nell’ ambito della sicurezza per identificare minacce, vulnerabilità del sistema, interdipendenze tra i diversi componenti e per prevedere contromisure reattive preventive efficaci. La concettualizzazione più generale identifica il rischio come la probabilità attesa che una minaccia possa trasformarsi in danno, comportando così un determinato impatto sul sistema. La minaccia viene definita come un evento di natura dolosa o accidentale che, sfruttando una o più vulnerabilità del sistema, potrebbe provocare un danno a cose o persone. In questo lavoro di tesi consideriamo una minaccia dolosa provocata dall’immissione di codice malevolo all’interno di un intero sistema. Per vulnerabilità invece si intende una debolezza, intrinseca o dovuta a condizioni di esercizio, che possa essere sfruttata da una minaccia per arrecare danno. Il processo di Risk Analysis prevede tre fasi fondamentali: 1. Analisi preliminare: l’obiettivo è identificare le funzionalità del sistema e gli asset da proteggere. Le attività da sostenere sono: • Individuazione dell’ambito applicativo (dominio da analizzare, responsabilità dei diversi attori, etc..); • Individuazione e descrizione dell’applicazione sottoposta all’analisi del rischio (obiettivi, funzionalità principali, architettura, etc..); • Descrizione funzionale del sistema; • Selezione dell’insieme degli asset da proteggere; • Elenco degli episodi trascorsi di incidenti legati alla sicurezza degli asset. 2. Threat Analysis: individuazione delle minacce che possono colpire gli asset.Per ogni asset bisogna seguire alcuni passi: • Selezione degli attacchi generali che riguardano l’asset; • Derivazione e descrizione delle minacce rispetto al caso specifico; • Costruzione di scenari rappresentativi dei potenziali attacchi mossi contro l’asset; • Identificazione delle vulnerabilità sfruttate dall’attaccante. 3. Risk assessment: l’obiettivo è valutare il rischio associato ad ogni minaccia e determinare se può essere o meno accettabile rispetto all’impatto ed alla potenzialità dell’attacco. Il risk assessment fornirà dunque uno strumento di misura delle priorità degli attacchi, allo scopo di stabilire gli interventi principali per la protezione delle risorse. L’avvento di Stuxnet ha dimostrato che tutti i sistemi sono vulnerabili quando gli aggressori hanno le risorse chiave ed il tempo sufficiente.Stuxnet fornisce una metrica sulla fascia alta della scala di rischio. Questo livello di rischio non è una novità ; in realtà abbiamo sempre saputo che era possibile, ma l’avvento di Stuxnet ha trasformato questo rischio finale da una remota possibilità a qualcosa di molto reale. Molte aziende ed organizzazioni considerano molto improbabile un attacco Stuxnet-like sui loro sistemi ed è per questo che non prendono le necessarie precauzioni per limitarlo.Questa decisione è anche ,”forzata”, dall’alto costo dell’investimento da sostenere. Trovare un compromesso tra rischio ed investimento, non è sempre semplice; è necessario considerare i livelli di probabili minacce, i costi di implementazione,i costi di manutenzione ed aggiornamento sia software che hardware. Attualmente, le aziende spendono oltre il 2% del loro budget ICS in sicurezza informatica, senza contare i costi del personale interno. In futuro, la sicurezza informatica andrà, sicuramente, ad occupare una quota maggiore nel bilancio ICS dell’azienda. Attualmente un’azienda spende circa il 3,5 per cento del suo budget IT in materia di sicurezza informatica. La spesa maggiore è legata principalmente alla definizione di regole più restrittive e pene più adeguate alla natura dinamica della sicurezza , e all’evoluzione delle tecnologie di security. Gli studi sulla vulnerabilatà delle infrastruttura di solito prendono in considerazione soltanto elementi di tipo strettamente tecnico benché talvolta l’analisi sia orientata a determinare anche le ricadute in un più vasto contesto socio-economico. Una possibile classificazione delle minacce e dei rischi può essere riassunta tramite la tabella sottostante: Azioni Umane Intenzionali Cause Interne Infiltrazione Cause Esterne Sabotaggio, Terrorismo, Azioni di Guerra Non Intenzionali Fattori Umani, Mancanza di manutenzione Fattori Umani Interventi non Umani Guasti tecnici, Errori di produzione Disastri Naturali, Distruzioni in altri sistemi e servizi Tabella 2.1: Classificazione rischi e minacce 2.2 Risk Evaluation Un industrial control system e le infrastrutture critiche, hanno raggiunto negli ultimi anni un livello di interdipendenza tale, che la corruzione di uno di questi elementi può avere rapidi effetti negativi su tutta la scoietà (basti pensare al disastro di Fukushima). Come è possible osservare dalla figura in basso, il fallimento di uno solo dei sistemi, a causa di un cyber-attack può condizionare di molto l’economia di un intero Paese.[1] Figura 2.2.1: Interdipendenza tra i settori Figura 2.2.2: Percentuale di perdita in caso di attacco ad uno dei settori nell’economia statunitense 2.2.1 Alcuni scenari passati In passato si è assistito a vere e proprie catastrofi ambientali ed economiche, che hanno portato addirittura alla perdita di vite umane, per colpa di una scarsa protezione di sistemi SCADA. Un riepilogo di alcune di esse serve a spiegare, meglio di qualsiasi numero, quali sono i rischi a cui si va incontro. • Esplosione di un oleodotto , WA, USA (Giugno 1999) [inserire riferimento citicus] Corporate e SCADA network collegate. Nessun AV o monitor d’accesso I cambiamenti nell’historical database hanno causato l’abbattimento delle performance Scan rates 3s -> 6m I controller non sono capaci di carpire la pressione nella pipeline. 230,000 gallonidi gasolio perso 3 morti, enormi danni. Ingenti perdite economiche nell’ordine di decine di milioni di $ • Attacco alle acque reflue del Maroochy Shire , QLD, Australia (Marzo/ Aprile 2000) >750,000 galloni di acque reflue non trattate rilasciate volontariamente in parchi fiumi e giardini dell’hotel Perdita della vita marina, vita pubblica a rischio, $200,000 di costi in pulizia Attrezzature rubate per controllare in remoto il sistema via wireless Pieno controllo della fornitura di acqua dolce Ha causato 46 differenti incidenti • Mancanza di elettricità nel nord US. e Canada (Agosto 2003) 50 milioni di case colpite L’impianto è stato colpito dal worm Blaster, causando ingenti danni Guasto del sistema di warning dovuto alla presenza di bug nel software Notiche del problema rallentate Più di 100 impianti energetici arrestati • Davis Besse, OH, USA (Agosto 2003) SQL Slammer infetta la rete dell’ impianto tramite la rete dei contractors Arresto completo del sistema di visualizzazione dei warning (4h 50m) e dei processi industriali(6h 9m) Le patch sono state sviluppate dopo ben 6 mesi Per classificare le conseguenze che un cyber attack potrebbe avere su un impianto industriale, è possibile utilizzare la tabella in figura, che ci da un idea dell’impatto economico/produttivo del virus sull’azienda. Figura 2.2.3: Harm Reference Table 2.3 APT: Advanced Persistent Threat Negli ultimi anni è notevolmente aumentato lo sviluppo di software malevoli in grado di penetrare con molta facilità (anche a volte grazie all’intervento umano) infrastrutture critiche. Essi prendono il nome di Advanced Persistent Threath in quanto, a differenza di malware di vecchia generazione riescono a sopravvivere all’interno di un sistema, nascondersi ai più sofisticati sistemi anti-virus e comunicare informazioni all’esterno tramite l’utilizzo di uno Command & Control Server. Una delle prime società a parlare di APT fu Mandiant, una società di sicurezza informatica focalizzata sulle tematiche di Incident Response e di Computer Forensics che fornisce servizi, prodotti e formazione a clienti privati e governativi. In particolare, nel seguente paper [23] vengono analizzate le caratteristiche principali degli APT e le fasi in cui si articolano questi particolari tipi di attacco: 1. Ricognizione: gli attaccanti cercano e identificano le persone che saranno bersaglio degli attacchi e, utilizzando fonti pubbliche o altri metodi, ottengono i loro indirizzi e-mail o i riferimenti di instant messaging 2. Intrusione nella rete: tutto inizia con delle mail di phishing, in cui l’attaccante prende di mira utenti specifici all’interno della società target con messaggi di posta elettronica fasulli che contengono link pericolosi o dannosi, oppure file malevoli allegati (PDF o documenti Microsoft Office). Questa fase consente di infettare la macchina e dare all’attaccante un primo accesso all’interno dell’infrastruttura 3. Creazione di una backdoor: gli attaccanti cercano di ottenere le credenziali di amministratore del dominio estraendole dalla rete. Gli attaccanti quindi, si muovono "lateralmente" all’interno della rete, installando backdoor e malware attraverso metodi di ’process injection’, modifiche di registro di sistema o servizi schedulati 4. Ottenere le credenziali utente: gli attaccanti ottengono la maggior parte di informazioni accedendo i sistemi tramite valide credenziali utente. In media, nelle reti del target vengono acceduti circa 40 sistemi utilizzando le credenziali rubate. 5. Installazione di utilities malevole: varie utility malevole vengono installate sulla rete target al fine di poter amministrare il sistema e svolgere attività come l’installazione di backdoor, il furto di password, la ricezione di email e l’ascolto di processi in esecuzione. 6. Escalation dei privilegi, ’movimento laterale’ ed esfiltrazione dei dati: ora gli attaccanti iniziano a intercettare le mail, gli allegati e i file dai server attraverso l’infrastruttura malevola di Comando e Controllo. Gli attaccanti di solito inviano i dati rubati verso server intermedi, dove li cifrano, li comprimono e quindi li indirizzano verso la destinazione finale 7. Mantenere la persistenza: gli aggressori cercano in ogni modo di mantenere la loro presenza nelle reti del target anche se alcuni parti vengono scoperte o inattivate. Gli APT sviluppati sono stati scoperti solo tre, quattro anni più tardi dalla loro diffusione ed ancora non completamente compresi e vanificati. In realtà Mandiant nella descrizione di un APT ha considerato solo alcuni scenari, ma gli strumenti di diffusione odierni sono tra i più disparati: • USB • Bluetooth • Wifi • CD/DVD • Mail • Cartelle condivise Di seguito si riporta una lista degli APT scoperti negli ultimi anni con una breve descrizione dei danni causati: 2003 – Slammer[24] Il worm informatico Slammer, con la sua rapida diffusione, ha causato problemi ai circuiti finanziari (quello del sud-est asiatico fu quasi completamente bloccato, in USA 13.000 ATM andarono fuori servizio, in Italia in 11.000 uffici Postali ci furono notevoli problemi), ai trasporti aerei (diversi voli in partenza dall’aeroporto di Huston e di Vancouver subirono pesanti ritardi o furono cancellati) ed ai sistemi di emergenza (il call-center del 911 di Seattle andò fuori servizio). Negli USA il worm è riuscito a penetrare anche all’intero del sistema di controllo di una centrale nucleare in dismissione (senza creare seri problemi grazie alla presenza di circuiti di back-up in analogico) e ad interrompere il traffico dei sistemi di monitoraggio e controllo di due società di distribuzione dell’energia elettrica (in un caso penetrando all’interno del sistema informatico e nell’altro saturando la banda del canale ATM utilizzata per la connessione con le unità periferiche). 2009 – Aurora [24] Aurora è uno dei primi malware capace di infettare milioni di PC ed esportare dati verso l’esterno. Esso prende il nome dall’operazione associata cominciata nella metà del 2009 e terminata verso la fine dello stesso anno. L’attacco ha colpito aziende molto importanti come Yahoo!, Symantec, Adobe , ma soprattutto Google. Gli esperti di sicurezza della Mc Afee ritengono che il malware sia stato creato per ottenere l’accesso e potenzialmente modificare i repository sorgente delle compagnie colpite. Il malware era inoltre capace di replicare se stesso all’interno di una LAN. 2010 – Stuxnet [14] Stuxnet è il primo malware che riprende il concetto di Cyberwarfare. Stuxnet è il primo virus che spia e riprogramma i PC destinati al controllo dei sistemi industriali, infetta sistemi operativi Windows e si propaga tramite l’utilizzo di ben 4 vulnerabilità 0-day. Lo scopo del virus è quello di deteriorare le centrifughe di centrali nucleari utilizzanti una determinata infrastruttura di controllo. In realtà una prima versione del virus nasce nel 2005 ( scoperta solo nel 2012 ) con l’intento di chiudere le valvole utilizzate per alimentare gas esafluoruro di uranio in centrifughe per l’arricchimento dell’uranio. Un malware di questo tipo potrebbe creare danni di qualsiasi dimensione senza che nessuno se ne accorga, fino a distruggere intere centrali. Secondo il New York Times, il virus Stuxnet sarebbe, la più sofisticata arma informatica mai creata, nonché il più importante strumento in mano a Israele e Stati Uniti per ostacolare l’Iran. Stuxnet è riuscito a penetrare più di 30000 PC e a rallentare notevolmente il programma nucleare Iraniano. 2011 – Duqu [20] Scoperto nel 2011 Duqu mostra enormi somiglianze con Stuxnet ma ha scopi totalmente differenti. Infatti presenta un rootkit dedicato allo spionaggio di informazioni industriali presenti sui PC infetti, tramite l’utilizzo di keylogger. Le informazioni vengono poi inviate in maniera criptata ad un C&C Server. Ad ulteriore conferma del fatto che Duqu sia un esperimento condotto per ottenere informazioni da usare in attacchi successivi, gli esperti del CrySyS hanno scoperto che l’installazione del malware attraverso la vulnerabilità zero-day di Windows era programmata per essere eseguita solo in un periodo di otto giorni nell’agosto 2011. Queste informazioni prelevate dal virus potrebbero portare alla conoscenza perfetta del sistema industriale utilizzato per poi creare un “nuovo” Stuxnet adatto a quell’infrastruttura e provocare ingenti danni. 2011 – Night Dragon [12] Night Dragon è incentrato specificamente sul settore energetico, ma le tecniche che utilizza potrebbero essere molto efficaci in qualsiasi settore. Secondo il rapporto di McAfee, gli attacchi sono in corso dal 2009 e riguardano lo sfruttamento delle vulnerabilità di Windows per sottrarre informazioni riguardanti il project-financing di compagnie petrolifere. 2012 – Flame [21] Scoperto nel 2012 Flame mostra anch’esso enormi somiglianze con Stuxnet ma riprende lo scopo di Duqu. Infatti nasce come malware di spionaggio atto registrare qualsiasi informazione presente sul PC infetto (mail,IM,microfono,video,keylogger,screenshot) ed inviarle ad un C&C Server. Secondo Kaspersky, Flame è un programma sofisticato, tanto da essere il virus più pericoloso tra tutti quelli scoperti in questi anni. Esso ha molta affinità con Stuxnet. Il nome “Flame” è connesso con i moduli di attacco, localizzati in vari luoghi nel codice malware decriptato. Infatti il malware si presenta come una piattaforma in grado di ricevere ed installare vari moduli per colpire differenti obiettivi. Kaspersky Lab ha scoperto l’esistenza del virus dopo che un’agenzia Tlc delle Nazioni Unite ha chiesto di analizzare i dati su un software malevolo del Medio Oriente, in cerca di un data-wiping virus denunciato dall’Iran. Il malware Flame è multifunzione, in quanto è in grado di portare avanti varie opzioni di alto profilo: monitoraggio network, scansione disco, cattura schermo, registrazione suoni da microfoni integrati ed è in grado di infiltrare vari sistemi Windows. Flame può propagarsi anche attraverso chiavette USB. 2012 – Gauss [16] Con Flame condivide una parte del codice utilizzato, con qualche differenza sul piano della infrastruttura ed una differenza fondamentale: al contrario dei suoi predecessori, Gauss sembra interessato a password e informazioni sui conti bancari delle vittime. Si concentra soprattutto sui PC degli abitanti del Libano. 2012 – Shamoon [22] L’arma più distruttiva scoperta dopo Stuxnet si chiama Shamoon. Come Stuxnet ,Duqu e Flame colpisce principalmente compagnie energetiche del Medio Oriente come Saudi Aramco, Qatar’s RasGas e altre compagnie presenti nella zona. È una nuova specie di virus che non distrugge processi industriali come Stuxnet o spia informazioni come Duqu,Gauss e Flame ma ha lo scopo di rimuovere e sovrascrivere informazioni presenti sugli hard disk di 30000-55000 workstation delle compagnie sopra citate. Il seguente grafico dà un’ idea di come siano evoluti rapidamente sia i malware, che le conoscenze degli attacker. Dalla figura 2.3.1 è possibile notare come l’aumento di sofisticazione dei tools presenti in rete per condurre un attacco, ha comportato una drastica riduzione delle conoscenze necessarie ad un attacker per compromettere un sistema. Uno studio del CERT dell’Università di Carnegie Mellon ha segnalato oltre 26000 incidenti di intrusioni nei computer nei primi tre mesi del 2002, che sono più di tutti quelli avvenuti in tutto il 2000 [15]. Figura 2.3.1: Evoluzione dei tool d’attaco e riduzione delle competenze di un attacker Capitolo 3 Stuxnet: “tecniche di guerra digitale” 3.1 Un po’ di storia Stuxnet, individuato nel giugno 2010 da VirusBlokAda (una ditta Bielorussa), è un computer worm progettato per attaccare software ed equipaggiamenti industriali. La prima variante di Stuxnet ha cominciato a diffondersi nel giugno 2009, ma la sua diffusione si è accelerata con le versioni successive del marzo-aprile 2010. Il nome è derivato da alcune keywords nascoste all’interno del software e trovate dagli analisti che lo hanno scoperto. Stuxnet include anche un rootkit ( software creato per avere il controllo completo di un sistema senza autorizzazioni) predisposto per un Programmable Logic Controller, cioè per computer specializzati nella gestione e controllo di processi industriali, ma in realtà studiato per colpire solo il sistema SCADA (Supervisory Control And Data Acquisition) della Siemens destinato a controllare processi industriali molto particolari. La Symantec che ha esaminato il caso ha dichiarato alla BBC che diverse varianti di Stuxnet hanno attaccato fra giugno 2009 e aprile 2010 cinque impianti iraniani con il probabile obiettivo di colpire l’infrastruttura per l’arricchimento dell’uranio che usa equipaggiamenti Siemens procurati 32 clandestinamente. L’analisi suggerisce anche che i creatori del worm hanno colpito le organizzazioni dall’interno, in quanto si tratta ovviamente di impianti non collegati a Internet per ragioni di sicurezza. Pertanto l’infezione è avvenuta tramite dispositivi mobili come ad esempio memorie USB. In realtà una prima versione del virus nasce nel 2005 con la sua versione 0.5, in cui lo scopo principale era quello di chiudere le valvole utilizzate per alimentare gas esafluoruro di uranio nelle centrifughe per l’arricchimento dello stesso. Una seconda versione del virus (Stuxnet 1.0 , scoperta solo nei primi mesi del 2010), invece, nasce con l’obiettivo dil deteriorare le turbine delle centrifughe destinate al processo di arricchimento dell’uranio portandole a velocità di rotazione insostenibili e riducendo tali velocità repentinamente. Figura 3.1.1: Diffusione del virus[14] La figura 3.1.1 rappresenta i diversi ragruppamenti di infezione dovuti a 10 differenti infezioni iniziali. Ogni infezione è un cerchio nero. I cerchi rossi rappresentano la variante utilizzata. Gli altri cerchi colorati rappresentano l’infezione in un dominio differente ,rappresentato con colore ben preciso (verde, giallo, blu, viola e arancio). La diffusione del virus,quindi, aumenta notevolmente, passando da pochi “grappoli” infetti a più zone di interesse. Ci sono un totale di 10 gruppi, in rappresentanza di 10 infezioni iniziali. L’attacco al dominio B (marzo 2010)è quello che ha avuto più successo. Attacchi nei primi giorni di giugno 2009 evidenziano le infezioni di minor rilievo,anche se, questi numeri, sono più bassi a causa dei campioni che sono stati recuperati. Per capire esattamente la pericolosità di un virus del genere basta analizzare la figura sottostante che rappresenta la diffusione geografica del malware in pochi anni. Figura 3.1.2: Diffusione geografica di Stuxnet[14] Come è possibile notare la zona più colpita è rappresentata propriio dall’Iran, il che porta a validare la tesi dell’attacco mirato. All’interno della tabella 3.1 possiamo analizzare le varie fasi di scoperta del virus rappresentate tramite una Timeline. Data Novembre 2008 Evento Una variante del viru Trojan.Zlob utilizza la vulnerabilità LNK solo dopo aver idenitificato Stuxnet Aprile 2009 La rivista Security Hakin9 rilascia i dettagli di una vulnerabilità legata all’esecuzione di codice in modalità remota nel servizio Spooler di stampa. Identificato poi come MS10-061. Giugno 2009 Prima campione di Stuxnet osservato. Non sfrutta la vuln MS10-046 e non presenta la firma dei friver Gennaio 2010 Si osserva il primo driver digitalmente firmato.La firma appartiente alla Realtek Semiconductor Corps. Marzo 2010 Prima variante di Stuxnet che utilizza l’ exploit MS10-046. Giugno 2010 VirusBlokAda identifica W32.Stuxnet (chiamato RootkitTmphider). Riferisce che sta usando una vulnerabilità presente nei file .lnk per propagarsi (vulenrabilità che solo pochi mesi più tardi Microsoft ha riportato nel bulletin identificato come MS10-046). 13 Luglio 2010 Symante identifica Stuxnet com w32.Temphid (Trojan Horse). 16 Luglio 2010 Microsoft rilascia un Security Advisory (per la "vulnerabilità nella shell di Windows che può consentire l’esecuzione di codice in modalità remota (2286198)" )che patcha la vulnerabilità nei file .lnk. 17 Luglio 2010 Eset identifica un nuovo driver di Stuxnet, questa volta firmato con un certificato rilasciato dal JMicron Technology Corp. 19 Luglio 2010 Rapporto di Siemens che comunica che si stanno studiando i report dei malware che infettano i sistemi Siemens WinCC SCADA Symantec rinomina il malware W32.Stuxnet. 20 Luglio 2010 Symantec monitora il server di comando e di controllo di Stuxnet 22 Luglio 2010 Verisign revoca il certificato JMicron Tecnologia Corps. 2 Agosto 2010 Microsoft rilascia MS10-046, che patcha la Windows Shell shortcut vulnerability. 6 Agosto 2010 Symantec riporta come Stuxnet può infettare i PLC colpendo così gli industrial control systems. Settembre 2010 Microsoft rilascia MS10-061 per patchare la Printer Spooler Vulnerability identificata da Symantec ad Agosto. Tabella 3.1: Stuxnet Timeline 3.2 Architettura del threat Stuxnet è dotato di un’architettura molto complessa, difficile da analizzare in quanto presenta ogni volta nuove sfaccettature. Il cuore di Stuxnet è costituito da files di grandi dimensioni, ovvero DLL (Dinamic Link Library) che contengono metodi (che per brevità chimaremo export) e risorse differenti. Oltre a file di grandi dimensioni, Stuxnet contiene anche due blocchi di configurazione criptati. Il dropper1 di Stuxnet è un programma wrapper2 che contiene tutti i componenti, memorizzati all’interno di una sezione chiamata "stub". Quando la minaccia viene eseguita, il wrapper estrae un file .dll dalla sezione stub, lo mappa nella memoria come un modulo, e chiama una delle export. Un puntatore alla sezione stub originale viene passato a tale export come parametro di input. Il puntatore alla sezione stub originale viene poi nuovamente passato come parametro ad uno dei metodi chiamati, in modo tale che, ogni strato del malware, ha sempre accesso alla dll principale ed ai blocchi di configurazione. Per autoinstallarsi, Stuxnet utilizza anche una tecnica differente, basata sull’utilizzo di un template PE (il formato Portable Executable (PE) è un formato di file per file eseguibili, file oggetto, librerie condivise e device drivers, usato nelle versioni a 32-bit e 64-bit del sistema operativo Microsoft Window. Il formato PE è praticamente una struttura dati che incapsula le informazioni necessarie al loader di Windows per gestire il codice eseguibile.) presente all’interno delle proprie resources3 con informazioni relative alla dll principale. In questo modo Stuxnet riesce a creare un vero e proprio eseguibile che richiama le proprie funzioni. 1 Un dropper è un programma (componente malware) creato per installare un malware, un virus, o aprire una backdoor su un sistema. Il codice del malware può essere contenuto dentro il dropper (singola fase) in modo tale da evitarne il rilevamento da parte degli antivirus, oppure il dropper, una volta attivo, può scaricare il malware nel sistema target (doppia fase). 2 Un wrapper (dal verbo inglese to wrap, "avvolgere") è un modulo software che ne "riveste" un altro, ovvero che funziona da tramite fra i propri clienti (che usano l’interfaccia del wrapper) e il modulo rivestito (che svolge effettivamente i servizi richiesti, su delega dell’oggetto wrapper). 3 Una risorsa rappresenta un file utilizzati da un metodo presente nella dll per raggiungere un determinato scopo 3.2.1 Export La DLL principale contiene tutto il codice per controllare Stuxnet. Ogni export di questa DLL, ha uno scopo differente nella gestione e nel controllo del threat. All”interno della Figura 3.2.1 è possibile osservare i diversi scopi di ogni export. Figura 3.2.1: Export utilizzate da Stuxnet[14] L’entry point è rappresentato dalla Export 15, dalla quale verranno poi richiamate le altre a seconda dell’operazione richiesta. Come è possibile osservare dalla Export 18, Stuxnet ha la capacità di disinstallarsi. Questo avviene dopo un certo periodo di tempo per non lasciare tracce di se stesso. 3.3 Diffusione Abbiamo accennato che l’infezione iniziale all’interno della Enterprise Network avviene tramite l’utiizzo di dispositivi rimovibili come ad esempio memorie USB, ma non abbiamo ancora parlato di come Stuxnet riesce a diffondersi all’interno della rete tramite altre tecniche. Essendo un virus molto aggressivo, riesce a sfruttare cinque vulnerabilità per copiare se stesso all’interno degli altri host presenti nella LAN: 1. LNK Vulnerability (CVE -2010-2568) si tratta di una vulnerabilità 0day molto pericolosa poiché permette l’esecuzione di codice arbitrario ed è sfruttabile sia in locale che da remoto, un attacco portato a termine utilizzando questa vulnerabilità può considerarsi piuttosto affidabile e ciò che lo rende possibile è un difetto di design della procedura di estrazione delle icone che Windows Shell (shell32.dll) associata ai file .LNK (i collegamenti). Tutte le versioni di Windows sono affette da tale problema. In pratica l’esecuzione di un file può essere effettuata semplicemente visualizzando l’icona del collegamento. Un file .LNK è costituito principalmente da tre sezioni: (a) Header Un file LNK ha i primi 4 byte costituiti dalla sequenza 4C 00 00 00 , e gli altri 16 che rappresentano il GUID. Seguono altri dati nell’intestazione che specificano il tipo di link (se è un file ,una directory, o altro), gli attributi del target (del file collegato), per esempio se è di sistema , se è nascosto e così via. In pratica è come se memorizzassimo delle informazioni riguardanti un file all’interno di un altro file (appunto il collegamento .lnk).Queste informazioni vengono seguite da 3 interi a 64 bit per memorizzare la data di creazione, modifica ed ultimo acceso. Dopo la data viene riportata la lunghezza del file “puntato”. (b) Shell Item ID List Dopo questi valori, ci sono dei flag che vengono passati all’applicazione quando viene eseguita (ha senso con file eseguibili). (c) File Location Info Questa struttura presenta un intero che indica la lunghezza totale del campo, poi un offset a partire dalla stessa che porta alla fine. Al suo interno è contenuto il nome del file che deve caricare l’icona. La vulnerabilità risiede all’interno del file shell32.dll,che presenta metodi del pannello di controllo vulnerabili, i quali iniziano tutti con il prefisso “CPL_”. Questi metodi convergono verso il metodo LoadLibraryW utilizzata per caricare il file indicato all’interno della sezione File Location Info. Figura 3.3.1: Struttura di un file .LNK Stuxnet utilizza questa falla proprio per eseguire il file ~wtr4141.tmp. Quando il file .LNK viene visualizzato tramite Esplora Risorse, viene chiamata la funzione LoadLibraryW() che attiva la DLL, ricevendone il percorso. Stuxnet utilizza questa vulnerabilità per distribuire se stesso. In particolare crea quattro file con lo stesso scopo : • Copy of Shortcut to.lnk; • Copy of Copy of Shortcut to.lnk; • Copy of Copy of Copy of Shortcut to.lnk; • Copy of Copy of Copy of Copy of Shortcut to.lnk; • ~WTR4141.TMP; • ~WTR4132.TMP. Abbiamo quattro link file, che differiscono per il percorso del file specificato. In pratica ogni unità esterna (in questo caso una flash drive USB), ha un proprio path fisso che varia a seconda del SO utilizzato: • Windows XP • Windows 7 • Windows Server 2003 • Windows 2000 Stunxnet utilizza due file: • ~WTR4141.TMP; • ~WTR4132.TMP. Il primo file ha come scopo principale quello di caricare il secondo file, ma prima di farlo, è attento a nascondere tutti i file sul disco rimovibile. Un enorme vantaggio per il malware fin quando non viene installato il rootkit. 2. MS10-061 Print Spooler zero-day vulnerability è una vulnerabilità zero day patchata da Microsoft con l’MS10-061. Questa vulnerabilità consente di scrivere nella cartella %System% della macchina vulnerabile. Il codice utilizzato da Stuxnet consente di caricare la DLL utilizzata dal virus. In pratica un attacker locale capace di inviare jobs alla stampante, può sfruttare questa vulnerabilità per elevare i suoi privilegi ed inviare una copia di se stesso alla vittima. L’attacco si divide in due fasi: (a) Nella le prima fase all’interno delle il virus cartelle copia il dropper ed altri fi- Windows\System32\winsta.exe e Windows\System32\wbem\mof\sysnullevnt.mof (b) Nella seconda il dropper viene eseguito La prima fase sfrutta la vulnerabilità MS10-061. Sotto alcune condizioni lo spooler impersona un client che invia due documenti in stampa. Questi due file sono stampati su file presenti nella cartella %SYSTEM% con privilegi da utente Guest (il quale non potrebbe avere accesso a tale cartella). In pratica un thread del processo spoolsv.exe chiama la funzione StartDocPrinter() in cui si specifica come un documento deve essere stampato. Per specificare come va stampato il documento viene passato il seguente parametro come Doc_Info: 1 typedef struct _DOC_INFO_1 { 2 LPTSTR pDocName; // Default 3 LPTSTR pOutputFile; // winsta.exe or wbem\mof\sysnullevnt.mof 4 LPTSTR pDatatype; // RAW 5 } DOC_INFO_1; La funzione StartDocPrinter() ha la seguente struttura: DWORD StartDocPrinter( _In_ HANDLE hPrinter, _In_ DWORD Level, _In_ LPBYTE pDocInfo ); Il primo parametro è un handle alla stampante,il secondo la versione di pDocInfo ed il terzo un puntatore al DOC_INFO_1. Microsoft ha rilasciato una patch per ovviare a questa vulnerabilità, introducendo due controlli pre-stampa: • Che il chiamante appartenga ad un gruppo locale • Che il parametro OutputFile sia NULL o uguale alla porta della stampante. Se così non fosse deve ottenere i diritti necessari. La seconda fase dell’attacco coinvolge il file wbem\mof\sysnullevnt.mof. Questo è un MOF file(Managed Object Format file). Questo file serve a definire la classe che rappresenta ogni oggetto del servizio. Esso può eseguire DLL, e spesso porta all’esecuzione del dropper winsta.exe. 3. MS08-067 Windows Server Service Vulnerability è una vulnerabilità presente all’interno del servizio RPC (Remote Procedure Call) messo a disposizione da Microsoft, che può abilitare un attacker locale ad eseguire codice malevolo da remoto. Tale vulnerabilità era già stata utilizzata da altri worm come Conflicker, il quale sfruttava una connessione tramite SMB4 ,su cui inviavano stringa con un percorso malformato, il quale abilitava l’esecuzione di qualsiasi file.Prima di utilizzare tale vulnerabilità, Stuxnet effettua un controllo basato su tre punti (a) La data corrente deve essere inferiore al 1 Gennaio 2013 (b) Antivirus installato sull’host aggiornato con data inferiore al 1 Gennaio 2009 (c) Timestamp delle librerie Kernel32.dll e Netapi32.dll inferiorel 12 Ottobre 2008 4. Network Shares Stuxnet può diffondersi anche tramite rete condivisa. All’interno di una rete locale, riesce a constatare se la condivisione $ADMIN è accessibile per costruire il nome del disco in comune (ad es. C$). Dopodiché, tramite la resource 210, costruisce un eseguibile con il codice della dll principale. Dopo aver individuato le cartelle, il file viene copiato con un nome casuale nella forma 4 Server Message Block (SMB) è un protocollo usato principalmente per condividere files, stampanti, porte seriali e comunicazioni di varia natura tra diversi nodi di una rete. Esso include anche un meccanismo di comunicazione tra processi autenticata. È soprattutto usato dai sistemi Microsoft Windows. DEFRAG[RANDLNT].TMP. Successivamente un job di rete viene schedulato per eseguire l’infezione. 5. WinCC Database servers Ogni volta che Stuxnet riesce ad installarsi su un host della rete, avvia una serie di operazioni in parallelo, tra cui la ricerca del server che esegue il software WinCC database. Quando questo viene trovato il malware esegue una connessione al database tramite l’uso di password standard non modificate dall’utente e inserite direttamente dal produttore, per inviare codice SQL adibito al caricamento del virus su altri host che implementano il software WinCC. I dati caricati all’interno del database sono dati binari, rappresentati da una stringa esadecimalehe rappresenta la DLL di Stuxnet. Le query eseguite dal malware sono del tipo: CREATE TABLE sysbinlog ( abin image )INSERT INTO sysbinlog VALUES(0x...) Se ha successo Stuxnet utilizza OLE Automation Stored Procedure per salvare se stesso dal database al disco come %UserProfile%\sql[RANDOM VALUE].dbi. Il file è poi aggiunto come una stored procedure ed eseguito. 1 SET tiainf = tiaind + ’\\sql%05x.dbi’ 2 EXEC sp _ addextendedproc sp _ dumpdbilog, tiainf 3 EXEC sp _ dumpdbilog dopo l’esecuzione del codice seguente, la stored procedure e la DLL principale vengono eliminate. 6. Step7 Project File Infection Stuxnet riesce a collegarsi a file di progetto Step7 ed installarsi sul PC vittima nel momento in cui questo tipo di file viene aperto. 3.4 Tecniche di injection nei processi Per effettuare l’esecuzione delle sue funzionalità principali, Stuxnet utilizza tecniche di DLL injection. La dll injection si basa nello scrivere il codice che si vuole far eseguire ad un altro processo,all’interno di una libreria dinamica (dll su Microsoft Windows). Quindi si avvia un programma che carica questa dll nel processo esterno (ovviamente con privilegi superiori rispetto al nostro processo) e il sistema operativo vede il codice come se fosse eseguito dal processo esterno e non dal nostro. Ogni volta che viene chiamata una export dalla DLL principale Stuxnet inietta l’intera DLL in un altro processo. Esso può essere un processo già esistente o uno creato ex-novo da Stuxnet. Se il processo è un “processo di fiducia” potrebbe a sua volta iniettare la dll all’interno di un altro processo. I processi fondamentali per l’injection sono: • Lsass.exe • Winlogon.exe • Svchost.exe • Software di sicurezza installati Stuxnet estrae da se stesso un template PE (Portable Executable) e crea una nuova sezione (chiamata .verif ) in grado di contenere l’indirizzo dell’entry point del processo colpito. A questo indirizzo ,Stuxnet pone un JUMP all’entry point desiderato e chiama sul processo la funzione ResumeThread in modo tale da far eseguire il codice necessario. Per far si che il processo abbia a disposizione tutte le entry della DLL principale, la sezione .stub viene mappata nella memoria del nuovo processo tramite sezioni condivise. Inoltre il processo può istruirne un altro per eseguire l’ export desiderata. Figura 3.4.1: Processi utilizzati da Stuxnet per l’injection 3.5 Installazione Appena il file .dll viene caricato per la prima volta, viene chiamata la Export 15, che ha il compito di : 1. Verificare che il PC utilizzi una versione di Windows compatibile 2. Vedere se il PC è già infetto o meno 3. Elevare i privilegi del processo corrente a privilegi di sistema (il risultato è un nuovo processo). Tale operazione sfrutta vulnerabilità differenti a seconda del sistema operativo utilizzato: • Task Scheduler Escalation of Privilege vulnerability (Vista,7 Server 2008) • Windows Win32k.sys Local Privilege Escalation vulnerability MS10- 073 (XP, 2000) 4. Cercare quale antivirus è installato e qual è il “miglior” processo per copiare il codice al suo interno. Figura 3.5.1: Export 15 utilizzata per la prima fase dell’installazione Dopo questi checks viene chiamata la Export 16 tramite la tecnica di injection sopra descritta. La Export 16 rappresenta il punto di installazione di Stux- net. La prima operazione eseguita riguarda la ricerca della data e del numero di versione del pc infetto, dopodiché crea ed installa il rootkit e le chiavi di registro, inietta se stesso nel processo services.exe per infettare i dischi rimovibili, inietta se stesso nel processo Step7 per infettare i progetti Step7,imposta i mutex globali per favorire la comunicazione di componenti differenti, e si connette al server RPC (utilizzato anche per conoscere l’ultima versione di Stuxnet). Per verificare che il pc non sia già infetto e contrassegnarlo come tale, Stuxnet va a modificare una chiave di registro “NTVDM TRACE” all’indirizzo HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\MSDOS Emulation . Se questa chiave ha il valore 19790509 vuol dire che il pc è già stato infettato ed il virus termina la sua esecuzione. Dopodichè Stuxnet effettua una ricerca sulla data del sistema e verifica che essa sia minore del 24/06/2012 (una sorta di deadline). Se questo è vero termina la sua esecuzione. Impostando dei global mutex, Stuxnet effettua la comunicazione tra processi andando a settare le regole di accesso ai file tramite: • SetDACL (XP o minori) • SetSACL (Vista o superiori) che hanno il compito di assicurare che nessuna fase di scrittura venga negata. Successivamente crea 3 file criptati: • 0em7a.pnf che rappresenta il corpo della dll principale • mdmeric3.pnf copiato in %SystemDrive%\inf\ • dati di configurazione copiati in %SystemDrive%\inf\mdmcpq3.PNF • un file di log %SystemDrive%\inf\oem6C.PNF Ricontrolla ancora una volta la data e verifica se la versione del virus è l’ultima diffusa, analizzando la versione criptata sul disco, decriptandola e caricandola in memoria. Per effettuare il controllo chiama la Export 6 che contiene il numero di versione ultimo del virus. Se le versioni coincidono Stuxnet continua la sua esecuzione. A questo punto, estrae su disco due file provenienti dalle resources 201 e 242 salvati come "Mrxnet.sys" e "Mrxcls. sys”. Sono due driver di cui il primo è il load point del programma, mentre l’altro ha il compito di nascondere e rimuovere i file di Stuxnet dal disco. Quando questi sono creati, le date di creazione dei file vengono modificate in base alle altre cartelle presenti sul sistema per non destare alcun sospetto. Quando questi file vengono eliminati Stuxnet avrà già modificato le voci di registro per caricarli come un servizio automatico all’avvio di Windows (HKEY_ LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services\MRxCls \”ImagePath” = “%System%\drivers\mrxcls.sys”).Non appena il rootkit è stato installato correttamente, Stuxnet crea altri mutex globali per segnalare il successo dell’installazione. A questo punto il controllo viene passato a due altre Export. Si inietta la dll principale prima all’interno del processo services.exe chiamando l’export 32 (che ha il compito di infettare i dischi rimovibili e avviare il server RPC) e poi all’interno del processo S7tgtopx.exe chiamando l’export 2 (che infetta tutti i sistemi Step7 eventualmente presenti sul PC ). Per effettuare queste operazioni Stuxnet potrebbe killare i processi explorer.exe e S7tgtopx.exe. 3.5.1 P2P sharing Continue ricerche da parte di ricercatori Symantec hanno constatato che Stuxnet, è capace di aggiornare se stesso tramite l’utilizzo di comunicazioni P2P. Le macchine infette possono porsi in contatto tra di loro, e verificare quale di esse possiede la versione più recente del virus. Qualsiasi macchina la possieda, sarà in grado di contattare gli altri componenti infetti della rete ed inviare la nuova versione del malware. Le comunicazioni P2P sono spesso utilizzate da malware, in quanto sono difficili da abbattere non avendo un punto centrale di fallimento. Ogni macchina della rete potrà fare quindi sia da client, effettuando il download del programma, che da server , inviando la propria copia ad un PC presente sulla LAN. Prima di connettersi al server RPC Stuxnet attende un tempo breve dopodiché chiama la funzione 0 verso di esso per farne il check, e la funzione 9 per recuperare alcune informazioni che verranno memorizzate nel file oem6c.pnf. Figura 3.5.2: Comunicazione P2P Il server RPC offre le seguenti funzioni: 0: ritorna la versione di Stuxnet installata 1: ricevi un .exe ed eseguilo 2: carica un modulo e la export eseguita 3: inietta il codice nel processo lsass.exe ed eseguilo 4: costruisci l’ultima versione di Stuxnet e mandala al client che la richiede 5: crea il processo 6: leggi file 7: sposta file 8: cancella file 9: scrivi data records Mentre il client può effettuare le seguenti richieste: 1: chiamare la funzione 0 sul server RPC per conoscere l’ultima versione 2: vedere se la sua versione è aggiornata 3: se la versione sul client è vecchia allora: a. chiama la funzione 4 per richiedere l’ultima versione b. ottiene l’ultima versione c. la installa tramite dll injection 4: se la versione sul client è più recente di quella del server: • prepara un .exe della sua versione di Stuxnet (tramite resource 210) • invia il file .exe al server tramite funzione RPC 1 Il procedimento di connessione è il seguente: Il client tenterà di chiamare la funzione RPC 0 su ciascun collegamento aspettando una risposta. Stuxnet esegue il binding seguente: 1. ncacn_ip_tcp:IPADDR[135] 2. ncacn_np:IPADDR[\\pipe\\ntsvcs] 3. ncacn_np:IPADDR[\\pipe\\browser] dopodiché tenterà di impersonare il token anonimo ed effettuare il seguente collegamento: • ncacn_np:IPADDR[\\pipe\\browser] Infine cercherà di individuare altri collegamenti tramite il SCM (Service Control Manager). Per ogni altro binding trovato verrà eseguito il seguente comando: • ncacn_ip_tcp:IPADDR (searches in the SCM for available services) Se almeno una delle associazioni risponde alla chiamata della funzione RPC 0 , allora Stuxnet avrà trovato un computer compromesso. Siccome si utilizza un sistema basato su server RPC, esso è efficace solo per computer connessi all’interno di una LAN. 3.5.2 Control & Command Server La capacità di Stuxnet di auto-aggiornarsi non è limitata al semplice scambio di informazioni tramite rete P2P. Infatti il malware è in grado di creare una vera e propria botnet che fa riferimento a dei server di controllo e comando detti C&C SERVER. Dopo che il threat ha installato se stesso, esportato i files e ottenuto alcune informazioni dal sistema, contatta il server sul porto 80 ed invia alcune informazioni di base riguardanti il computer compromesso via HTTP. Per implementare un server di questo tipo Stuxnet utilizza due indirizzi (conosciuti): • www.mypremierfutbol.com • www.todaysfutbol.com I due URL sono stati localizzati in Malesia e Danimarca. Il threat ha la capacità di aggiornare se stesso con nuovi comandi e nuovi controlli, ma non sono stati mai trovati dei file con delle configurazioni aggiornate. Un file di configurazione chiamato %Windir%\inf\mdmcpq3.PNF viene letto, le informazioni di configurazione aggiornate, ottenute da questo file, sono scritte nella DLL principale e la checksum viene ricalcolata per assicurare che il file sia corretto. Le informazioni che il server raccoglie sono inviate secondo un formato ben preciso: Part 1: • 0x00 byte 1, fixed value • 0x01 byte from Configuration Data (at offset 14h) • 0x02 byte OS major version • 0x03 byte OS minor version • 0x04 byte OS service pack major version • 0x05 byte size of part 1 of payload • 0x06 byte unused, 0 • 0x07 byte unused, 0 • 0x08 dword from C. Data (at offset 10h, Sequence ID) • 0x0C word unknown • 0x0E word OS suite mask • 0x10 byte unused, 0 • 0x11 byte flags • 0x12 string computer name,null-terminated • 0xXX string domain name, null-terminated Part 2, segue la parte 1: • 0x00 dword IP address of interface 1, if any • 0x04 dword IP address of interface 2, if any • 0x08 dword IP address of interface 3, if any • 0x0C dword from Configuration Data (at offset 9Ch) • 0x10 byte unused, 0 • 0x11 string copy of S7P string from C. Data (418h) La stringa con offset 11h contiene un bit che è alto se sul PC sono presenti due stringhe all’interno del registro di sistema: • HKEY_LOCAL_MACHINE\Software\Siemens\Step7,value: STEP7_Version • HKEY_LOCAL_MACHINE\Software\Siemens\WinCC\Setup,value:Version Questo bit informa l’attacker se la macchina infetta contiene il software di programmazione Siemens Step7 o WinCC. Per inviare informazioni sul porto 80 Stuxnet utilizza la tecnica di injection sopra riportata tramite il processo iexplore.exe (Internet Explorer), oppure il processo del browser installato sul PC, determinato grazie alla stringa HKEY_CLASSES_ROOT\HTTP\SHELL\OPEN\COMMAND nel registro. Se tutto è andato a buon fine i dati vengono inviati tramite una GET HTTP con il consueto formato [http://]www.mypremierfutbol.com/index.php?data=1234.. Figura 3.5.3: Alcuni comandi del C&C Server 3.6 Escalation Privilege L’escalation privilege è una caratteristica presente in ogni malware, in quanto tramite i diritti d’amministratore all’interno di una macchina, è possibile eseguire qualsiasi operazione. Per ottenere i permessi locali, se essi non sono già disponibili sulla macchina, Stuxnet utilizza due vulnerabilità 0-day, a seconda del Sistema Operativo utilizzato : • Microsoft Windows XP o minori: MS-10-073 Per utilizzare questa vulnerabilità Stuxnet carica un keyboard layout file ad hoc, che permette di eseguire codice con privilegi di sistema. L’escalation privilege avviene quando l’input da tastiera arriva al file Win32k.sys. • Microsoft Windows Vista or 7: MS-10-092 Tale vulnerabilità rappresenta un grave difetto nel progetto originale del servizio: vale a dire il modo in cui è controllatà l’integrità dei metadati che descrivono i processi pianificati. Nei sistemi operativi Windows Vista o successivi, l’Utilità di pianificazione crea un file XML con le informazioni di configurazione per ogni job registrato. Questi file di solito si trovano nella directory %SystemRoot% \ system32 \ Tasks (se non altrimenti specificato) e contengono informazioni come: il tipo di job, il percorso del file eseguibile e gli argomenti della riga di comando,l’ account che l’eseguibile potrà avviare, i privilegi ottenuti e così via. Algoritmo 3.1 File XML di configurazione 1 2 3 4 5 6 7 8 9 10 11 12 <Principalstt <Principal id="LocalSystem"tt <UserIdttS-1-5-18</UserIdtt <RunLevelttHighestAvailable</RunLeveltt </Principaltt </Principalstt <Actions Context="LocalSystem"tt <Exectt <CommandttC:\WINDOWS\NOTEPAD.EXE</Commandtt <Argumentstt</Argumentstt </Exectt </Actionstt La sezione “Principals” definisce i privilegi richiesti dal task (in questo caso NOTEPAD.EXE). Questo file è leggibile dall’utente anche se non ha i diritti di amministratore, e per garantire la sua protezione viene utilizzato un controllo di integrità CRC32. La falla di questa vulnerabilità sta proprio nell’algoritmo di calcolo della checksum scritto in Python, in quanto è molto utile nel ritrovare errori casuali, ma non in grado di individuare quelli intenzionali. Infatti Stuxnet dopo aver sostituito i valori nel file, aggiunge uno speciale commento del tipo <!–XY–tt ,per ottenere lo stesso valore di cheksum iniziale. 3.7 Infezione del PLC I dispositivi PLC vengono caricati con blocchi di codice e dati scritti utilizzando una varietà di linguaggi, ad esempio AWL o SCL. Il codice compilato,nel caso di PLC Siemens, è un assembly denominato MC7. Questi blocchi vengono poi gestiti dal PLC, per eseguire, controllare e monitorare un processo industriale. Il file di libreria s7otbxdx.dll, presente sulla macchina destinata alla programmazione del dispositivo di controllo, è responsabile dello scambio di codice tra il PC (dispositivo di controllo) e il PLC. Sostituendo questo file, Stuxnet è in grado di eseguire le seguenti operazioni: 1. monitorare i blocchi scritti e letti dal PLC 2. infettare il PLC inserendo il proprio blocco o infettando quelli esistenti 3. mascherare che il PLC è infetto Il file s7otbxdx.dll contiene diverse funzioni che consentono di leggere e scrivere da e sul PLC. Per sostituire questo file, Stuxnet lo rinomina in s7otbxsx.dll e rimpiazza il file originale con la sua versione modificata. Questo file contiene tutte le export del file originale di cui solo alcune sono modificate (funzioni dedicate alla lettura e scrittura di blocchi di codice su PLC). è anche tramite queste funzioni che Stuxnet riesce a mascherare il codice maligno che si trova sul PLC. I blocchi più comuni all’interno dei PLC sono : a. Data Blocks DB (contengono dati come strutture, numeri) b. System Data Blocks SDB (contengono informazioni su come il PLC è configurato e sono creati in base ai moduli collegati al PLC) c. Organization Blocks OB (punto di ingresso dei programmi che vengono eseguiti ciclicamente dalla CPU) Per quanto riguarda Stuxnet due sono gli OB colpiti: 1. OB1 è il principale punto di ingresso del programma PLC eseguito ciclicamente senza requisiti di tempo specifici 2. OB35 che ha il compito di monitorare input critici al fine di rimediare immediatamente d. Functional Blocks FB (blocchi di codice standard eseguito dal PLC) 3.7.1 Processo di infezione del plc Stuxnet infetta un PLC tramite l’utilizzo di codici differenti a seconda del modello. L’infezione consiste nell’injection di dati e codice. Il virus contiene 3 sequenze di infezioni (A , B , C , di cui l’ultima è implementata solo in parte). Inizialmente se la DLL è eseguita all’interno del file ccrtsloader.exe, s7otbxdx.dll esegue due threads responsabili dell’infezione: 1. Il primo lancia una routine di infezione ogni 15 min grazie alle informazioni raccolte dalla DLL sostituita con quella infetta. Questa routine colpisce solo le CPUs 6ES7- 315-2 (series 300) con SDB speciali. La sequenza dell’infezione è di tipo A o B 2. Il secondo thread interroga un blocco iniettato dal primo e determina se eseguire l’infezione A o B. Il thread che viene eseguito ogni 15 min esegue alcune operazioni standard: 1. Riconosce il tipo di PLC tramite la funzione s7ag_read_szl API. Deve essere un PLC della famiglia 6ES7-315-2 2. Analizza i blocchi SDB per vedere quale PLC potrebbe essere infettato e con quale sequenza (A o B) 3. Se queste due azioni vanno a buon fine inizia l’infezione. Il blocco DP_RECV è copiato su FC1869 e rimpiazzato con il codice malevolo 4. Il codice malevolo è scritto sul PLC 5. OB1 viene infettato ed il codice è eseguito all’inizio del ciclo 6. OB35 viene infettato. Siccome è una guardia potrebbe stoppare OB1. 3.7.1.1 Checking degli SDB (System Data Block) In questa fase Stuxnet va ad analizzare gli SDB all’interno del PLC per vedere quale sequenza infettiva utilizzare (A o B). Questo perché essi specificano quale tipo di convertitore di frequenza è utilizzato. I convertitori di frequenza hanno il compito di controllare elementi come motori. Siccome essi possono essere prodotti da due case diverse (Vacon e Fararo Paya) vengono utilizzate due tecniche differenti di infezione. 3.7.1.2 DP_RECV replacement è un blocco funzionale non standard utilizzato dai coprocessori di rete atto a ricevere pacchetti sul bus di comunicazione utilizzato (Profibus). Il blocco originale viene rimpiazzato con quello malevolo ed ogni volta che si riceve un pacchetto questo viene intercettato da Stuxnet. 3.7.1.3 OB1/OB35 infection Stuxnet utilizza la tecnica del codice anteposto per infettare gli OB, andandone quindi ad aumentare la dimensione.Praticamente le due sequenze sono quasi identiche ed hanno il compito di intercettare i pacchetti sul Profibus, generare informazioni corrotte e mandarle sul canale. Queste azioni sono controllate da una complessa macchina a stati finiti. Figura 3.7.1: FSM del processo di corruzione di un PLC Per individuare i PLC infetti basta analizzare i file OB1 e OB35 in quanto presentano tutti la stessa entry inserita da Stuxnet. Il codice modificato anteposto ad ogni blocco è riportato di seguito: Algoritmo 3.2 Codice Assembly anteposto al blocco OB1 1 2 3 4 5 6 UC FC1865 POP L DW#16#DEADF007 BEC L DW#16#0 L DW#16#0 ==D Algoritmo 3.3 Codice Assembly anteposto al blocco OB32 1 2 3 4 5 6 UC FC1874 POP L DW#16#DEADF007 BEC L DW#16#0 L DW#16#0 ==D 3.8 Come Stuxnet deteriora le centrifughe All’interno dei record nelle frame inviate sul bus viene inviato il valore di frequenza relativo al dispositivo controllato. Questo valore è contenuto sempre nello stesso punto delle frame (offset 0xc) ed è indicato come PD1. I valori di frequenza sono rappresentati in Hertz o deciHertz. Per capire quale unità di misura si sta utilizzando, Stuxnet analizza il valore memorizzato e se esso è superiore a 1210 assume che si sta operando in deciHz. La routine che conta i record viene chiamata una volta al minuto. Per passare dallo stato 1 allo stato 2 si impiegano 12.8 giorni perché si prevedono 60 eventi massimi al minuto e il contatore, inizialmente settato a 1.187.136, deve arrivare a 2.299.104. Negli stati 3 e 4 si inviano le frames che provocano la distruzione delle valvole, in quanto modificano la frequenza massima alla quale lavora il motore e ne controllano il comportamento da remoto (tramite Profibus). Ad esempio nella sequenza A la frequenza viene fatta variare tra tre stati in maniera repentina. Infatti si passa da 1410 Hz a 2 Hz per poi andare a 1064Hz in maniera ciclica. Come sono gestite le informazioni sul bus Esse sono organizzate in record di 28-32 byte con diversi campi di cui 4 fondamentali: • ID specifica il parametro da cambiare • VALUE contiene il nuovo valore di un parametro particolare • CW utilizzato per inviare il comando (run,stop,fault reset) • REF varia da 100% a -100% ed indica la direzione di funzionamento del convertitore di frequenza Come Stuxnet evade i controlli Stuxnet è costituito anche da un’altra sequenza: la sequenza C. Tale routine non è conosciuta alla perfezione in quanto mancano alcune funzioni all’interno della DLL principale e non può essere richiamata. Il suo funzionamento può essere descritto tramite una macchina a stati finiti organizzata in 8 stati: • STATO 0 (WAIT): il codice prevede sei gruppi di 164 periferiche (questi potrebbero essere sei cascate di 164 centrifughe ciascuna). Stuxnet monitora i gruppi e controlla che la somma delle attività per tutti gruppo sia superiore a 297 giorni, oppure per ogni gruppo superiore a 35 giorni. Inoltre tutti i gruppi devono essere attivi per 3 giorni. • STATO 1(RECORDING): vengono creati 7 blocchi (DB8064 –DB8070), ognuno dei quali contiene 3 sotto-blocchi. L’immagine di I/O del processo viene copiata con intervalli di un secondo all’interno dei blocchi, formando così una registrazione di 21 secondi. L’area di ingresso contiene informazioni che vengono passate al PLC da una periferica (ad esempio stato attuale, temperatura, velocità di rotazione). • STATO 2-6 (SABOTAGE): quando la periferica produce un’uscita, la sequenza C la intercetta e si assicura che questa non arrivi al sistema di monitoraggio. Inoltre Stuxnet non attacca tutte le periferiche ma solo alcune scelte in modo pseudo-casuale. In pratica se l’attacco non va a buon fine su una periferica, Stuxnet procede son la successiva. In totale vengono colpite 110 periferiche su 164. Come Stuxnet colpisce le periferiche non si sa, in quanto mancano dei dati. • STATO 7 (RESET): i sette blocchi creati vengono cancellati insieme a valori utilizzati negli altri blocchi. Poi si ritorna allo stato 1. Si ritorna al primo stato anche in caso di errore o se passano più di 7 secondi tra due cicli OB1. Stuxnet registra le frequenze di lavoro regolari dei regolatori di frequenza. Questi valori vengono rimandati indietro a WinCC in modo tale da nascondere i valori reali. E’ possibile riassumere il processo di infezione del PLC tramite il seguente grafico: Figura 3.8.1: Flusso di infezione del PLC 3.9 Lavori presenti in letteratura L’avvento di Stuxnet ha “ispirato” molto la ricerca in merito alla sicurezza di sistemi critici come i Supervisoty Control And Data Acquisition. Molte sono le proposte ritrovate in letteratura per analizzare,quantificare,identificare e limitare un malware così complesso. All’interno di questo paragrafo verrà effettuata una panoramica di alcune delle soluzioni proposte da ricercatori e società di tutto il mondo in merito all’argomento. Possiamo fare una prima suddivisione degli argomenti in base al tipo di ricerca effettuata: 1. Analisi quantitativa 2. Detection del malware 3. Analisi di sistemi critici attaccabili 3.9.1 Analisi quantitativa L’analisi quantitativa è una metodologia di analisi che si basa esclusivamente su dati statistici, misurazioni e comportamenti di un determinato fenomeno. due principali approcci per l’analisi quantitativa sono la costruzione di modelli e la loro soluzione (analitica o tramite simulazione), in cui il comportamento del sistema è riprodotto tramite un modello, e l’osservazione e la valutazione sperimentale (anche con stimoli specifici). La descrizione di varie tecniche e formalismi appartenenti a questi due approcci costituisce il corpo di questo lavoro di tesi. In letteratura sono presenti pochissimi la vori che si focalizzano sull’analisi di un sistema critico affetto da malware Stuxnet-like. Un primo lavoro che si occupa di analisi quantitativa del virus è rappresentato da: 1. Is Quantitative Analysis of Stuxnet Possible?[3] In questo paper si cerca di capire se è possibile condurre un’analisi quantitativa sulla diffusione di Stuxnet. Per raggiungere lo scopo si cerca di modellare ciascun componente del sistema come una catena di Markov a tempo continuo (CTMC), ovvero utilizzare un singolo modello per un PC, una chiavetta USB ed una cartella condivisa come mostrato nella figura sottostante. Figura 3.9.1: CTMs individuali del modello Alcune delle transizioni tra gli stati sono costanti (come le transizioni RR) , mentre altre sono variabili e dipendono dallo stato precedente; in particolare nel modello della USB stick possiamo osservare probabilità differenti di infezione che variano in base al numero delle infezioni. Il modello così ottenuto può essere compilato e simulato andando ad unire i diversi elementi. Ad esempio si potrebbero unire i modelli dei PC e delle cartelle condivise per ottenere una singola rete aziendale. Il modello globale combina poi tutte le reti aziendali. Una volta che il modello finale è stato costruito, la risoluzione di equazioni differenziali permette di analizzare la propagazione di Stuxnet. Limiti del modello In questa rappresentazione del virus possiamo ritrovare però molti limiti, in quanto non compare minimamente la presenza del fattore umano che risulta rilevante nella diffusione del virus. Inoltre non si parla della presenza di C&C server che è uno degli elementi innovati dei malware Stuxnet-like che può far variare le probabilità di diffusione e di attacco del virus. 2. Modeling the Stuxnet Attack with BDMP: Towards More Formal Risk Assessments[19] In questo lavoro gli autori si propongono di modellare un attacco Stuxnet tramite l’utilizzo del formalismo BDMP (Boolean logic Driven Markov Processes) e dimostrare i vantaggi di tale approccio. Dopo una descrizione dell’architettura attaccata da Stuxnet, si individuano le fasi di attacco e i componenti del BDMP. Sulla base dei valori stimati delle probabilità di successo, si da una quantificazione delle principali possibili sequenze che portano alla distruzione fisica dello stabilimento industriale preso di mira. Il lavoro mette in evidenza i vantaggi di BDMP rispetto agli alberi di fallimento spesso utilizzati nella valutazione della sicurezza. Ogni fase di attacco viene mdellata come una foglia di un albero che può assumere tre forme differenti: • Attacker Action Individua un’azione dell’attacker per raggiungere l’obiettivo. In particolare viene modellata come una distribuzione esponenziale con parametro l e MTTS pari ad 1/l. • Timed Security Event Rappresenta un evento necessario per la corretta esecuzione dell’attacco che però non è sotto il controllo dell’attacker. Anche in questo caso si utilizzauna funzione di distribuzione esponenziale. • Instantaneous Security Event Evento non temporizzato, indipendente dalla durata dell’attacco che può avvenire con probabilità g. Un esempio di modello è rappresentato nella figura sottostante, in cui si rappresenta l’attacco a partire dalla fase iniziale (Infiltrazione tramite USB), fino ad arrivare alla compromissione del sistema. I punti in rosso indicano altri due alberi BDMP. Figura 3.9.2: Modello BDMP della diffuzione del virus I vantaggi di questo modello rispetto ad un attack tree sono molteplici, in quanto permettono di definire dei vincoli e dei flussi di esecuzione ben precisi,scandendo le diverse fasi del virus. Limiti del modello Il modello in questione presenta però alcuni limiti legati alla quantificazione delle probabilità e delle distribuzioni in quanto potrebbero variare in base all’architettura. Un’analisi di sensitività potrebbe completare questa analisi.te 3.9.2 Detection del malware Oltre allo sviluppo di metodo di simulazione ed analisi del virus, sono state formulate diverse ipotesi per la detection di un malware Stuxnet-like. In particolare molte soluzioni si basano su tecniche innovative che utilizzano strumenti già presenti. 1. Honeypot Ibrido[17] Le recenti tecniche di difesa contro i malware, prevedono l’uso di honeypots, ovvero delle vere e proprie trappole per gli attacker. Un honeypots espone una vulnerabilità e aspetta di essere attaccato. Appena un utente malintenzionato tenta di attaccare l’honeypot,questo registra tutte le attività dell’attaccante. La soluzione proposta in questo articolo, prevede l’uso di honeypots in concomitanza con rilevamento basato su firma e su anomalie (detta HoneyFarm). Possiamo individuare più livelli: 1) Livello di Signature Based detection 2) Livello di Anomaly Based detection 3) Honeypot Figura 3.9.3: HoneyFarm ibrida per la difesa contro worm I primi due livelli sono usati per tenere traccia delle attività dell’attacker, mentre l’honeypot per scoprire nuove vulnerabilità. • VANTAGGI: Riduzione di falsi allarmi e più precisione nel profilare un worm • SVANTAGGI: Tempo di configurazione elevato 2. Clustering Alghoritm[25] Questo articolo presenta una nuova architettura per la suddivisione di malware accumunati da caratteristiche simili in famiglie. Si analizza la frequenza e la sequenza di istruzioni eseguite da file Portable Execution. Per migliorare l’affidabilità si utilizzano diversi tipi di algoritmi come illustrato in figura Figura 3.9.4: Clustering degli algoritmi (a) Instruction Feature Extractor: estrae le funzioni di base del malware dal file PE e le memorizza in un database (simili a signature) (b) Vengono applicati i due algoritmi di clustering : Instruction Frequency ed Instruction Sequence (c) Vengono combinati i diversi cluster (d) Vengono generate le varie signature per i vari malware (e) Viene fornita un’interfaccia utente per inserire dati da parte di esperti. Per l’estrazione delle features è stata preferita un’analisi statica in quanto l’analisi dinamica richiede un tempo troppo elevato. Se il file è compresso con UPX deve essere decompresso prima di analizzarlo (con K32dasm). 3. Protocol Learning[11] Uno dei problemi legati alla detection dei malware, consiste nell’andare ad individuare la dipendenza che esiste tra un malware e gli host esterni (ad esempio un C&C server nel caso di Stuxnet). Non conoscendo il protocollo usato risulta difficile rilevare le comunicazioni maligne. Soluzione: L’approccio proposto prevede l’uso di tecniche di protocol learning per l’analisi ed il rilevamento di campioni sconosciuti Per studiare il comportamento del malware sono stati utilizzati diversi metodi tutti basati su sandboxes: • Full Internet Access (troppo rischioso) • Filter specific Ports (non conoscendo il malware non si sa quali porte utilizza) • Common service emulation (emulando alcuni servizi si rischia di non comprendere appieno il comportamento del malware) • Full isolation (si inibisce completamente la comunicazione con l’esterno) ScriptGEN Per realizzare il protocol learning ci si sofferma su un tools (ScriptGEN) che permette di definire il linguaggio usato da un protocollo costruendo una FSM in cui ogni nodo corrisponde ad uno stato in seguito ad una risposta dal server ed ogni arco ad una richiesta da parte del client. ScriptGEN utilizza due metodi: • Semantic Clustering (raggruppa messaggi simili) • Region Analysis (generalizza i messaggi del protocollo per individuarne altri simili in futuro) L’approccio proposto prevede le seguenti fasi: (a) Collezione del traffico Analisi degli endpoints ( rimozione di tracce anomale che potrebbero influenzare il risultato) (b) Analisi degli endpoints ( rimozione di tracce anomale che potrebbero influenzare il risultato) (c) Modellazione del traffico( inline o offline a partire dai paccheU raccolti (ScriptGen)) (d) Contenimento del traffico (una volta noto il protocollo si usa un proxy per simulare il mondo esterno, ad esempio un C&C server. Se ci sono messaggi non analizzati si riparte dalla prima fase per espandere la FSM) Questo tipo di analisi permette di scoprire le interazioni del malware con il mondo esterno in modo tale da capirne il funzionamento ed inibirne la diffusione. Potrebbe essere usato anche per modellare le comunicazioni avviate da Stuxnet o Duqu. Figura 3.9.5: Protocol Learning 4. Features Extraction Lo scopo di questo articolo è quella di estrarre alcuni aspetti essenziale da un set di malware in modo tale da generalizzarne il comportamento e facilitarne la detection Partendo da un set di dati relativi a malware, è possibile effettuare due tipi di analisi: (a) statica (analisi del codice) (b) dinamica (tramite lo studio delle API utilizzate) Il metodo proposto mette in atto tre tecniche: (a) Feature selection (Ranking/Pruning) per ridurre le caratteristiche rilevanti (Dimension Reduction) (b) Supervised Classification (efficace solo per malware conosciuti) (c) Unsupervised Classification (preferito agli altri a causa della natura polimorfica dei malware) realizzato tramite suddivisione in clustering dei worm e calcolo delle differenze tra di essi. Molti malware utilizzano sorgenti compresse (.INF, .PNF e così via), e risulta molto difficile eseguire un’analisi di questo tipo su di essi. Per questo è stata proposta una tecnica ulteriore basata sul calcolo dell’entropia sui file binari. Ad esempio è stato effettuato un calcolo dell’entropia su file compressi e cryptati del malware Duqu. Sono stati classificati come sospetti tutti i file con entropia superiore a 0.6 e molti file di Duqu sono stati classificati con entropia pari a 0.9. 5. System Call Based Detection[5] Quello che si vuole fare, è estrapolare un modello che rappresenti ed individui il comportamento di un malware, in base alle chiamate di sistema effettuate. La specifica di detection viene vista come un “modello” che combina delle “signatures”, dove ogni signature è formata da “atomi” che rappresentano operazioni di base del programma in un particolare stato. Quindi un modello rappresenta un’astrazione ad alto livello del programma, mentre le signatures astrazioni a basso livello (lettura di un file di configurazione ad esempio). Si parla di : SIGNATURE MATCHING: quando un programma presenta tutti i passi presenti nella signature in un ordine preciso. MODEL MATCHING: quando il numero di signature matching all’interno di un programma supera una determinata soglia L’articolo propone diverse tecniche per la scelta di un modello comportamentale facendo riferimento a signature diverse, e mette in evidenza come la scelta di alcuni parametri piuttosto che altri sia fondamentale nella costruzione di uno strumento di detection. I modelli migliori sono quelli che si basano su pochi “atomi” di alto livello. 6. Botnet Detection[9] A livello di rete è possibile osservare che le botnet si stanno diffondendo sempre di più verso comunicazioni criptate e reti ad-hoc,molto spesso basate su comunicazioni P2P. Il framework proposto si basa sulla suddivisione dei diversi tipi di connessioni effettuate tramite il Simpson Diversity Index. Tramite questa euristica viene creato un vero e proprio fingerprint per ogni connessione ed è possibile suddividerle in cluster. Tale tecnica ha riscontrato un numero elevato di falsi positivi, che possono essere evitati tramite una whitelist. Il problema di questo framework è evidente nel momento in cui le comunicazioni di una botnet sono ferme, ovvero si invia il solo segnale di keep-alive (come ad esempio nel caso del C&C server in Stuxnet nel momento in cui non bisogna inviare informazioni o richiedere nuove versioni del virus). In questo caso il framework non riesce a rilevare alcuna comunicazione malevola. 3.9.3 Analisi di sistemi critici attaccabili 1. Smart Grid[2] Una smart grid è l’evoluzione di una Power Grid, che controlla e gestisce l’energia evitando sovraccarichi e cali di tensione. Per fare ciò vengono utilizzati sistemi SCADA e quindi PLC. La sicurezza di questi sistemi ha suscitato enorme interesse dopo l’avvento di Stuxnet e sono stati formulati modelli per la simulazione e la sperimentazione di cyber-attacks su questo tipo di infrastrutture. Il framework proposto nell’articolo utilizza: - Emulab testbed per ricreare il comportamento di sistemi SCADA e PLC - Simulazione software per riprodurre i processi fisici Figura 3.9.6: Ambiente simulativo Cyber Attacks Simulation Su questo framework è stato simulato uno scenario in cui l’attaccante è in grado di aumentare il carico di una rete elettrica tramite hardware compromesso. Si considerano 3 bus ( 7, 8, 9 ) PRIMO SCENARIO: Attacco non sincronizzato (I PLC inviano l’attacco indipendentemente). Si può notare una piccola variazione di tensione elettrica e quindi un minor impatto dell’attacco SECONDO SCENARIO: Attacco sincronizzato (I PLC inviano l’attacco in contemporanea ogni 10s. La sincronizzazione dei PLC provoca una vera e propria caduta di potenza che potrebbe portare ad un collasso. Tramite questo framework è possibile simulare gran parte dei sistemi industriali e testarne gli attacchi. Di seguito sono rappresentati i risultati ottenuti Figura 3.9.7: Risultato attacchi SMART GRID Nelle misurazioni effettuate nel paper analizzato sono stati individuati due casi di studio: • Caso di studio 1: The Effect of Stuxnet on a Boiling Water Power Plant DESCRIZIONE DELL’ESPERIMENTO L’esperimento comprende 3 unità : una turbina, una caldaia ed un gruppo elettrogeno. Si usano 3 PLC, uno per ogni valvola. La rete è stata configurata tramite NS. Solo il PLC che controlla la valvola del vapore è infetto. Il processo di infezione inibisce il normale funzionamento dell’unità R-PLC1 e ne sostituisce il codice. Il codice maligno apre e chiude la valvola. RISULTATI DELL’ESPERIMENTO Il comportamento anomalo del singolo PLC infetto comporta una variazione notevole nei valori di pressione, e corrente (pressione : da 107 a 114 kg/cm2 , corrente da 0 a 108 MW). Questo può portare alla rottura di componenti come trasformatori. Questo caso di studio mostra come sia possibile simulare un impianto industriale e controllare gli effetti di un cyber attack tramite il framework descritto nell’articolo. Figura 3.9.8: Architettura presa in esame per il primo caso di studio • Case Study 2: The Effect of Network Parameters on a Cyber Attack Targeting a Chemical Process DESCRIZIONE DELL’ESPERIMENTO Il modello di attacco utilizzato cerca di provocare un arresto del processo fisico tramite l’invio di pacchetti leggittimi sul bus ai PLC. Quello che si va ad analizzare è il tempo che un processo impiega ad arrestarsi dal momento dell’attacco. I pacchetti vengono inviati con ritardi che variano dai 0 ai 3 secondi e la percentuale di pacchetti persi dallo 0% al 10%. RISULTATI DELL’ESPERIMENTO L’esperimento ha dimostrato che il ritardo di pacchetti sulla rete e la loro perdita influenzano minimamente i tempi di shut down di un processo, senza provocare danni. Figura 3.9.9: Architettura presa in esame per il secondo caso di studio Capitolo 4 Metodologia e modello del sistema Lo studio e l’analisi di un’architettura reale caratterizzata da vincoli real-time,di dependability e availability molto stringenti, in molti casi non è fattibile tramite un sitema reale, e quindi, si preferisce ricorrere a strumenti teorici presenti in letteratura, con l’obiettivo di ottenere una stima, il più realistica possibile, del comportamento del sistema. La difficoltà o l’impossibilità di studiare un sistema a partire dalla sua architettura reale costringe l’analista alla formalizzazione del problema attraverso i modelli. Nell’uso scientifico e tecnico-progettuale, un modello è una rappresentazione di un oggetto o di un fenomeno, che corrisponde al fenomeno modellato con l’intento di riprodurne alcune caratteristiche o comportamenti fondamentali, in modo tale che questi aspetti possano essere mostrati, studiati, conosciuti laddove l’oggetto modellato non sia direttamente accessibile. La costituzione di un modello scientifico o tecnico, per quanto possa essere genericamente orientata o guidata in partenza da una teoria metafisica, è sempre il risultato di un contesto della prova rigoroso, predisposto in modo tale da non essere minimamente influenzato dalle aspettative e dall’interpretazione soggettiva dell’osservatore (si dice che l’osservazione e l’esperienza scientifiche, su cui si fonda la formulazione di modelli teorici validi, sono invarianti rispetto all’osservatore).[reference Wikipedia -modello]. Nel presente capitolo verranno presentati le diverse tecniche di modellazione presenti 77 in letteratura e la realizzazione del modello tramite il formalismo scelto. Il sistema da analizzare è stato realizzato riprendendo lo schema descritto nel primo capitolo, cercando di costruire un’architettura reale semplificata. 4.1 Modelli I formalismi per lo studio dell’affidabilità dei sistemi dependable possono dividersi in due grandi categorie: quelli che seguono un approccio di modellazione top-down (o deduttivo) e quelli di tipo bottom-up (induttivi), a seconda che l’analisi parta dal fallimento a livello di sistema o da un guasto degli elementi. Il formalismo storicamente più diffuso per le analisi top-down è quello degli Alberi dei Guasti (Fault Trees, FT), mentre per le analisi bottom-up il formalismo di maggior successo è quello dei Diagrammi a Blocchi Affidabilistici (Reliability Block Diagrams, RBD). Entrambi questi formalismi si prestano ad analisi di tipo combinatoriale, che ne limita la potenza espressiva. Per esempio, RBD e FT non consentono la modellazione di tipi di guasto di modo comune, cioè guasti simultanei ad unità identiche causati dallo stesso motivo e nello stesso modo, e quindi tali da far cadere l’ipotesi di indipendenza tra le probabilità di guasto dei singoli costituenti. Per ovviare a tali limitazioni, possono essere impiegati formalismi basati sull’analisi dello spazio di stato, quali catene di Markov a tempo continuo (Continuous Time Markov Chains, CTMC) e reti di Petri temporizzate o stocastiche (Timed/Stochastic Petri Nets, TPN/SPN). Tali formalismi consentono tra le altre cose una modellazione dettagliata degli aspetti di manutenibilità (diagnostica e recupero dagli errori). Esistono diversi altri formalismi impiegabili per l’analisi dei sistemi dependable, tra cui gli automi temporizzati (Timed Automata, TA), i diagrammi di decisione binari (Binary Decision Diagrams, BDD) e le algebre dei processi (Process Algebras, PA), che possono risultare utili per l’analisi di particolari proprietà o attributi real-time. Inoltre, formalismi nati per scopi diversi sono risultati utili per l’analisi di certi aspetti dei sistemi depen- dable. Tra questi è opportuno citare le reti di code (Queueing Networks, QN), utili per modellare aspetti di performability in congiunzione con altri formalismi, e le reti bayesiane (Bayesian Networks, BN), che consentono di estendere la potenza espressiva degli alberi dei guasti senza incorrere nel problema dell’esplosione dello spazio di stato. Infine, sono stati definiti dei formalismi derivati da quelli “base” sopra menzionati, aggiungendo varie estensioni e ricorrendo a metodi di soluzione spesso basati sulla traduzione dei modelli in formalismi con potenza espressiva più elevata. È il caso ad esempio degli alberi dei guasti, di cui sono state definite diverse estensioni (dinamici, parametrici, riparabili ecc.). Modelli espressi in taluni formalismi (per esempio, SPN,Stochastic Activity Network) si prestano sia ad analisi di tipo quantitativo (esempio, tasso di fallimenti) che di verifica di proprietà (esempio, raggiungibilità di uno stato non sicuro). Altri (esempio, BN) consentono analisi qualitative sia di tipo “what if?”, finalizzate a valutare quali sono le conseguenze provocate dal verificarsi di una determinata condizione, che di tipo “backward” (a ritroso) o di “most probable explanation” (spiegazione più plausibile), che hanno lo scopo di valutare le cause (esempio, guasti) a partire dagli effetti (esempio, fallimenti), e pertanto risultano particolarmente adatti ad analisi di sensitività parametrica o anche, in fase operativa, di tipo diagnostico. Anche linguaggi per la specifica di sistemi, quali UML (Unified Modeling Language) e SysML (Systems Modeling Language), sono impiegabili per analisi formali di dependability [reference MODELLI PER L’ANALISI DI SISTEMI CRITICI Flammini]. Figura 4.1.1: Formalismi e potenza espressiva 4.2 Metodologia di analisi utilizzata Lo studio di sistemi complessi richiede una attenta definizione del suo comportamento che porta all’analisi del sistema stesso. La metodologia utilizzata a tal fine prevede i seguenti passi fondamentali: 1. Definizione del contesto: questa fase prevede la corretta descrizione del contesto in cui si opera. In particolare è possibile utilizzare formalismi con alto livello di astrazione per individuare le attività ed i componenti principali del sistema 2. Definizione degli obiettivi: Definire l’obiettivo vuol dire identificare a pieno il problema,eliminando qualsiasi dubbio. 3. Assunzioni di base: bisogna valutare ogni possibile assunzione da prendere in considerazione per la semplificazione del modello: un modello costruito con un numero troppo elevato di dettagli rischia di diventare più complesso del sistema reale e di difficile interpretazione. Al contrario una semplificazione eccessiva del modello può portare ad una perdita di accuratezza e di precisione dei risultati. 4. Costruzione del modello: questa fase di progettazione prevede la formalizzazione di un modello in grado di combinare accuratezza e semplicità, fornendo informazioni dettagliate, ma ad un costo, in termini di tempi e risorse, accettabile. Il modello deve essere attinente al sistema reale e garantire risultati corretti. 5. Progetto degli esperimenti. La definizione di esperimenti consente di capire se il modello costruito è attinente a quello reale. Gli esperimenti possono essere condotti seguendo un approccio di tipo interattivo o di tipo comparativo: nel primo caso, si osserva il funzionamento del sistema assegnando valori standard ai parametri, nel secondo casi si attribuiscono valori diversi allo stesso parametro per selezionare la soluzione che ottimizza le metriche prestazionali individuate nelle fasi iniziali. 6. Analisi dei risultati: i risultati ottenuti dalla simulazione, strettamente legati a variabili di decisione o di prestazione, devono essere interpretati ed analizzati allo scopo di verificare la correttezza del modello e convalidare i valori dei parametri selezionati. Il formalismo scelto per realizzare un modello semplificato del sistema SCADA utilizza le Stochastic Activity Network. 4.2.1 SAN Stochastic Activity Network Le reti SAN costituiscono un sottoinsieme delle reti di Petri in cui le transizioni, o attività, possono essere istantanee o temporizzate, secondo un durata stabilita da una certa distribuzione di probabilità: inoltre, è possibile descrivere l’incertezza nell’esito di un’attività attribuendo ad essa più casi possibili di uscita (ad ognuno dei quali è associata una certa probabilità). Le SAN comprendono caratteristiche sia delle reti di Petri stocastiche che dei modelli di code. Strutturalmente una rete SAN è costituita dai seguenti elementi : Figura 4.2.1: Elementi SAN • attività (activities), • posti (places), • porte di ingresso e di uscita (input gates e output gates). Le attività, o le transizioni nella terminologia propria delle reti di Petri, possono essere di due tipi: temporizzate e istantanee. A differenza delle reti di Petri, nelle reti SAN alle attività possono essere associate a dei casi di uscita (cases) che rappresentano le scelte possibili in uscita da un’attività. I posti possono essere associati ad una marcatura, ovvero possono contenere un numero finito di gettoni (token). Le porte di ingresso e di uscita sono state introdotte per aggiungere flessibilità nel definire le regole di abilitazione e di completamento. Le reti SAN presentano le seguenti proprietà: • un modo generale per specificare che un’attività è abilitata; • un modo generale per specificare una regola di completamento (scatto) di un’attività; • un modo per rappresentare eventi di durata nulla; • un modo per rappresentare delle scelte probabilistiche dopo il completamento di un’attività; • valori dei paramenti che possono dipendere dallo stato della rete; • le distribuzioni dei ritardi delle attività non sono necessariamente esponenziali. La natura stocastica della rete è realizzata associando una funzione di distribuzione del tempo di completamento ad ogni attività, e una distribuzione di probabilità ad ogni caso di uscita. Entrambe le distribuzioni possono dipendere dalla marcatura globale della rete. In prima approssimazione si può dire che una rete SAN viene eseguita nel tempo attraverso il completamento delle attività, che comportano il cambiamento dello stato delle marcature. In ogni istante di simulazione, una ed una sola attività viene schedulata per il completamento. Una volta scelta l’attività che deve completare, viene scelto il caso di uscita, basandosi sulle relative distribuzioni di probabilità. Queste due scelte determinano unicamente la marcatura successiva della rete, che è poi ottenuta eseguendo le funzioni delle porte di ingresso e uscita collegate all’attività ed al caso di uscita scelti. Questa procedura è poi ripetuta considerando le attività abilitate nella nuova marcatura. Una porta di ingresso è caratterizzata da una funzione di abilitazione (enabling predicate) e da una funzione di ingresso. Un’attività è abilitata se per ogni porta di ingresso collegata, il predicato di abilitazione è vero e se, per ogni arco di ingresso, il numero di gettoni nel posto collegato è maggiore o uguale al numero di archi. L’attività viene eseguita nel momento in cui risulta vero un Input Gates oppure il numero di oken all’interno del Place collegato è maggiore di zero. Figura 4.2.2: Attività e collegamenti in una rete SAN Le SAN si possono risolvere sia per via analitica che per via simulativa, a seconda delle caratteristiche del modello. Infatti non tutti i modelli possono essere trasformati in catene di Markov. Per risolvere modelli realistici è necessario avvalersi di appositi tool software. In questo lavoro di tesi si è utilizzato uno specifico tool, denominato MOBIUS. Per misurare le caratteristiche del modello si utilizzano delle variabili dette reward variables che possono essere associate sia a places che a delle Activities. Le reward variables sono molto generali ed espressive, permettendo da sole di valutare grandezze diverse. Ogni reward variable, è infatti composta da due sottocampi, a loro volta contatori: • una componente impulsiva (impulse reward), definita sulle attività, il cui valore si incrementa ad ogni completamento di un’attività; • una componente continua (rate reward), definita in base alle marcature dei posti, il cui valore si incrementa per tutto il tempo in cui il modello si trova in certi stati, secondo una opportuna legge. Data la natura stocastica delle SAN, si ha che una reward variable è una variabile aleatoria, per cui in molti casi è complicato ottenerne la distribuzione precisa. Spesso è più semplice trovarne la media e la varianza, specialmente se si utilizzano tecniche numeriche/simulative, come un tool software. 4.3 Modello realizzato Il modello realizzato è stato costrutito facendo riferimento alle tecniche utilizzate nel [18] per creare modelli probabilistici intrusion-tolerant. Il sistema modellato è costituito principalmente da 4 elementi: • Host (Operator System) • Engineering Station • Database (per la raccolta delle informazioni) • PLC L’architettura utilizzata per l’analisi del comportamento del virus è costituita da: • 6 Host all’interno della Enterprise Network • 1 Database raggiungibile sia dalla Enterprise Network che dalla Control Network • 4 Engineering Station all’interno della Control Network • 1 PLC connesso a tutte le ES La quantità di elementi utilizzata è stata scelta in scala in base all’architettura precedentemente descritta. Esaminiamo i diversi elementi del modello partendo dall’analisi probabilistico-temporale del virus. 4.3.1 Host Un host all’interno di una Enterprise Network è un PC con Sistema Operativo Microsoft Windows, che ha il compito di fornire alcune funzionalità all’utente finale come lettura informazioni da database, connessione internet, connessione LAN, stampa di documenti e così via. Per modellare il suo comportamento sotto un attacco Stuxnet-like, sono state fatte alcune assunzioni. 4.3.1.1 Assunzioni del modello Ogni host è un PC appartenente ad una Enterprise Network (EN), ovvero avente accesso ad Internet ed al Database. Tutti gli host sono collegati in LAN e possono essere infettati tramite diversi meccanismi: • Dispositivi removibili • Print Spooler vuln • Server Service RPC vuln • Step7 Project vuln • Database compromise • Network Shares vuln L’avvio dell’attacco è stato simulato con l’inserimento di un dispositivo USB infetto all’interno di uno degli Host presenti nella EN. La diffusione del virus all’interno degli altri Host della LAN può avvenire tramite le vulnerabilità sopra descritte, con tempi differenti. Condizioni di infezione: 1. Print Spooler vuln , Server Service RPC vuln e Network Shares vuln possono essere utilizzate se almeno un host è stato infettato. 2. Step7 Project vuln può essere usata se è stato infettato almeno un progetto. 3. Database compromise può essere usata se il Database è stato infettato. Figura 4.3.1: Possibilità di infezione di un host La figura rappresentata, indica tutte le possibili vulnerabilità che Stuxnet può utilizzare per infettare un determinato host all’interno della LAN. 4.3.1.2 Tempi e probabilità scelti per il modello Ogni tentativo di attacco è stato modellato con una Timed Activity in cui i tempi sono espressi tramite una distribuzione esponenziale con rate l. Il TTS (Time To Success espresso in giorni) di ogni attività è stato recuperato da studi precedenti: T T S = 1/l÷86400 Le informazioni riguardanti il modello sono riportate all’interno della tabella sottostante Timed Activity l Probabilità Removable_Media 5.79e-6 Network_Shares 1.39e-4 0.7 2 hours Print_Server 9.25e-5 0.7 3 hours Service_Server_RPC 2.77e-4 0.7 1hours Database_Vuln 2.77e-4 0.7 1hours Escalation_Privilege 0 0.7 0 Installing_Rootkit 0 0.8 0 FirewallRouterPermission 0 0.8 0 RestorePC 8.36e-7 0.2 1 mounth Server_Attack 5.79e-6 0.5 2 days Install Remote Server 5.79e-6 InfectOtherUsb 5.79e-6 0.8 2 days OpenFileProject 1.16e-5 0.5 1 day DataTransferAndUpdate 5.79e-6 1 2 days 0.4+(USB_Infection>Mark()*0.05) +(Project_Infected>Mark()*0.05) (0.3+(UpdateOK>Mark()*0.1)) TTS 2 days 2 days Tabella 4.1: Probabilità e TTS delle attività del modello Host Ogni host all’interno della Enterprise Network può attaccare il Database presente all’interno della Perimeter Network con una probabilità pari a 0.5, in quanto si sta supponendo che solo il 50% degli host possa eseguire operazioni sul DB. 4.3.1.3 Stochastic Activity Network dell’Host La rete SAN raffigurata, rappresenta il comportamento tipico di un host della Enterprise Network sotto l’influenza del malware Stuxnet. Inizialmente un host si trova nello stato NotInfected, che rappresenta il normale funzionamento del PC. L’inserimento di un dispositivo USB infetto è rappresentato tramite due activity: • USB_Infected Activity istantanea che rappresenta il punto di ingresso di diffusione del virus. • Removable_Media Evento temporizzato che rappresenta l’inserimento di un dispositivo USB qualunque (Infetto o meno) la cui probabilità varia in base al numero di host infettati. Le altre activity collegate allo stato NotInfected rappresentano le diverse vulnerabilità utilizzate dal virus. Una volta che il virus ha avuto accesso al PC si passa nello stato di Check, ovvero la fase in cui il virus controlla che il sistema abbia determinati requisiti: • Sistema a 32 bit • Windows OS • OS non patchato Se l’host attaccato non possiede questi requisiti, il virus esce dalla fase di installazione portandosi nello stato di Exit, altrimenti cerca di ottenere i diritti di amministratore tramite l’utilizzo di due vulnerabilità che variano a seconda del Sistema Operativo utilizzato. Questa fase è rappresentata tramite l’Instantaneous Activity “Escalation Privilege”. Una volta ottenuti i diritti, il virus tenta di installare due driver, destinati all’esecuzione del malware anche in caso di reboot del sistema. Se l’operazione va a buon fine il sistema passa dallo stato NotInfected allo stato Host_Infected. L’activity RestorePC prevede la possibilità per un host di recuperare le normali funzionalità prima che il virus venga installato (tramite formattazione o detection da parte di un antivirus). Nel momento in cui il sistema viene infettato, il virus tenta di eseguire sei azioni differenti: 1. Connessione ad un Server di Comando e Controllo esterno 2. Avvio Server RPC per comunicazione P2P 3. Ricerca ed attacco Database 4. Infettare altri dispositivi USB 5. Infettare altri host tramite diverse vulnerabilità 6. Infettare progetti Step7 Figura 4.3.2: Rete SAN dell’Host 4.3.2 Engineering Station 4.3.2.1 Assunzioni del modello Nel modello si suppone che le ES possano essere infettate solo in due modi: • Inserimento di un dispositivo infetto all’interno della stessa • Apertura di un progetto da DB infetto Questa supposizione viene fatta perché ,a volte, all’interno di un sistema SCADA, per motivi di sicurezza, si preferisce utilizzare una vera e propria separazione fisica tra la Enterprise Network e la Control Network detta Air Gap. Lo scopo del virus è quello di infettare più host possibili per aumentare la probabilità di inserire un dispositivo USB infetto all’interno di una ES. Ogni ES una volta infettata avrà una determinata probabilità di infettare il PLC ad essa collegato legata all’evento “Apertura progetto infetto da parte dell’utente”. Nel modello di suppone che qualsiasi Engineering Station può modificare il comportamento del PLC in quanto l’architettura presa in esame, prevede l’utilizzo di un bus di collegamento tra Automation System ed Engineering Station, come rappresentato in figura. Figura 4.3.3: Collegamento tra Engineering Station e PLC 4.3.2.2 Tempi e probabilità scelti per il modello Ogni tentativo di attacco è stato modellato con una Timed Activity rappresentata da una distribuzione esponenziale in cui il Success Rate è dato da 1/l. Il TTS (Time To Success) di ogni attività è stato recuperato da studi precedenti e da analisi sul modello. Timed Activity l Probabilità InsertUSB 7.7e-7 (0.2+(USB_Infection>Mark()*0.08)) 15 days DatabaseVuln 7.7e-7 (0.2+(Project_Infected>Mark()*0.08)) 15 days Escalation_Privilege 0 0.7 0 Installing_Rootkit 0 0.8 0 FirewallRouterPermission 0 0.4 0 RestorePC 8.36e-7 0.2 1 mounth Install Remote Server 5.79e-6 InfectOtherUsb 5.79e-6 0.8 2 days OpenProject 5.79e-6 1 2 days DataTransferAndUpdate 5.79e-6 1 2 days (0.3+(UpdateOK>Mark()*0.1)) TTS 2 days Tabella 4.2: Probabilità e TTS delle attività del modello Engineering Station Si suppone che l’inserimento di un dispositivo USB all’interno del PC o l’apertura di un progetto avvenga ogni 15 giorni.La probabilità che un dispositivo venga infettato tramite USB dipende dal numero di dispositivi che sono stati infettati all’interno della Enterprise Network, mentre la probabilità di infettare una ES tramite DB dipende dal numero di progetti infettati presenti all’interno del database. Le altre attività sono identiche al modello dell’Host, a differenza di “OpenProject” che rappresenta l’apertura di un progetto presente sulla ES, tramite il quale sarà possibile infettare il PLC ad essa collegato. Il valore di probabilità utilizzato nelle prime due activity del modello ES ha la seguente forma: P = w 1 + X ⇤ k1 dove: • P rappresenta la probabilità che l’azione vada a buon fine • w1 è un peso associato all’evento. Rappresenta la minima probabilità che quel determinato evento si verifichi. • X è il numero di token di un place del modello • k1 = N ° max di token (w1 ⇤ 0.01) è il valore compreso tra [0, 1 w1] per raggiungere la probabilità massima. 4.3.2.3 Stochastic Activity Network di una Engineering Station Il modello di una Engineering Station è molto simile a quesllo di un semplice Host, in quanto le fasi di infezione sono esattamente le stesso, avendo Microsoft Windows come O.S.. Come possiamo notare dalla Tabella 4.2 la probabilità di bypassare il firewall è molto più bassa rispetto ad un host, poiché stiamo assumendo che ci siano dei requisiti di sicurezza maggiore. Figura 4.3.4: Rete SAN di una Engineering Station 4.3.3 PLC 4.3.3.1 Assuzioni del modello Per quanto riguarda il modello del PLC, esso attraversa tre fasi principali: • NotInfected • Infected • Corrupted La mission del sistema è compromessa nel momento in cui il PLC passa dallo stato Infected allo stato Corrupted in cui inizia ad inviare falsi comandi ai dispositivi. La modellazione del comportamento del PLC è stata fatta analizzando le diverse fasi che Stuxnet attraversa per andare a modificarne il comportamento dei dispositivi fisici e nascondersi all’operatore. In particolare, le fasi sono sei e sono rappresentate tramite una macchina a stati, le cui transizioni da uno stato ad un altro sono scandite da eventi: 1. Recording data Registrazione dei dati provenienti dai dispositivi fisici all’interno di una porzione di memoria istanziata da Stuxnet 2. Timer 2h Durante questa fase Stuxnet non effettua operazioni 3. Timer da 15 a 50 minuti 4. Invio Frame A questo punto si possono verificare due eventi : (a) Stuxnet resetta i suoi dati e riparte dal primo stato della macchina a stati (b) Si verifica un errore dovuto all’esecuzione prolungata di un OB all’interno del PLC , ed in particolare dell’OB1. In questo caso si attiva un timer di 5 ore, dopodiché Stuxnet riprende le sue normali operazioni ritornando nello stato 1. 4.3.3.2 Tempi e probabilità scelti per il modello I tempi delle attività relative al modello del PLC sono stati recuperati da documenti ufficiali messi a disposizione da società di sicurezza come Symantec ed Eset. Timed Activity l Probabilità TTS Recording 3.86e-7 1 1 mounth Two_H_Timer 1.39e-4 1 2 hours Sending Frames 3.33e-4 1 50 mins IA1 Istantanea 0.8 0 Five_h_Timer 5.55e-5 1 5hours Tabella 4.3: Probabilità e TTS delle attività del modello PLC 4.3.3.3 Stochastic Acitivity Network di un PLC Figura 4.3.5: SAN di un PLC 4.3.4 Architettura completa L’architettura totale è stata realizzata tramite gli strumenti Rep/Join messi a disposizione dal tool Mobius. In particolare si è preferito utilizzare soltanto lo strumento Join per far variare singolarmente i diversi componenti del sistema. Figura 4.3.6: Composizione del modello I diversi sottomodelli sono stati collegati tramite le seguenti variabili condivise: • Numero di host infettati : La variabile consente di mantenere aggiornato il numero di host che vengono infettati all’interno della Enterprise Network e viene utilizzata per calcolare la probabilità di inserimento di un dispositivo USB infetto all’interno di una Engineering Station. • Update effettuati: Consente di capire quanti host ed ES sono riusciti a stabilire una connessione con l’esterno o ad avviare una comunicazione P2P, per richiedere versioni aggiornate del malware. Tale dato viene utilizzato per far variare la probabilità di infezione del sistema in quanto la possibilità di connessione verso l’esterno consente una maggiore conoscenza dell’intera architettura e ,quindi, lo sviluppo di software specializzato. • Database infettato: Appena si entra in questo stato è possibile sfruttare un’ulteriore vulnerabilità del sistema legata alle query SQL effettuate da un host verso il DB. • Numero di USB infettate: il numero di dispositivi USB infettati all’interno della rete consente di far variare la probabilità con la quale un host ed una ES vengano infettati. • Numero di progetti infettati: il numero di ogetti infettati all’interno della rete consente di far variare la probabilità con la quale un host ed una ES vengano infettati. • Ogni host è collegato al database tramite la variabile condivisa DB_Attacked che consente di scatenare un attacco al DB. • Infezione PLC: è una variabile condivisa solo tra Engineering Station e PLC, che consente al virus di sovrascrivere i blocchi del PLC con quelli corrotti. • USB : consente di collegare ad un qualsiasi host, o a più di uno un dispositivo USB infetto per avviare l’infezione Capitolo 5 Analisi e simulazione del modello L’analisi e lo studio di sistemi critici attraverso esperimenti sul sistema reale, richiede uno sforzo notevole in termini di tempo di esecuzione e costo di attuazione, a causa della grande mole di dati che si vuole far variare per carpire ogni aspetto del sistema. Per questo, molto spesso, si ricorre ad un processo di simulazione tramite software dedicati in grado di emulare il “comportamento” del sistema reale in tempi e costi contenuti. Il seguente capitolo si divide in diverse sezioni riguardanti le fasi di analisi attraversate durante lo studio: 1. Studio del comportamento del sistema affetto da un virus Stuxnet-like 2. Sensitivity Analysis sul modello 3. Studio dei parametri più incisivi tramite analisi della varianza (ANOVA) 4. Esperimenti sul modello in presenza di diversity Infine verranno presentate alcune soluzioni ideali per l’aumento della sicurezza di sistemi critici tramite diversity. 102 5.1 Simulazione del modello La simulazione del modello presentato nel capitolo 4, è stata effettuata su un arco di tempo pari a 12 mesi e Consente di analizzare la probabilità di compromissione di un sistema mission critical, ed evidenziare i tempi impiegati dal malware per raggiungere l’obiettivo. Nel modello il sistema viene compromesso nel momento in cui il plc non è più sotto il controllo dell’utente ma, tramite la sovrascrittura del programma originale, inizia ad inviare dati errati agli attuatori ed informazioni errate alle HMI. Figura 5.1.1: Probabilità di compromissione di un sistema mission critical sotto attacco Stuxnet-like Come si può vedere dal grafico in figura 5.1.1 la probabilità massima di compromissione di un sistema raggiunge il valore di 0.6, in quanto viene calcolata come: E [PSuccessf ulAttack, PU nsuccessf ulAttack ] ovvero la media tra la probabilità di successo e inuccesso di un attacco su migliaia di ripetizioni. Come è possibile vedere dalla tabella la probabilità di compromissione raggiunge il suo massimo valore dopo 3/4 mesi e si mantiene costante per tutto il resto del tempo. Essendo un malware molto aggressivo, è possibile osservare la forte variazioni di probabilità nei primi due mesi (0 - 0.218 - 0.438). In tabella sono riportati i valori ottenuti Mese Probabilità 1 0.218 2 0.438 3 0.51 4 0.554 5 0.554 6 0.5548 7 0.555 8 0.557 9 0.557 10 0.5575 11 0.558 12 0.558 Tabella 5.1: Probabilità di attacco in 12 mesi L’andamento della curva è dovuto al fatto che il virus, impiegando del tempo per diffondersi all’interno della Control Network, avrà scarsa probabilità di raggiungere una engineering station nei primi giorni di infezione, in quanto sarà presente solo su pochi PC. In un mese,invece, riesce a raggiungere almeno il 60% delle macchine presenti nella CN e ad aumentare di molto la probabilità di infezione di una ES. 5.2 Sensitivity Analysis Per sensitivity analysis(o analisi di sensitività) si intende lo studio delle variazioni di un valore, al variare di uno o più parametri che lo determinano. In questo caso i parametri rappresentano i valori di probabilità di successo di una singola activity del modello. Per il suo svolgimento si è preferito far assumere ad ogni parametro tre valori di probabilità distinti: Sigla Probabilità L 0.25 M 0.5 H 0.8 Tabella 5.2: Valori di probabilità per la sensitivity analysis Le attività scelte per effettuare l’analisi sono cinque e racchiudono le attività fondamentali del virus e di un PC: 1. Escalation Privilege 2. Restore PC 3. Firewall&Router Permission collegato all’attività di aggiornamento del virus tramite C&C Server ed RPC Server 4. OpenFileProject,InfectUsb 5. Server Attack (DatabaseVuln nelle ES) In totale sono stati generati 243 esperimenti partendo da valori bassi di probabilità, fino ad arrivare a valori elevati. In tabella si riportano i risultati ottenuti: I valori di interesse in questi esperimenti sono essenzialmente due: 1. probabilità di successo di un attacco 2. tempo impiegato per raggiungere tale valore L’analisi dei tempi impiegati per raggiungere un determinato valore di probabilità, ha consentito di effettuare il calcolo di una variabile D come differenza fra il tempo impiegato dall’esperimento con valore di probabilità massima e l’esperimento corrente: 4 = TEmax TEi Per chiarire meglio il calcolo effettuato basta osservare la figura 5.2.1 Figura 5.2.1: Calcolo del D Per analizzare i risultati della sensitivity analysis è stato utilizzato un tool automatico (JMP) per l’analisi della varianza, a cui sono stati sottoposti i due dati sopra calcolati. In particolare l’ANOVA consente di capire quali siano gli elementi principali che condizionano il comportamento e l’evoluzione del virus all’interno del modello. 5.2.1 ANOVA ANOVA è una tecnica che si basa sull’analisi della varianza relativa a diversi fattori. Infatti misura l’entità della variabilità o dispersione dalla media delle misurazioni. Essa è data dal quadrato della deviazione standard, ovvero la media aritmetica dei quadrati delle distanze dei dati dalla media M : V arianza = s2 = devianza/gradidilibertà Essa è data dalla formula: V arianza = P M )2 (x N L’analisi della varianza (ANOVA) è un insieme di tecniche statistiche facenti parte della statistica inferenziale che permettono di confrontare due o più gruppi di dati confrontando la variabilità interna a questi gruppi con la variabilità tra i gruppi. L’ipotesi nulla solitamente prevede che i dati di tutti i gruppi abbiano la stessa origine, ovvero la stessa distribuzione stocastica, e che le differenze osservate tra i gruppi siano dovute solo al caso. Si usano queste tecniche quando le variabili esplicative sono di tipo nominale. Nulla impedisce di usare queste tecniche anche in presenza di variabili esplicative di tipo ordinale o continuo, ma in tal caso sono meno efficienti delle tecniche alternative (ad esempio: regressione lineare).[wikipedia] L’ipotesi alla base dell’analisi della varianza è che dati n gruppi, sia possibile scomporre la varianza in due componenti: Varianza interna ai gruppi (anche detta Within) e Varianza tra i gruppi (Between). La ragione che spinge a compiere tale distinzione è la convinzione, da parte del ricercatore, che determinati fenomeni trovino spiegazione in caratteristiche proprie del gruppo di appartenenza. Se si vuole stabilire se vi è differenza di variabilità fra due popolazioni da ciascuna delle quali si è estratto un campione: - si calcola la varianza di ciascun campione - quindi si confrontano le varianze rispettive, calcolando il rapporto tra la maggiore e la minore delle due. Le due varianze sono significativamente diverse, se tale rapporto (detto F) supera i limiti indicati nella tabella specifica Il valore di F è sempre, per definizione, maggiore di 1. 5.2.1.1 Applicazione di ANOVA al modello I testi effettuati sul modello prendono in considerazione due casi particolari: 1. test per l’uguaglianza tra medie di due popolazioni (distribuzione normale; varianza nota o sconosciuta, ma uguale/varianza sconosciuta) 2. test per l’uguaglianza tra medie in campioni accoppiati (X1,...,Xn), (Y1,...,Yn) si procede come per un test relativo al valore di una sola media, ma utilizzando la media e la varianza delle differenze campionarie corrispondenti Xi - Yi, i=1,...,n. Si effettua per esempio nei casi in cui i dati campionari sono relativi a condizioni precedenti e successive a un certo trattamento o evento. L’analisi della varianza è stata condotta, infatti, con interazioni del primo del secondo ordine, ovvero studiando le singole attività e le interazioni tra due di esse. L’analisi ha messo in evidenza che i fattori più importanti del modello sono: 1. Escalation Privilege 2. Server Attack 3. OpeProject & InfectUsb La variazione di questi tre elementi condiziona maggiormente la probabilità di successo di un attacco Stuxnet-like. Come è possibile notare dalla Figura 5.2.2, lo screening degli effetti effettuato sui valori di probabilità ricavati dagli esperimenti sul modello, ha permesso di indiviuare le interazioni del primo e del secondo ordine significative. In particolare osserviamo che le interazioni del secondo ordine più importanti sono proprio: • p1*p3 • p1*p5 • p3*p5 Figura 5.2.2: Screening degli effetti sugli esperimenti effettuati sul modello Questo risultato rispecchia pienamente il comportamento del virus , in quanto la fase di Server Attack o di InfectUsb non può avvenire se prima il malware non si è installato sulla macchina ed ha ottenuto i diritti di amministratore. Lo stesso vale per l’interazione tra p3 e p5 in quanto il numero di progetti infetti all’interno del server determina notevolmente la probabilità di infezione di una Engineering Station. 5.3 Analisi ed esperimenti in presenza di diversity Per ralizzare meccanismi di diversity, all’interno del modello sono state modificate di volta in volta le probabilità di un host e di una engineering station, in modo tale da ottere configurazioni differenti in base al numero di elementi “diversi” presenti nell’architettura. In particolare sono state utilizzate tre percentuali differenti per il numero di host ed engineering station. Le percentuali scelte sono fornite nella tabella sottostante: %Host Diversi %ES Diversi 33% 25% 50% 50% 80% 75% Di seguito si riportano i diversi esperimenti: ConfigurationOK 1. Il primo esperimento prevede di fare diversity sulle configurazioni hardware (CPU A 32 bit e 64 bit) e software (O.S. ). In particolare la diversity viene introdotta solo nella Enterprise Network, ovvero sugli host della rete. Gli esperimenti effettuati hanno restituito i seguenti valori di probabilità: 33% 50% 80% 0 0 0 0 1 0,2035 0,19966667 0,174 2 0,38033333 0,368 0,34142857 3 0,45366667 0,4405 0,41 4 0,48883333 0,47783333 0,44642857 5 0,49416667 0,48216667 0,45085714 6 0,49733333 0,48616667 0,45385714 7 0,49816667 0,48716667 0,45457143 8 0,49833333 0,4875 0,45485714 9 0,49833333 0,4875 0,45528571 10 0,49833333 0,4875 0,45528571 11 0,49833333 0,48766667 0,45528571 12 0,49833333 0,48766667 0,45528571 Tabella 5.3: Probabilità di compromissione del sistema in presenza di diversity sulla configurazione negli host che restituisce il seguente grafico Figura 5.3.1: Grafico della tabella 5.3 La variazione di probabilità è minima in quanto nel modello si sta supponendo che ci sia una probabilità di base di inserire il dispositivo infetto direttamente nella ES. Se andassimo ad eliminare questo vincolo avremmo probabilità molto più basse in quanto il virus riuscirebbe ad installarsi solo su poche macchine con poche possibilità di diffusione. 2. Lo stesso esperimento è stato effettuato facendo variare la probabilità di ConfigurationOK all’interno delle Engineering Station ottenendo le seguenti probabilità: 25% 50% 75% 0 0 0 0 1 0,17 0,106 0,06794737 2 0,28 0,1984 0,13336842 3 0,352 0,2393 0,16121053 4 0,38 0,258 0,17394737 5 0,39 0,26075 0,17563158 6 0,39 0,26291667 0,17742105 7 0,392 0,26375 0,17815789 8 0,392 0,26416667 0,17815789 9 0,392 0,26433333 0,17863158 10 0,393 0,26441667 0,17863158 11 0,393 0,2645 0,17868421 12 0,393 0,2645 0,17868421 Tabella 5.4: Probabilità di compromissione del sistema in presenza di diversity sulla configurazione nelle engineering station Possiamo vedere subito che le probabilità di successo di un attacco diminuiscono notevolmente se si effettua diversity all’interno della Control Network, in quanto il virus si installerà correttamente solo sul 25% delle macchine nell’ultimo esperimento. La tabella viene graficata di seguito Figura 5.3.2: Grafico della tabella 5.4 Escalation Privilege 1. Il terzo esperimento prevede l’inserimento di host con bassa probabilità di Escalation Privilege all’interno della Enterprise Network. 33% 50% 80% 0 0 0 0 1 0,19716667 0,19257143 0,17285714 2 0,37133333 0,36128571 0,34242857 3 0,4455 0,43114286 0,41585714 4 0,48016667 0,46571429 0,45028571 5 0,48316667 0,46928571 0,45457143 6 0,4865 0,47242857 0,45942857 7 0,48816667 0,47314286 0,46014286 8 0,48833333 0,474 0,46071429 9 0,48833333 0,47442857 0,46071429 10 0,48833333 0,47442857 0,46071429 11 0,48833333 0,47442857 0,46071429 12 0,48833333 0,47442857 0,46071429 Tabella 5.5: Probabilità di compromissione del sistema in presenza di diversity nella enterprise network Figura 5.3.3: Grafico della tabella 5.5 Anche in questo caso le probabilità sono elevate a causa della probabilità di inserire il dispositivo USB all’interno della Control Network. Eliminando questo vincolo la probabilità scende di 0.2. Possiamo subito vedere come lo stesso esperimento condotto all’interno della Control Network, genera risultati migliori 25% 50% 75% 0 0 0 0 1 0,14925 0,119 0,0828 2 0,286875 0,2308 0,1682 3 0,3395 0,2744 0,201 4 0,3675 0,2935 0,2158 5 0,370125 0,2956 0,2178 6 0,37275 0,2985 0,219 7 0,3735 0,2988 0,2192 8 0,3735 0,2989 0,2192 9 0,37375 0,2994 0,2194 10 0,37375 0,2994 0,2194 11 0,37375 0,2995 0,2194 12 0,37375 0,2995 0,2194 Tabella 5.6: Probabilità di compromissione del sistema con diversity sul sistema operativo all’interno della Control Network Figura 5.3.4: Grafico della tabella 5.6 USBInfection & OpenProject (Host) 1. Il quarto esperimento permette di osservare l’impatto della diversity sul Sistema Operativo e sui software utilizzati negli host della Enterprise Network. In particolare le funzioni analizzate sono: • Infezione di dispositivi USB • Apertura progetti tramite Step7 Le probabilità ottenute sono: 33% 50% 80% 0 0 0 0 1 0,21466667 0,17285714 0,1699 2 0,39716667 0,34242857 0,3055 3 0,469 0,41585714 0,3637 4 0,50333333 0,45028571 0,3912 5 0,50733333 0,45457143 0,3946 6 0,51133333 0,45942857 0,3981 7 0,5125 0,46014286 0,3991 8 0,51266667 0,46071429 0,3995 9 0,51283333 0,46071429 0,3997 10 0,51283333 0,46071429 0,3997 11 0,51283333 0,46071429 0,3997 12 0,51283333 0,46071429 0,3997 Tabella 5.7: Probabilità di compromissione del sistema con diversity sul Sistema Operativo e sui software utilizzati negli host della Enterprise Network La probabilità di infezione in questo caso, diminuisce più rapidamente in quanto il numero di progetti e di disposistivi USB infetti condiziona la probabilità di attacco di una ES. Se scartassimo la possibilità di infettare direttamente una ES, la probabiltà diminuirebbe di molto. Figura 5.3.5: Grafico della figura 5.7 1. Effettuando lo stesso esperimento sulle Engineering Station si hanno valori di probabilità molto più bassi. Questo è dovuto al fatto che l’apertura di un progetto infetto su una Engineering Station comporta l’infezione del PLC e la compromissione del sistema. Di seguito si riportano i valori dell’esperimento: 25% 50% 75% 0 0 0 0 1 0,14311111 0,11763636 0,07664706 2 0,26733333 0,22209091 0,15388235 3 0,31833333 0,26527273 0,18676471 4 0,34311111 0,28790909 0,19935294 5 0,34688889 0,29009091 0,20094118 6 0,34944444 0,29172727 0,20229412 7 0,35066667 0,29218182 0,20258824 8 0,35111111 0,29245455 0,20264706 9 0,35111111 0,29272727 0,20276471 10 0,35111111 0,29272727 0,20276471 11 0,35111111 0,29272727 0,20276471 12 0,35111111 0,29272727 0,20276471 Tabella 5.8: Probabilità di compromissione del sistema con diversity sul Sistema Operativo e sui software utilizzati negli host della Control Network Figura 5.3.6: Grafico della tabella 5.8 Server Attack 1. Il quinto esperimento studia l’effetto della diversity sui collegamenti al server in cui vengono memorizzati i progetti Step7. In particolare si suppone che solo tramite alcune macchine si possa infettare il DB. Di seguito si riportano le probabilità: 33% 50% 80% 0 0 0 0 1 0,17114286 0,1699 0,17 2 0,31785714 0,3055 0,28 3 0,38414286 0,3637 0,352 4 0,40928571 0,3912 0,38 5 0,41242857 0,3946 0,39 6 0,41614286 0,3981 0,39 7 0,41742857 0,3991 0,392 8 0,41771429 0,3995 0,392 9 0,418 0,3997 0,392 10 0,418 0,3997 0,393 11 0,418 0,3997 0,393 12 0,418 0,3997 0,393 Tabella 5.9: Probabilità di compromissione del sistema con diversity sul Server di gestione del DB La seguente tabella viene graficata di seguito Figura 5.3.7: Gragico tabella 5.9 Come è possibile osservare, la probabilità di attacco varia di poco., in quanto Stuxnet è programmato per diffondersi principalmente tramite dispositivi USB. Dopo aver fatto variare singolarmente gli elementi della Enterprise Network e della Control Network, sono stati effettuati esperimenti di diversity facendo variare le probabilità delle activity degli host e delle engineering station contemporaneamente. In particolare la probabilità di compromissione del sistema è stata calcolata con le seguenti configurazioni Escalation Privilege 1. Escalation 33%Host 25 % Es 2. Escalation 33 %Host 50 % Es 3. Escalation 33%Host 80 % Es 4. Escalation 50%Host 25 % Es 5. Escalation 50%Host 50 % Es 6. Escalation 80%Host 50 % Es I risultati ottenuti sono rappresentati tramite il grafico sottostante Figura 5.3.8: Probabilità di successo di un attacco Stuxnet-like su sistemi con diverse configurazioni e O.S. HOST: Configurazione Diversity sull’host RestorePC H=0.8 FirewallPermission L=0.25 InfectOtherUSB L=0.25 ENGINEERING STATION: Configurazione Diversity su una ES RestorePC L=0.25 InfectOtherUsb L=0.25 OpenProject L=0.25 Le configurazioni architetturali di cui sono stati analizzati i risultati sono 1. 33% Host-25% ES 2. 50% Host-25% ES 3. 80% Host-25% ES 4. 33% Host-50% ES 5. 33% Host-75% ES 6. 50% Host-75% ES I risultati ottenuti sono rappresentati tramite il grafico sottostante Figura 5.3.9: Probabilità di successo di un attacco Stuxnet-like su sistemi con configurazioni di diversity su RestorePC,FirewallPermission,InfectOtherUSB Come è possibile osservare dal grafico 5.3.9 la variazione del numero di Host “ripuliti” ogni mesi non influisce molto probabilità di attaco del virus, in quanto la forte aggressività di questo tipo di malware comporta una diffusione repentina all’interno della rete. Se si pensa all’elevato numero di vulnerabilità 0-day sfruttate si può capire che non basta limitare la diffusione tramite USB e ripulire gli Host della Enterprise Network. D’altro canto il dato rilevante si osserva nell’abbattimento notevole della probabilità di successo passando dalla configurazione 33%-50%, alla configurazione 33%-75%. 5.4 Conclusioni Dall’analisi di questi esperimenti è possibile osservare come, molto spesso, gli impianti che utilizzano sistemi mission critical, debbano effettuare investimenti mirati. Infatti, la protezione di PC presenti all’interno della Enterprise Network potrebbe comportare ingenti spese per l’azienda e scarsi risultati con malware Stuxnet-like. I migliori risultati si ottengono quando si investe su PC della Control Network,in cui la possibilità di limitare l’installazione di questo tipo di virus sulle Engineering Station consente,infatti, un abbattimento elevato della probabilità di compromissione del sistema. Sicuramente la soluzione meno costosa è contenuta all’interno del primo esperimento, in cui si fa variare la configurazione hardware di un singolo PC. Introducendo architetture differenti (32 bit, 64 bit) si riesce di a ritardare di molto la compromissione del sistema in quanto il virus riesce a sfruttare alcune vulnerabilità presenti solo su architetture a 32 bit. Questo riesce comunque a garantire la portabilità delle applicazioni e dei file avendo gli stessi sistemi operativi. Allo stesso tempo però l’utilizzo dello stesso Sistema Operativo su tutte le macchine può creare un unico punto di fallimento, in quanto basterebbe adattare il codice ad architetture differenti. Buoni risultati si ottengono anche andando ad effettuare diversity sui Sistemi Operativi, anche dello stesso tipo ma di versione differente (ad esempio Microsoft Windows XP, Windows 2005, Windows 2008), in quanto presentano vulnerabilità differenti. Soprattutto le versioni precendenti non si portano dietro “falle” presenti negli ultimi prodotti (da Windows Vista in poi) che sono altamente utilizzati a causa dei continui aggiornamenti dei software industriali. Lo studio fatto nel [13] consente di osservare con quali OS sia possibile fare diversity e con quali no. Esistono, infatti, Sistemi Operativi differenti, che presentano le stesse ed identiche vulnerabilità. Non basta quindi installare software diversi sulle macchine, ma occorre capire quali siano quelli più adatti. La tabella sottostante può ben chiarire il concetto espresso. Figura 5.4.1: Vulnerabilità in comune tra i diversi OS Ma quanto bisogna investire sulla diversity per avere buoni risultati? La risposta a questa domanda ci viene fornita dagli ultimi due esperimenti, in cui sono stati effettuate delle misurazioni facendo variare la percentuale di macchine “diverse” sia nella Control Network che nella Enterprise Network, ottenendo così diversi livelli di probabilità. L’analisi dei risultati, consente subito di notare che non occorre effettuare diversity su un numero elevato di elementi, ma modificando la configurazione del 50% dei componenti presenti nella Control Network e del 33% presenti nella Enterprise Network è possibile ottenere un abbattimento della probabilità di successo pari a 0.28. Altro dato rilevante è rappresentato dal fatto che per condurre un attacco succesfull sul sistema, il virus impiegherà all’incirca 3 mesi in più rispetto ad una configurazione priva di diversity. Questo potrebbe comportare un notevole riparmio per l’azienda per quanto riguarda operazioni di manutenzione e recovery dei PC. La sicurezza e la protezione di sistemi critici rientrano tra gli argomenti più importanti degli ultimi 5 anni, ma sembra, che solo ultimamente, si ricerchino strade diverse da quelle classiche, che non producono più effetti significativi e risolutivi, soprattutto perché inadatte a fronteggiare malware di ultima generazione. La prospettiva di questo lavoro di tesi, è quello di tracciare un percorso con possibili ulteriori sviluppi, in cui si potrà estendere il modello ad architetture reali e di larga scala, in modo da recuperare maggiori informazioni in grado di specializzare il framework creato per raggiungere così alti livelli di precisione e rendere reale l’utilizzo della diversity. Bibliografia [1] www.newscientist.com. [2] 2011. Developing cyber-physical experimental capabilities for the security analysis of the future smart grid. [3] Anne Remke1 Emmanuele Zambon1 Anna Kolesnichenko1, Pieter-Tjerk de Boer1 and 2 Boudewijn R. Haverkort1. Is quantitative analysis of stuxnet possible? [4] Zbigniew Kalbarczyk Domenico Cotroneo Ravishankar K. Iyer Antonio Pecchia, Aashish Sharma. Identifying compromised users in shared computing infrastructures: a data-driven bayesian network approach. [5] Balzarotti Canali, Lanzi. A quantitative study of accuracy in system call-based malware detection. [6] Catello Di Martino Domenico Cotroneo. Modeling for assessment and validation: Stochastic activity networks. [7] ESET. Stuxnet under microscope. [8] Francesco Flammini. Modelli per l’analisidi sistemi critici. [9] Luis Mendoca Henrique Santos. Botnet: A heuristic-based detection framework. 125 [10] Daniel Hanson Jason V. Miller Bartek Kostanecki Jesse Gough Mario van Velzen Oliver Friedrichs Jensenne Roculan, Sean Hittel. Sqlexp sql server worm analysis. [11] Davide Balzarotti Mariano Graziano, Corrado Leita. Towards network containment in malware analysis systems. [12] McAfee. Global energy cyberattacks: night dragon. [13] Ilir Gashi Nuno Neves Miguel Garcia, Alysson Bessani and Rafael Obelheiro. Os diversity for intrusion tolerance: Myth or reality? 2011. [14] Liam O Murchu Nicolas Falliere and Eric Chien. W32.stuxnet dossier. [15] SETOLA ROBERTO PANZIERI STEFANO, SCARANO ILARIA. Vulnerabilita’ informatica dei sistemi scada connessi alle reti pubbliche. [16] Gauss Technical Paper. http://www.securelist.com/en/blog/208193767/. [17] Anjali Sardana Pragya Jain. A hybrid honeyfarm based technique for defense against worm attack. [18] Michel Cukier Sankalp Singh and William H. Sanders. Probabilistic validation of an intrusion-tolerant replication system. [19] Ludovic Pietre Cambacedes Siwar Kriaa, Marc Bouissou. Modeling the stuxnet attack with bdmp: Towards more formal risk assessments. [20] Symantec. W32.duqu the precursor to the next stuxnet. . [21] Symantec. Have i got newsforyou: Analysis of flamer cec server. . [22] Symantec. http://www.symantec.com/connect/blogs/shamoon-attacks. . [23] Websense. Advanced persistent threats and other advanced attacks:threat analysis and defense strategies for smb, mid-size, and enterprise organizations. [24] Wikipedia. wikipedia.org/wiki/operationaurora. [25] Yong Chen Qingshan Jiang 2010 Yang Fao Ye, Tao Li. Automatic malware categorization using cluster ensemble.