SCADA (In)Security: un'analisi approfondita sulla superficie di attacco del noto sistema di controllo industriale

Il termine SCADA, acronimo di Supervisory Control And Data Acquisition, si riferisce a un sistema informatico, in genere un’architettura distribuita con gestione centralizzata, utilizzato per il monitoraggio e il controllo elettronico dei sistemi industriali.

Un sistema SCADA è un software che consente all’operatore di interfacciarsi con i processi tramite sistemi di controllo. Più in generale, qualsiasi applicazione che riceve dati dal funzionamento di un sistema di controllo per controllarla e ottimizzarla è un’applicazione SCADA. L’applicazione può riguardare un processo di distillazione petrolchimica, un sistema di filtrazione dell’acqua, un compressore del condotto o qualsiasi altro elemento.

I sistemi SCADA hanno due obiettivi principali:

monitoraggio del sistema fisico, è possibile controllare e gestire a distanza le varie macchine e tutti i processi in esecuzione;
acquisizione dei dati, utile per verificare il corretto funzionamento del sistema e per identificare più facilmente guasti o possibili problemi.

L’interconnessione dei sistemi SCADA è, da un lato, una grande opportunità e un vantaggio per molte applicazioni industriali, consentendo una maggiore accessibilità; dall’altra, espone le debolezze e le vulnerabilità dei sistemi a un rischio molto più elevato. Per questo motivo è necessaria un’analisi globale della sicurezza dell’intero sistema, verificando ogni interconnessione o componente e identificando le rispettive vulnerabilità e l’impatto relativo che queste possono avere sui processi di produzione.

I rischi di un attacco ai sistemi industriali sono concreti e reali: si tratta di obiettivi molto sensibili data l’importanza dei processi che governano e dell’impatto che un disservizio può causare sulla comunità.

Con l’attacco malware noto come “Stuxnet”, i problemi di sicurezza di SCADA sono diventati di primaria importanza. È diventato evidente che gli attaccanti erano disposti ad accedere ai sistemi SCADA / PLC per danneggiare l’impianto industriale. Data la difficile natura dell’attuazione di controlli robusti in ambienti industriali, varie autorità nazionali come NIST e CPNI hanno prodotto standard e guide di sicurezza per i sistemi in tempo reale. Con l’abbondanza di apparecchiature ICS / SCADA scarsamente protette, poiché non prevedevano alcun controllo di sicurezza, gli organismi nazionali e internazionali hanno compiuto uno sforzo significativo per definire gli standard per la sicurezza dell’infrastruttura CNI.

Esempi di standard sviluppati sono:

Guide di sicurezza CPNI del Regno Unito;
USA NIST 800-82;
ISA 99;
IEC62443.

La sfida principale è proteggere le apparecchiature legacy esposte alla rete per evitare possibili intrusioni all’interno del sistema. Tuttavia, l’uso di queste norme pone solo le basi per la sicurezza e potrebbe non essere sufficiente. Al fine di comprendere meglio le vulnerabilità dei sistemi SCADA e su quali attacchi erano basati, lo studio è proseguito con l’analisi dello stato dell’arte dei malware ICS / SCADA.

ICS/SCADA Malware

L’esposizione dei sistemi SCADA a Internet ha introdotto molti rischi per la sicurezza. Ciò è particolarmente vero perché i protocolli di sicurezza e autenticazione in SCADA sono stati ritenuti non necessari fino agli anni ’90. Queste implementazioni legacy erano basate sull’oscurità/anonimato di protocolli specializzati con interfacce proprietarie e isolamento fisico del sistema. Collegando il sistema alla rete, la proprietà dell’oscurità degli strumenti utilizzati nell’ambiente è venuta meno. Gli attacchi ai sistemi ICS / SCADA sono diventati molto sofisticati nel corso degli anni – vedi Stuxnet – mentre allo stesso tempo sono stati abbassati il livello di abilità e il tempo necessario per lanciare un attacco. Altri problemi, come l’aumento della complessità e l’interdipendenza delle infrastrutture critiche, comprendono i rischi derivanti dalla perdita del servizio (ad esempio elettricità, traffico o controllo dei processi), danni alle proprietà, all’ambiente e potenzialmente alla vita umana. Tra i malware più noti ed emergenti che colpiscono i sistemi ICS / SCADA ci sono:

Malware	CVE
Stuxnet	CVE-2010-2729 CVE-2010-2568 CVE-2008-4250
Triton	N/A
Industroyer	CVE-2015-5374
Havex (RAT)	CVE-2014-1761 CVE-2013-5671 CVE-2013-1756
IronGate	N/A
BlackEnergy	CVE-2014-4114 CVE-2014-0751

Security design

Gli ambienti SCADA sono nati come sistemi isolati e quindi gli hacker potrebbero difficilmente accedere al sistema. Collegandosi ad altre reti, il sistema è esposto a tutte le possibili minacce relative alla rete. Tutto ciò ha introdotto nuove vulnerabilità nei sistemi SCADA. Inoltre, il problema dell’utilizzo di standard aperti per i protocolli di comunicazione interna ha sollevato ulteriori vulnerabilità da affrontare. Il motivo principale per cui sono stati utilizzati gli standard aperti è principalmente legato al costo: ma questi sono aperti, sono accessibili a tutti e quindi un possibile utente malintenzionato che studia i protocolli può identificare le possibili lacune da sfruttare per un attacco. Queste scelte hanno inevitabilmente influito sulla sicurezza del sistema. Tutto ciò ha consentito agli aggressori un maggiore accesso alle informazioni nei sistemi SCADA. La robustezza dei sistemi SCADA / ICS di fronte a un attacco cibernetico diretto è molto inefficiente perché, come precedentemente affermato, non erano destinati a essere connessi a reti esterne. I sistemi dovrebbero essere progettati in modo tale che ci siano controlli di sicurezza come:

firewall,
Data-diode,
IDS e IPS,
sistemi di gestione delle identità e degli accessi.

Lo stato attuale di sicurezza dei sistemi SCADA / ICS è considerato molto basso. Gli approcci di codifica sicuri sono rari e molti sistemi sono così fragili da non poter resistere alle scansioni di sicurezza.

Esistono account amministrativi con backdoor e, in alcuni casi, credenziali di autenticazione con “hardcoded” che, se note, garantiscono l’accesso a potenziali aggressori. Il “flicker” di base di SCADA / ICS può causare arresti anomali e problemi relativi all’overflow del buffer. In alcuni casi non ci sono sistemi di sicurezza basati sul “timeout della password” e tutto ciò espone il sistema ai tentativi di accesso basati sulla “forza bruta”. Attraverso l’uso di framework come Metasploit e Nessus, gli hacker sono in grado di ottenere informazioni di sistema e accedervi in tempo reale.

Gli attacchi informatici su SCADA / ICS sono rari ma in aumento. La tentazione iniziale delle aziende era di respingere il problema; tuttavia, una presentazione di “Blackhat” nel 2013 ha mostrato che se un honeypot è presente sulla rete simulando un sistema in tempo reale, le parti che erano connesse potevano cambiare le impostazioni nei livelli creando un potenziale pericolo. Questo era solo un honeypot virtuale, non un vero sistema SCADA, ma il risultato di attaccanti esterni che si collegavano ai sistemi reali cambiando le impostazioni poteva avere serie implicazioni. Se possibile, dovrebbero essere usati prodotti robusti SCADA / ICS, con sistemi di sicurezza elevati. È essenziale separare il sistema dalle reti ad alto rischio – come Internet – e non consentire l’accesso diretto agli indirizzi IP SCADA/ICS.

ICS/SCADA Vulnerabilities Taxonomy

Come citato in nota[1], i sistemi SCADA presentano diverse vulnerabilità di sicurezza:

vulnerabilità hardware: I componenti SCADA (master SCADA, RTU, IED) presentano vulnerabilità che possono essere sfruttate dagli attacker. Ad esempio, le RTU hanno una bassa capacità di elaborazione e poca memoria, quindi possono essere soggette ad attacchi legati all’overflow del buffer;
vulnerabilità del software: le vulnerabilità più comuni riguardano l’interruzione, l’intercettazione del traffico di dati e la modifica. Il software potrebbe essere rimosso da un utente malintenzionato per causare un errore potenzialmente grave. Altre vulnerabilità sono legate al sistema operativo e alla sicurezza basata su firewall. Il problema si verifica perché molti nodi su sistemi SCADA eseguono sistemi operativi in tempo reale (RTOS). Questi sistemi sono più suscettibili agli attacchi DoS (Denial of Service) perché le piccole disfunzioni della messaggistica possono portare a una significativa perdita di disponibilità delle informazioni. Inoltre, ci sono problemi legati alla mancanza di meccanismi di autenticazione nei vecchi protocolli utilizzati in questi sistemi (Modbus o, ad esempio, InterControl Center Communications Protocol [ICCP]). I protocolli più semplici sono spesso preferiti su meccanismi più complessi per migliorare l’affidabilità, la manutenibilità e le prestazioni, ma questo potrebbe esporre il sistema a possibili aggressori;
vulnerabilità legate ai collegamenti di comunicazione: i sistemi di comunicazione possono essere utilizzati come mezzi di connessione al mondo esterno, poiché non sono presenti funzionalità di sicurezza;
vulnerabilità in merito all’autorizzazione: l’accesso non autorizzato alle apparecchiature può impedire l’accesso legittimo alle richieste degli utenti o di altre risorse, causando problemi nel sistema in quanto potrebbero non essere disponibili o funzionare in modo Con l’accesso non autorizzato è inoltre possibile modificare le logiche di controllo e/o caricare un codice di controllo per distruggere o danneggiare il sistema.

Le misure di controllo della sicurezza includono: tecniche crittografiche, parole chiave, firewall, sistemi di rilevamento delle intrusioni, VPN, antivirus, controllo degli accessi, ecc. Altre misure sono state proposte per i sistemi SCADA, tra cui utilizzare gli standard IEEE / ISO e NIST Guidelines e, in secondo luogo, migliorare i protocolli SCADA inserendo crittografia e decrittografia per la comunicazione a ogni estremità, senza apportare modifiche ai protocolli che utilizzano crittografia e sistemi di sicurezza esterni (SSL / TLS, IPSec) o che cambiano fondamentalmente i protocolli.

Una sfida significativa, tuttavia, riguarda la decisione su quale di queste misure sia la più appropriata e che consideri rischi, impatto e costi. Tuttavia, queste tecniche non affrontano la quantificazione della probabilità di successo (e impatto) di questi diversi insiemi di minacce alla sicurezza. Da questi limiti nasce la necessità di sviluppare approcci di modellizzazione del rischio e della minaccia. Un modello di minaccia / rischio può aiutare a valutare la probabilità, il danno potenziale, la priorità degli attacchi e quindi contribuire a minimizzare o sradicare le minacce. Tutto ciò è necessario per formalizzare il rischio percepito.

Risk and Impact Analysis

Per effettuare un’analisi di rischio e impatto, la tabella 1 è stata definita con tutti i possibili attacchi, attualmente noti, su un sistema SCADA / ICS. Le informazioni mostrate sono:

Attacks	Description	Probabili ty	Impact
Malware (Virus, Trojan, Worms ecc.)	Programmi software progettati per eseguire azioni indesiderate e non autorizzate su un sistema senza il consenso dell’utente, con conseguenti danni, corruzione o furto di informazioni. Il suo impatto può essere grave e si è osservato che il malware può essere comune o personalizzato. Questo tipo di attacchi, in particolare i worm, riguardano un’ampia gamma di risorse, dai sistemi SCADA ai sistemi standard.	Very high	High
Exploit Kits and rootkits	Un exploit è un codice appositamente predisposto per sfruttare una vulnerabilità al fine di ottenere l’accesso a un sistema. È una delle minacce più importanti alle reti ICS / SCADA, in quanto può essere utilizzata anche da malintenzionati poco esperti e sono difficili da rilevare.	Medium	High
Advanced Persistent Threats (APTs)	Attacchi progettati per un obiettivo specifico che si verificano per un lungo periodo di tempo e di solito vengono effettuati in più fasi. L’obiettivo principale è rimanere nascosti e ottenere quante più informazioni, dati sensibili o controlli per raggiungere l’obiettivo dell’attacco. Mentre la probabilità di questo attacco è bassa, è importante tener conto della difficoltà di individuarli, che di solito richiede molto tempo. Sono progettati per molti scenari, come il furto di informazioni riservate o proprietarie o l’interruzione delle operazioni.	Low	High
Insider Threat (Internal employee incidents)	Un dipendente, un appaltatore o una terza parte che ha accesso a sistemi interni limitati si avvale di questo vantaggio per rubare, modificare o accedere senza autorizzazione a questi sistemi o ad altri che possono essere accessibili attraverso di essi.	Low	Crucial
Eavesdropping, (MitM, SCADA communication hijacking)	Intercettazione in tempo reale non autorizzata di una comunicazione privata, ad esempio una telefonata, una sessione di messaggistica istantanea, videoconferenze o comunicazioni e-mail. In questo ambiente, può anche includere l’intercettazione di comunicazioni SCADA, ad es. comandi di controllo e anche la loro modifica per scopi non autorizzati.	Low	High/Crucial
Communication Systems network outage	Un’interruzione o un guasto nella fornitura di rete, intenzionale o accidentale. A seconda del segmento di rete interessato e del tempo necessario per ripristinare le comunicazioni, l’importanza di questa minaccia può variare da alta a critica.	Low	High/Crucial
(Distributed) Denial of Service	Questo attacco consiste in più sistemi che “attaccano” un singolo bersaglio per saturarlo e farlo schiantare. Questo può essere fatto semplicemente cercando di fare troppe connessioni, inondando un canale di comunicazione o ripetendo ripetutamente le stesse comunicazioni. È di grande importanza se i dispositivi SCADA sono interessati da questo attacco e possono causare la cessazione delle operazioni.	Low	Medium/High
Data/Sensitive information leakage	I dati sensibili vengono rivelati, intenzionalmente o meno, a soggetti non autorizzati. L’importanza di questa minaccia può variare notevolmente a seconda del tipo di dati trapelati: • Medio: dati operativi standard, procedure interne. • Alto: dati aziendali, dati utente privati o proprietà industriale.	Low	Medium/High

tipo di attacco,
descrizione dell’attacco,
probabilità di accadimento,
impatto sul

Caratterizzazione di vulnerabilità delle componenti di un sistema SCADA

Componenti coinvolti

Partendo dalle basi di attacco e dall’analisi del malware descritto è stato possibile identificare una serie di componenti per i quali è necessario fornire un robusto sistema di sicurezza. Questi componenti includono:

Unità terminale remota (RTU);
Controllore logico programmabile (PLC);
Master Terminal Unit (MTU);
Sistema operativo (SO);
Server I / O (IOS);
Database server (DBS);
Comunicazione (C).

Ognuno di questi componenti può essere colpito da una serie di minacce che, se riuscite, possono portare il sistema a non funzionare. Tra le principali minacce[1] che possono influenzare i componenti identificati, vi sono:

accesso non autorizzato (UA);
malware (MW);
denial of service (DoS);
vulnerabilità del sistema operativo (OSV);
autenticazione (A);
vulnerabilità del software (SV);
attacchi umani (HA);
vulnerabilità hardware (HV);
vulnerabilità nelle comunicazioni (CV).

Impact Matrix	UA	MW	DoS	OSV	A	SV	HA	HV	CV	No Threats
RTU	0	0	0.2	0.14	0	0.01	10−3	0.02	0.02	0.349
PLC	0	0	0.2	0.14	0	0.01	10−3	0.02	0.2	0.349
OS	0	0.01	0.2	0.1	10−3	0.2	0	0	0	0.669
MTU	0.3	0.3	0.2	0.1	10−3	0.2	0	0.02	0.02	0.399
IOS	0.3	0.02	0.2	0.02	10−3	0.2	0	0.02	0.02	0.399
DBS	0.3	0.02	0.2	0.02	10−3	0.2	0	0.02	0.02	0.399
C	0	0.01	0.2	0.01	0	0.01	0	0	0.5	0.450
No Failure	0.1	0.64	0.86	0.07	0.996	0.17	0.999	0.9	0.04	1

Tabella 2: Impact Matrix per sistemi SCADA

All’interno di ciascuna cella viene stimata la probabilità che il componente venga compromesso, data la possibile minaccia. Ovviamente queste probabilità possono variare in base alla metodologia di attacco e alle strategie e tattiche dell’attaccante.

Analisi e identificazione degli exploits

Per identificare ulteriori possibili componenti e minacce, è stata condotta un’analisi degli exploit noti sui sistemi SCADA, il tutto con l’aiuto di “Metasploit”. Questa è una struttura che consente lo sviluppo di exploit il cui scopo è quello di prendere il controllo totale della macchina remota e oltre. È uno strumento creato per testare la sicurezza di un sistema, questi infatti offrono strumenti anti-rilevamento ed evitamento. Non avendo un obiettivo specifico, la ricerca di exploit è rivolta principalmente ai software e ai componenti più diffusi utilizzati all’interno di un sistema SCADA. Pertanto, sono state condotte ricerche volte a identificare questi exploit. Dalla ricerca sono stati identificati circa sessanta exploit e trentuno software/componenti SCADA, tra cui:

mySCADA – myPro Zscada
Rockwell Scada system GE Proficy Cimplicity
KingScada Certec EDV
7-Technologies IGSS IniNet SpiderControl
Advantech webaccess ClearScada
AzoTech DaqFactory Soitec SmartEnergy
CADA 3S CoDeSys Novus Electronics WS10
DataC RealWin ABB MicroScada SYS600
Procyon Iconics Genesis32
ScadaTec & ScadaPhone Siemens FactoryLink
CitecScada Sunway Force control
Winlog ITS SCADA
Modbus Intellicom Netbiter webSCADA
BroadWin TwinCat
KingView OPC Client
Moxa Device manager
Zscada
GE Proficy Cimplicity
Certec EDV
IniNet SpiderControl
ClearScada
Soitec SmartEnergy
Novus Electronics WS10
ABB MicroScada SYS600
Iconics Genesis32
Siemens FactoryLink
Sunway Force control
ITS SCADA
Intellicom Netbiter webSCADA
TwinCat
OPC Client.

Per ciascuno dei componenti software/hardware “Metasploit” ha fornito molteplici exploit, che forniscono informazioni su:

versione software;
vulnerabilità sfruttabile;
fonte dell’analisi approfondita (percorso).

Utilizzando il percorso consigliato da Metasploit, che in genere ci ha indirizzato a database noti come ExploitDB, è stato possibile estrapolare ulteriori informazioni, tra cui:

tipo di attacco, locale o remoto,
conseguenza dell’attacco, impatto
CVE, se esistente,
presenza del codice sorgente,
verifica della fattibilità,
sistema operativo coinvolto,
data in cui era nota la vulnerabilità,
collegamenti di riferimento.

Esistono standard di settore, come il NIST, in cui è definito un punteggio di vulnerabilità. NIST ha un database CVE (Common Vulnerability Enumeration) che ci ha fornito un elemento aggiuntivo per classificare l’attacco. Ogni CVE è associato a un sistema di punteggio di vulnerabilità comune (CVSS) che definisce il livello di rischio di tale vulnerabilità. Il CVE identifica effettivamente una vulnerabilità. Ogni CVE ha uno o più enumerazioni di piattaforma comune (CPE) ad esso associate, che identificano univocamente un prodotto software. Parliamo invece di CWE (Common Weakness Enumeration) usato per descrivere le classi di vulnerabilità. Ogni CVE può appartenere a più CWE.

L’analisi, a questo punto, ha mirato ad approfondire il livello di dettaglio partendo dal CVE e risalendo al CVSS corrispondente, ove presente. Da questi, ulteriori informazioni sull’attacco potrebbero essere ottenute sul sistema, tra cui:

autenticazione, se richiesta o meno;
complessità dell’attacco;
punteggio di impatto (da 0 a 10);
punteggio di sfruttabilità (che definisce quante fonti dobbiamo supportare l’attacco).

Ulteriori informazioni relative alle metriche CVSS, ovvero: punteggio base, metriche ambientali e temporali. A questo punto è stato possibile classificare gli altri componenti interessati e le vulnerabilità tipicamente sfruttate, oltre a quelle identificate nel paragrafo 3.1, tutto ciò che è possibile osservare nella seguente tabella:

Affected Components	Exploitable vulnerabilities
Executables (file)	Buffer overflow
Webserver	Path/Directory trasversal
Webapp	Cross-site scripting
HMI	Sql Injection
ActiveX	Port attack
Specific ports (tipicamente protocolli tcp/udp)	Privileage escalation
libraries “.DLL”	Overwrite information

Tabella. Componenti e vulnerabilità SCADA

A questo punto è stato possibile capire, sulla base dell’attacco, quali potrebbero essere le possibili conseguenze a cui un sistema ICS / SCADA potrebbe rispondere, tra cui:

esecuzione di codice arbitrario da parte di un utente malintenzionat;
configurazione del cambio di servizio, generazione di comportamenti indesiderati;
un utente malintenzionato potrebbe accedere alle informazioni in registri, memoria, ecc.;
smettere di funzionare, causando di fatto un Denial of service (DoS);
modifica delle informazioni da parte di un utente.

Per definire il costo di ciascun exploit identificato, è stata definita una funzione di costo per ciascun exploit e una funzione di impatto per gli exploit senza CVE, in modo da poter calcolare la funzione di costo. Ogni elemento interessato, vulnerabilità, impatto e tipo di attacco (remoto o locale) avrà un punteggio basato sulle possibili conseguenze che può generare.
I punteggi proposti sono i seguenti:

Vulnerabilità (Vn)	Score 0-10
Buffer overflow	8
Hard coded credential	10
Cross site scripting	8
Web access	8
sql injection	10
Multi-vulnerability	10
Port attack	8
Privilage escalation	10
Overwrite information	10

Consequences (Cs)	Score 0.1-0.7
Esecuzione di codice arbitrario	0,7
Service change config.	0,7
Denial of service (DoS)	0,7
Overwrite information	0,7
Accesso a info (registri ecc.)	0,7

Elementi colpiti (Ec)	Score 0-10
File (.exe/activeX)	8
WebServer/webapp	8
Gateway Server	8
Sw platform(plc/sensori/rtu)	10
Port udp/tcp	8
Modbus	10
HMI	10

Type (T)	Score
Remote	0.5
Local	0.1

CVE	Score
si	0,5
no	0,2

Essendo un sistema critico, i punteggi assegnati risultano inevitabilmente molto alti. La funzione di impatto (punteggio 0-10) proposta è la seguente:

I = (Vn * Cs) + (Ec * T)

A questo punto è stata definita una funzione di costo per ogni exploit:

((Vn * I) + (Ec * T)) * CVE

La funzione di costo è stata normalizzata e definita con una percentuale.

Infine, nella tabella seguente, verranno mostrate le analisi effettuate in dettaglio e quali sono i componenti software e hardware interessati dalle vulnerabilità e informazioni relative precedentemente descritte.

Component	Version	Date	Type of vulnerability	Local/ Remote
mySCADA – myPRO	7	20/05/2018	Hard-Coded Credentials FTP User&Password	Remote
Rockwell Scada System_MicroLogi x	27.011 e precedenti	16/05/2018	Cross-site scripting (XSS) nel web server	Remote
LAquis Scada	4.1.0.3237	27/09/2017	Path Traversal, consente accesso a file	Remote
KingScada	Precedenti alla 3.1.2.13	14/09/2017	Stack-based buffer overflow	Remote
Zscada Modbus	2.0	13/09/2017	Buffer overflow	Remote
GE Proficy CIMPLICITY	8.2	07/07/2016	SERVICE_CHANG E_CONFIG Privilege Escalation	Local
Certec EDV	2.5.9	09/05/2016	Path issue – Fornisce privilegi ad utente non autorizzato	Local
SpiderControl	2.02.0000	08/12/2015	Elevazione di privilegi	Remote
ClearSCADA	2010 R1.0, 2009, 2007, 2005. SCX 67 R4.5 e 68 R3.9	28/01/2015	Remote Authentication Bypass	Remote
Soitec SmartEnergy	1.4 e 1.3	15/12/2014	SQL Injection	Remote
WS10	1.83	24/09/2014	Overflow (PoC)	Remote
KingScada	precedente a 3.1.2	11/02/2014	Consente di caricare una “.dll” malevola tramite url specifico	Remote
ABB MicroSCADA	4.1, 4.2, 8.4.5 e da9.0 a 9.3	03/12/2013	Remote Code Execution	Remote
IGSS	9.00.00.11 059 e precedenti	22/10/2013	Remote command injection. Directory traversal in “dc.exe”	Remote
Advantech Webaccess	7.1 2013.05.3 0 e precedenti	08/01/2013	Cross-Site Scripting	Remote
7-Technologies IGSS	9.00.00.11 063 e precedenti	09/06/2011	Multiple stack-based buffer overflows in “IGSSdataServer.ex e”	Remote
7-Technologies IGSS	10 e precedenti	30/05/2011	Stack-based buffer overflow in Schneider Electric igss. Esegue codice arbitrario inviando sulla porta TCP – 12397	Remote
7-Technologies IGSS	9.00.00 b11063	16/05/2011	Multiple stack-based buffer overflows in “IGSSdataServer.ex e”	Remote
7-Technologies IGSS	9.00.00.11 059	22/03/2011	Multiple Vulnerabilities	Remote
DaqFactory	5.85 build 1853 e precedenti	18/09/2011	Stack-based buffer overflow	Remote
DaqFactory	5.85 build 1842	24/06/2011	Dos	Remote
CADA 3S CoDeSys	2.3.9.27 e precedenti	02/02/2013	Directory traversal su “Gateway- Server”	Remote
CoDeSys SCADA	3.4 SP4 Patch 2 e precedenti	13/12/2011	Stack-based buffer overflow sulla componente “CmpWebServer”	Remote
CoDeSys	3.4 SP4 Patch 2	30/11/2011	Null Pointer Invalid HTTP Request Parsing Remote Denial of Service	Remote
Iconics GENESIS32	9.21.201.0 1	17/07/2011	Integer Overflow	Remote
mySCADAPro	7	29/07/2016	Local Privilege Escalation	Local
Measuresoft ScadaPro	4.0.0 e precedenti	16/09/2011	Multiple stack-based buffer overflows in “service.exe”	Remote
DATAC RealWin SCADA Server	2.1 Build 6.0.10.10 e precedenti	22/06/2011	Stack buffer overflow	Remote
DATAC RealWin SCADA Server	2.1 e precedenti	20/06/2011	Stack-based buffer overflow	Remote
DATAC RealWin SCADA Server	2.0 (Build 6.1.8.10)	30/11/2010	Multiple stack-based buffer overflows	Remote
Procyon Core Server	1.13 e precedenti	12/09/2011	Stack-based buffer overflow & Dos	Remote
ScadaTEC ModbusTagServer & ScadaPhone	4.1.1.81 e precedenti	12/09/2011	Buffer overflow	Local
ScadaPhone	5.3.11.123 0 e precedenti	13/09/2011	Stack-Buffer overflow	Local
CitectSCADA/Cite ctFacilities ODBC	5, 6 e 7	14/11/2010	Stack-based buffer overflow	Remote
CitectSCADA ODBC Server	5.1.2600. 6, 7	05/09/2008	Stack-based buffer overflow	Remote
Sielco Sistemi Winlog	2.07.16 e precedenti	13/09/2017	Remote Buffer Overflow	Remote
Winlog Lite SCADA	2.06.17	29/08/2012	SEH overwrite	Remote
Sielco Sistemi Winlog	2.07.16	27/06/2012	Vulnerabilità multiple	Remote
Sielco Sistemi Winlog	2.07.18	08/06/2012	Remote Buffer Overflow, application presente	Remote
Sielco Sistemi Winlog	2.07.00 e precedenti	21/06/2011	Stack based Buffer Overflow	Remote
Siemens FactoryLink	8	25/06/2011	Buffer Overflow	Remote
FactoryLink	7.5, 7.5 SP2, 8.0.1.703	21/06/2011	Stack buffer overflow	Remote
Siemens tecnomatix factorylink	8.0.1.1473 e precedenti	22/03/2011	Vulnerabilità multiple	Remote
Modbus/TCP OPC Server	3	25/01/2011	Heap-based buffer overflow. Remote Heap Corruption (PoC)	Remote
Advantech Studio	7.0 Build Number 0501.1111	04/12/2012	Path traversal in “NTWebServer.exe”	Remote
	.0402.000 0		, SCADA/HMI Directory Traversal
Winlog Lite SCADA HMI system	2.06.17	29/08/2012	Overwrite (SEH)	Remote
CoDeSys SCADA	3.4 SP4 Patch 2 e precedenti	13/12/2011	Stack-based buffer overflow	Remote
BroadWin	7.0 e precedenti	31/10/2011	WebAccess consente di causare da remoto un DoS	Remote
Measuresoft ScadaPro	4.0.0 e precedenti	16/09/2011	Multiple stack-based buffer overflows in “service.exe”	Remote
ScadaTEC ScadaPhone	5.3.11.123 0 e precedenti	13/09/2011	Buffer overflow	Local
Sunway Force Control	6.1	26/08/2011	Remote Overflow in “httpsrv.exe”	Remote
Advantech/BroadW in SCADA	7.0	23/03/2011	esecuzione di codice arbibrario sulla porta TCP – 4592 in “webvrpcs.exe”	Remote
KingView	6.53 e 6.52	07/03/2011	Stack-based buffer overflow	Remote
KingView	6.53	09/01/2011	Heap-based buffer overflow	Remote
ITS SCADA	Non presente	04/10/2010	SQL-injection	Remote
Intellicom Netbiter webSCADA Products	WS100, WS200, altre versioni potrebbero essere colpite	01/10/2010	Vulnerabilità multiple tra cui: directory-traversal, information- disclosure e arbitrary-file-upload	Remote

SCADA Enumeration

Shodan è un motore di ricerca che identifica all’interno della rete i dispositivi che lo compongono e che attraverso di esso sono collegati tra loro. I risultati restituiti da questo motore di ricerca sono relativi a server, computer, router, stampanti di rete, webcam e persino semafori, centrali elettriche, impianti di condizionamento industriale e turbine eoliche. Shodan è in grado di analizzare e passare attraverso tutti i nodi che compongono Internet e che consentono di interagire anche a migliaia di chilometri di distanza. Ogni mese il motore di ricerca “scheda” circa 500 milioni di nuovi dispositivi, creando un enorme database di computer, server, router e webcam collegati a Internet.

La registrazione su Shodan ti consentirà di utilizzare filtri specifici, tra cui:

città: cerca i dispositivi in una città specifica;
Paese: cerca i dispositivi nel paese indicato;
geo: consente di passare le coordinate geografiche;
hostname: cerca gli host che corrispondono alla stringa di testo specificata;
net: esegue una ricerca basata su IP o CIDR;
os: ricerca basata sul sistema operativo;
porto: cercare una porta aperta;
prima / dopo: cerca i risultati in una particolare finestra temporale;
prodotto: per cercare un prodotto specifico.

È possibile utilizzare l’API per effettuare ricerche basate su:

CVE;
Vuln: vulnerabilità specifiche;
metodo di ricerca;
ricerca su richiesta di scansione;
avvisi di rete.

L’analisi condotta attraverso l’uso di Shodan è stata fatta sulla base delle seguenti domande:

Query: https://www.shodan.io/search?query=NomeSW/Numero versione – CVE;
Vuln: CVE-NumeroCVE;
Server Scada;
Protocolli e porte di comunicazione, principalmente porta modbus: 502;
Usa il codice https:
“200 ok” fornirà tutti quei sistemi il cui accesso non richiede autenticazione,
“401” viceversa fornirà sistemi a cui è possibile accedere solo tramite autenticazione.

Nella figura qui sotto è possibile osservare una dashboard a cui potremmo accedere ed eseguire qualsiasi azione dannosa praticamente senza costi e sforzi.

Tra i problemi più importanti segnaliamo che esistono diversi sistemi a cui è possibile accedere senza autenticazione e che eseguono un controllo remoto del sistema, ad esempio: gestione delle valvole, disattivazione degli allarmi, ecc. A tale proposito, si consiglia di tali sistemi richiedere l’autenticazione o meno remoto per prendere le necessarie precauzioni per evitare che un possibile aggressore possa causare danni al sistema. Tra i server e i servizi più utilizzati vogliamo segnalare:

CirCarLife Scada;
Servizio BAS Scada;
VTScada;
SCADA ISC;
Web scada;
Soluzioni software HMI / Scada;
Cloud Scada;
Server OPC InView.

Inoltre, utilizzando l’immagine Shodan e inserendo la seguente query:

screenshot.label: “ics / SCADA”,

è possibile osservare un’intera serie di HMI a cui è possibile accedere, ad esempio tramite strumenti come vcn viewer, che sarà sufficiente per fornire l’indirizzo e la porta di utilizzo (che sono spesso chiari) in modo da accedere al sistema e fare una qualsiasi azione malevola per compromettere il sistema. È possibile osservarne un esempio nella figura qui sotto:

In effetti, molti di questi sistemi risultano avere l’autenticazione disabilitata e quindi, inserendola nel sistema IP e nel numero di porta, è possibile accedervi e manipolarla, oltre a spiare l’utente che la sta usando. Quindi dall’analisi di Shodan è chiaro che l’accesso a un sistema ICS / SCADA generico non richiede quasi nessuno sforzo e quasi nessun costo da parte di un aggressore, ma può creare enormi danni al sistema. A tale riguardo, i vari amministratori di sistema SCADA sono invitati a effettuare i controlli necessari relativi all’autenticazione e a fornire adeguati sistemi di sicurezza.

A questo punto dell’analisi sono state definite le reali tassonomie di attacco che possono influenzare un sistema SCADA e le ulteriori contromisure da utilizzare.

Attack Taxonomy

Le minacce e le vulnerabilità elencate potrebbero essere utilizzate dagli attacker per causare diversi livelli di danno con relativi effetti a cascata nelle infrastrutture. Nella tabella sono stati definiti i principali scenari di attacco, ognuno dei quali con il relativo impatto. L’impatto varierà tra “Basso”, “Medio”, “Alto” e “Cruciale”.

Attack scenarios	Impact
Contro I sistemi di amministrazione	Crucial
Contro gli attuatori	High/Crucial
Contro il collegamento di rete tra sensori/attuatori e HMI	High
Contro i sensori	Medium/Crucial
Contro le informazioni che transitano sulla rete	Medium/Crucial
Compromissione di componenti ICT	Medium/High
Vulnerabilità dei protocolli, exploit	High/Crucial
Contro lo storico dei dati di controllo	Medium

Standard for the security of SCADA systems

Esistono molti standard applicabili a diversi settori industriali con una parte di essi che affronta già, almeno parzialmente, gli aspetti della sicurezza IT che dovrebbero essere affrontati nei sistemi e nelle reti ICS / SCADA.

Inoltre, i governi stanno anche iniziando a definire regolamenti obbligatori, come il Regolamento europeo sulla protezione dei dati (GDPR), per “forzare” le organizzazioni a raggiungere, almeno, un livello base di sicurezza delle informazioni sui loro sistemi, promuovendo in alcuni casi il uso di questi standard.

Tra gli standard più noti e consigliati da seguire vi sono i seguenti:

AGA 12 Parte 1 (Protezione crittografica delle comunicazioni SCADA): il suo obiettivo principale ruota intorno a una proposta di progettazione di sistema completa per ottimizzare i sistemi Ciò consente di ridurre i requisiti per l’esecuzione dei processi di manutenzione e gestione;
IEC 61968/61970 (Common Information Model [CIM] – Distribution / Energy management): definisce un “Common Information Model” che può essere utilizzato per le interazioni tra applicazione e applicazione tra i sistemi nel centro;
IEC 62351 (Sicurezza nei sistemi di gestione dell’energia): fornisce raccomandazioni di sicurezza per molti protocolli alcuni dei quali sono principalmente utilizzati nel settore energetico (include IEC 60870-5, DNP3, IEC 60870-5-101 e IEC 60870-5-104);
IEEE P1711 (Standard per un protocollo crittografico per la sicurezza informatica dei collegamenti seriali delle sottostazioni): definisce un protocollo crittografico che fornisce integrità e riservatezza opzionali, per la sicurezza informatica dei collegamenti;
ANSI / ISA 99 (Sicurezza dei sistemi di automazione e controllo industriale): definisce una linea guida per la sicurezza dei sistemi di automazione industriale e di Lo sviluppo di questo standard è stato interrotto quando è stato avviato ISA IEC 62443, che si rivela essere la sua evoluzione, il cui intento è quello di espanderlo e completarlo;
NIST SP 800-82 (Guida ai sistemi di controllo industriale): definisce la topologia tipica dei sistemi SCADA, identificando le minacce e le vulnerabilità del sistema fornendo raccomandazioni e contromisure per mitigare i rischi;
ISO 27000 (sistemi di gestione della sicurezza delle informazioni): uno standard per scopi generali che fornisce buone pratiche e raccomandazioni per la gestione della sicurezza delle informazioni e viene normalmente utilizzato per l’implementazione o la “gestione dei sistemi di gestione della sicurezza delle informazioni” (ISMS).

Note

[1] Sulla base delle minacce e dei componenti identificati finora, una matrice di impatto è stata definita da Chen, Qian, Abercrombie e Sheldon, Risk assessment for industrial control systems quantifying availability using mean failure cost (MFC), Journal of Artificial Intelligence and Soft Computing Research 5.3 (2015), 205-220.

Articolo a cura di Antonio Pirozzi e Corrado Aaron Visaggio

Profilo Autore

Antonio Pirozzi

Antonio Pirozzi si è laureato (cum laude) nel 2014 in Ingegneria Informatica presso l'Università del Sannio indagando euristiche per delineare il genoma e la filogenesi dei malware. Attualmente è studente di dottorato presso la stessa Università, portando avanti studi sui modelli di Deep Learning applicati ai problemi di classificazione dei malware. È Professore a contratto al Master in Cyber Security presso la Link Campus University. Ha co-fondato, nel 2008, il primo gruppo di ricerca universitario sull'analisi dei malware in Italia: il gruppo di ricerca ISWATlab (www.iswatlab.eu) nell'Università del Sannio. È anche esperto di materia per EC-Council e detiene più di 14 certificazioni internazionali. Attualmente è direttore del laboratorio di ricerca Z-LAB Cybaze/ YOROI nonchè head of IT di Cybaze, dove con il suo team ha scoperto vari impianti malware di diversi APT e operazioni state-sponsored. La sua esperienza va ben oltre il classico panorama della Computer Security, ha lavorato su numerosi progetti tra i quali GSM Security, ICS Security, Blockchain Malware, composition malware, inoltre ha pubblicato BOTCHAIN il primo impianto di botnet completamente funzionante basato su Blockchain

Profilo Autore

Corrado Aaron Visaggio

Corrado Aaron Visaggio è nato a Molfetta (BA) nel 1977. E’ professore associato di Sicurezza Informatica al Dipartimento di Ingegneria dell’Università degli Studi del Sannio. Ha conseguito la laurea in Ingegneria Elettronica (2001) presso il Politecnico di Bari e il dottorato (2005) presso l’Università degli Studi del Sannio. E’ docente di master universitari, quali quello di Roma Tor Vergata, Link University e Università degli Studi di Bari. E’ docente della Scuola Internazionale di Alta Formazione per la Prevenzione ed il Contrasto del Crimine Organizzato, del Ministero della Difesa ed è stato istruttore persso il Dipartimento di Sicurezza delle Informazioni del Ministero degli Interni. E’ il direttore del nodo Unisannio per il Laboratorio Nazionale CINI di Cybersecurity. E’ il responsabile scientifico di numerosi progetti di ricerca finanziati in Cybersecurity, che riguardano sicurezza delle reti, malware analysis e protezione dei dati. E’ nell’editorial board di numerose riviste scientifiche e conferenze internazionali di settorie (MALWARE, ISSRE, ARES, SECRYPT, SEKE, ITASec, FORSE, DATA, WETSOM). E’ autore di circa cento articoli scientifici su riviste e atti di convegni internazionali di settore. E’ co-fondatare della Spin-off accademica SER&P. Gli interessi di ricerca sono: malware analysis, data privacy and protection, software security, empirical software engineering.

Profilo Autore

Fabrizio Giorgione

Fabrizio Giorgione è nato a Napoli (NA) nel 1992. Si è laureato in ingegneria informatica presso l’università degli studi del Sannio il 17 dicembre del 2018 con una tesi dal titolo: “Analisi della superficie di un sistema SCADA”. Ha sviluppato, presso il laboratorio ISWATlab, un’applicazione Android denominata “Privacy Guard” la quale valuta il rischio di privacy leakage, ovvero il furto di informazioni, sugli smartphone (http://www.iswatlab.eu/?page_id=499). Ha effettuato il tirocinio presso lo “ZLab” di “Cse Cyber Sec” nell’ambito “SOC”, “Forensic” e “Malware Analysis”. Attualmente lavora presso la società di “NTT DATA” come “Cyber security Analyst” nel SOC di Napoli. Il suo compito è quello di effettuare analisi di log, di malware e di prevenire minacce interne ed esterne alla sua azienda e ai clienti della società. Si è occupato, inoltre, del montaggio e della gestione di sonde IDS/IPS presso Telecom Italia nella sede di Roma (RM).

Condividi sui Social Network: