Il CERT-UA (ucraino) ha parlato del “più sofisticato attacco alla distribuzione di energia” nella conferenza stampa dove ha annunciato che, in collaborazione con Microsoft ed ESET, ha rilevato e rimosso un malware russo, “Industroyer2“, che tentava di eseguire il secondo attacco nella storia per interrompere l’erogazione di energia elettrica in Ucraina.
L’attacco precedente, Industroyer, risaliva al dicembre 2016. Non si sa dove esattamente questo attacco sia stato tentato, nella conferenza stampa si è solo parlato di sottostazioni ad alto voltaggio di un’azienda privata in un’area dove vivono almeno due milioni di persone. L’area si trova nell’est e secondo gli ucraini era parte dell’offensiva che i russi stanno preparando in quella zona del paese. Secondo CERT-UA l’attacco è stato completamente prevenuto, altre fonti parlano di nove sottostazioni che sono state temporaneamente messe fuori linea. Gli attacchi sono stati tentati dopo l’ingresso della Ucraina nella grid elettrica europea.
Russia-Ucraina, verso attacchi cyber più devastanti: ecco perché
Sfruttando sia le informazioni fornite da CERT-UA che l’analisi del malware di ESET, è possibile analizzare l’attacco che è stato attribuito a Sandworm ed è caratterizzato dall’uso coordinato di più malware. Alcuni dei malware hanno come bersaglio gli impianti ICS, altri l’infrastruttura ICT che interfaccia un ICS.
Malware utilizzato: Industroyer2
Il malware progettato per colpire gli ICS è stato chiamato Industroyer2, l’ultimo appartenente alla famiglia Industroyer che è stata progettata per attaccare griglie elettriche e che pare sia stato utilizzato nel dicembre 2016 ed attribuito a giugno 2017. Industroyer o Crash Override è stato definito come la peggior minaccia ad ICS dopo Stuxnet e la sua caratteristica fondamentale è la flessibilità permessa dalla capacità sfruttare quattro protocolli di comunicazione tipici di ICS. I protocolli sono utilizzati in tutto il mondo in infrastrutture critiche per la distribuzione di energia elettrica, acqua e gas e per il controllo dei trasporti. Questi protocolli sono stati sviluppati decenni fa ed erano stati pensati per sistemi isolati e quindi la sicurezza non è mai stato un parametro di progetto. Una volta ottenuto l’accesso ad un ICS a partire dalla infrastruttura ICT collegata, era semplice per Industroyer utilizzare i protocolli per controllare direttamente l’ICS e chiudere un impianto di distribuzione o alimentazione. Oltre al codice per interagire mediante i quattro protocolli, Industroyer conteneva un modulo in grado di implementare un DOS contro relè di protezione, un dispositivo di sicurezza. Vista la sofisticazione del malware e la quantità di risorse necessarie per la sua messa a punto, non ci sono mai stati dubbi che lo sviluppatore agisse per conto di uno stato.
La variante Industroyer2 è implementata come un singolo modulo ed è in grado di interagire con i relè di protezione e di utilizzare solo uno dei quattro protocolli del suo antenato. Il modulo scoperto è stato compilato due settimane prima della scoperta, confermando che l’attacco era stato pianificato a lungo. Questo fatto è stato confermato anche nella conferenza stampa del Ministero dell’Energia, dello Sviluppo Tecnologico e Digitalizzazione dell’Ucraina che ha sottolineato come il ritardo tra l’invasione russa e l’uso del malware sia dovuto alla necessità di ottenere i necessari privilegi di accesso sul sistema da attaccare. Le forti similitudini tra il modulo rilevato e quello del corrispondente modulo di Industroyer, in pratica si tratta di una specializzazione, confermano che è stato prodotto dallo stesso gruppo. Industroyer2 è altamente configurabile con una descrizione codificata nel corpo del modulo che guida le azioni del malware ed è in grado di interagire con otto diversi indirizzi IP. È quindi più rigido del suo precursore, che prelevava la configurazione da un file, e per questa ragione deve essere ricompilato per ogni target. Questo non è ovviamente un problema, vista la bassa frequenza di utilizzo da quando la famiglia è apparsa.
Malware utilizzato: CaddyWiper
L’attacco bloccato da CERT-UA utilizzava anche dei wiper da installare sia su ICS che su sistemi Windows della infrastruttura informatica associata. La ragione dell’uso dei wiper sulla infrastruttura ICT è quella di ostacolare il ripristino del normale funzionamento dell’impianto di distribuzione. L’utilizzo del wiper Caddywiper, anche su ICS permetteva l’ulteriore vantaggio di ostacolare la rilevazione di Industroyer e di cancellare le tracce delle sue azioni. Caddywiper è l’ultimo di una lista di wiper utilizzati contro l’Ucraina e che comprende, ad esempio Isaac, Hermetic e AcidRain. Caddywiper era stato usato in precedenza contro uffici governativi e banche ucraine. Nella infrastruttura ICT del sistema attaccato, Caddywiper è lanciato da un nuovo loader, ARGUEPATCH, ottenuto modificando il debugger remoto di IDA, noto strumento di reverse engineering. ESET sospetta che la scelta di questo strumento come punto di partenza per lo sviluppo del loader sia dovuto ad un particolare senso dell’umorismo di Sandworm. Il codice che carica è criptato ed il loader era programmato per lanciare l’attacco alle 14:58 del 8 aprile sul sistema ICT ed alle 16:20 sulla rete ICS. Sostanzialmente, mentre il personale era focalizzato per gestire il wiper su ICT, il malware lanciava attacco su ICS per sabotare la distribuzione di energia.
Uno script powershell sul server suggerisce che il wiper sia stato installato tramite una GPO di Active Domain
Malware utilizzato: Linux e Solaris
Sulla rete della società energetica attaccato sono stati scoperti ulteriori malware in Bash, chiamati Orcshred, Soloshred e Awfulshred. Orcshred è un worm per sistemi Linux mentre Orcshred e Soloshred sono due wiper per, rispettivamente, sistemi Linux e Solaris. Abbiamo quindi due varianti del wiper, una per ciascuno sistema operativo.
La versione per Linux distrugge l’intero contenuto dei dischi collegati al sistema operando in parallelo sui vari dischi. In base alle dimensioni del disco, ciò può richiedere molte ore visto che i malware utilizzano, come suggerito dai nomi, shred o dd. Per accelerare le operazioni, i servizi ssh e http sul nodo vengono terminati. Inoltre, il wiper distrugge le informazioni di log e per il boot. L’ultima azione del wiper è quella di forzare un riavvio, operazione ovviamente impossibile visto che tutti i dati sono stati cancellati.
Per quanto riguarda la versione Solaris notiamo che è molto raro trovare versioin di malware per questo sistema. Anche questa versione del malware interrompe e disabilita sul nodo attaccato i servizi ssh, http ed anche quelli oracle. Ovviamente, il wiper deve impedire agli operatori di utilizzare l’infrastruttura ICT per riacquisire il controllo su ICS. Per questa ragione, il malware cancella il file system ed i database e, come la versione Linux, i dischi e le informazioni di boot. Il tutto avviene operando in parallelo sui vari dischi. Terminate le operazioni, lo script si cancella.
La prima azione: il worm
La prima azione dell’attaccante dopo l’accesso iniziale è lanciare un worm, uno script bash che attiva il wiper mediante la schedulazione di un task con un’opzione che permette di lanciare il wiper alle 14.58. Questo ritardo permette di non danneggiare il sistema da cui l’attacco inizia. Successivamente, lo script itera sui vari indirizzi IP ottenuti mediante ip route of ifconfig-a ed assumendo che ogni indirizzo appartenga ad una rete di classe C. Con ogni indirizzo IP così generato, il malware cerca di aprire una connessione, un tunnel, mediante SSH su alcune porte. Per ogni porta, il worm utilizza un insieme predefinito di credenziali memorizzate nello script. Gli analisti ipotizzano che queste credenziali siano state raccolte prima dell’attacco e questo può spiegare il tempo necessario per preparare l’attacco stesso. Se la connessione ha successo ed il sistema non è già stato infettato, viene creata una copia del worm con l’opzione che permette di lanciare il wiper alle 14:58 in parallelo alle operazioni di Caddywiper. L’uso di tunnel SSH limita ovviamente la possibilità che un sistema di intrusion detection riveli il flusso illegale tra i nodi.
CERT-UA pensa che l’accesso iniziale al sistema target sia avvenuto prima del 22 febbraio. Successivamente, l’attaccante ha raccolto le informazioni sul sistema target utili per la preparazione del malware e per lanciare il worm. Non è ancora stato comunicato come tale accesso sia avvenuto ma l’azienda è stata bersaglio di una ondata di attacchi successivi in quel periodo. La mancanza di informazioni sul meccanismo di accesso iniziale è comune a molti attacchi di Sandworm. Altra informazione che manca è come gli attaccanti siano passati da sistemi ICT a ICS
Conclusioni
Il malware utilizzato in questo attacco è sofisticato ed innovativo per la sua integrazione di wiper su ICS e su ICT. Ovviamente con una invasione in corso non è necessario essere stealth o preoccuparsi troppo dell’attribuzione. Al limite, si può essere interessati ad aumentare la complessità dell’analisi dei malware utilizzato per poterlo riutilizzare. Questo può spiegare perché l’unico componente non offuscato è il malware per Solaris. Inoltre, il malware è stato specializzato per uno specifico protocollo mentre Industroyer era una vera e propria piattaforma per attacchi ad ICS.
Infine, è naturale correlare la scoperta di questo malware allo smantellamento della botnet Cyclops Blink, l’infrastruttura di attacco di Sandworm, avvenuta pochi giorni fa. Probabilmente, lo smantellamento è stato preceduto, come sempre in questi casi, dal monitoraggio delle comunicazioni dell’infrastruttura per scoprire i prossimi bersagli. Visto che, in generale, conviene continuare il monitoraggio per il maggior tempo possibile, si può ipotizzare che lo smantellamento della botnet sia stato un passo necessario per sconfiggere l’attacco. La mancanza di informazioni sul meccanismo di accesso iniziale conferma questa ipotesi. Infine, citiamo un interessante commento su questa sconfitta di Sandworm che evidenzia come una delle ragioni della mancanza di cyber attacchi con gravi impatti sia la capacità dei difensori di lavorare in modo aggressivo (o meglio proattivo) e non solo reattivo.
Sempre nell’ottica di un atteggiamento proattivo, ricordiamo che Mercoledì 13 aprile, il Dipartimento dell’Energia, la Cybersecurity and Infrastructure Security Agency, la NSA e l’FBI hanno rilasciato un avviso congiunto su Pipedream, un nuovo set di strumenti in grado di manipolare maliziosamente un’ampia gamma di apparecchiature per ICS. Rispetto ai precedenti toolkit per ICS, il malware è stato definito come un coltellino svizzero con una serie di strumenti per interrompere o controllare il funzionamento di un insieme di dispositivi. L’insieme comprende dei PLC Schneider Electric e OMRON che interfacciano una infrastruttura ICT e gli attuatori e sensori tipici di un ICS. Un diverso componente del malware ha come target i server OPC UA (Open Platform Communications Unified Architecture) che interagiscono con ICS.
Secondo chi lo ha esaminato, Pipedream è in grado di attaccare i dispositivi, bloccarli definitivamente ed impedire agli operatori di accedervi. Inoltre, permette di usarli per accedere ad altri dispositivi ICS. Il toolkit sfrutta un modulo a basso livello per cui potrebbe essere in grado di attaccare altri dispositivi oltre a quelli citati. Lo strumento sfrutta alcune vulnerabilità zero day ma può essere in grado di operare anche senza queste vulnerabilità perché in realtà compone in modo nuovo funzionalità già disponibili sui dispositivi stessi. Pipedream può essere interessante anche per il nostro paese visto che pare essere stato studiato per impianti che operano su gas liquefatto.
L’avviso congiunto di mercoledì raccomanda di attuare un insieme di raccomandazioni per elevare il livello di sicurezza delle infrastrutture.
