fbpx
Cyber Deception Technology, nuova frontiera nell’arte della guerra
17 Giugno 2019
Dal Deep Web agli attacchi al Cloud: il lato oscuro della Digital Transformation
20 Giugno 2019

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:

  1. monitoraggio del sistema fisico, è possibile controllare e gestire a distanza le varie macchine e tutti i processi in esecuzione;
  2. 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:

  1. mySCADA – myPro Zscada
  2. Rockwell Scada system GE Proficy Cimplicity
  3. KingScada Certec EDV
  4. 7-Technologies IGSS IniNet SpiderControl
  5. Advantech webaccess ClearScada
  6. AzoTech DaqFactory Soitec SmartEnergy
  7. CADA 3S CoDeSys Novus Electronics WS10
  8. DataC RealWin ABB MicroScada SYS600
  9. Procyon Iconics Genesis32
  10. ScadaTec & ScadaPhone Siemens FactoryLink
  11. CitecScada Sunway Force control
  12. Winlog ITS SCADA
  13. Modbus Intellicom Netbiter webSCADA
  14. BroadWin TwinCat
  15. KingView OPC Client
  16. Moxa Device manager
  17. Zscada
  18. GE Proficy Cimplicity
  19. Certec EDV
  20. IniNet SpiderControl
  21. ClearScada
  22. Soitec SmartEnergy
  23. Novus Electronics WS10
  24. ABB MicroScada SYS600
  25. Iconics Genesis32
  26. Siemens FactoryLink
  27. Sunway Force control
  28. ITS SCADA
  29. Intellicom Netbiter webSCADA
  30. TwinCat
  31. 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:

  1. tipo di attacco, locale o remoto,
  2. conseguenza dell’attacco, impatto
  3. CVE, se esistente,
  4. presenza del codice sorgente,
  5. verifica della fattibilità,
  6. sistema operativo coinvolto,
  7. data in cui era nota la vulnerabilità,
  8. 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

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 Universita', portando avanti studi sui modelli di Deep Leaning applicati ai problemi di classificazione dei malware. È Professore a contratto al Master in Cyber Security presso la LinkCampus 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 e' direttore del laboratorio di ricerca Z-LAB Cybaze/ YOROI nonche’ 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

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.

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).

Download PDF
Condividi sui Social Network:

ISCRIVITI ALLA NEWSLETTER DI ICT SECURITY MAGAZINE

Una volta al mese riceverai gratuitamente la rassegna dei migliori articoli di ICT Security Magazine

Rispettiamo totalmente la tua privacy, non cederemo i tuoi dati a nessuno e, soprattutto, non ti invieremo spam o continue offerte, ma solo email di aggiornamento.
Privacy Policy