Impatto della diversity sulla protezione di infrastrutture critiche: un

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.