SecurityOpenLab

Come violare una fabbrica automatizzata in poche mosse

Un attacco mirato può bloccare la produzione di una fabbrica. Le cronache sono piene di casi. Basti ricordare l'iniezione di codice maligno che lo scorso anno bloccò gli impianti dell'azienda manifatturiera tedesca Rheinmetall Automotive. Causò danni per 4 milioni di dollari a settimana. E ricordò ai proprietari delle fabbriche che un virus informatico può sabotare la produzione.

La consapevolezza delle minacce è cresciuta. Però c'è ancora il rischio che le aziende vedano questi attacchi come incidenti isolati, e non come il lavoro mirato di un aggressore. Per smantellare questo punto di vista, il ricercatore di Trend Micro Federico Maggi si è messo al lavoro. Si è appoggiato a un laboratorio della School of Management del Politecnico di Milano e ha dimostrato che cosa si potrebbe davvero verificare.

La vittima designata era l'azienda svizzera ABB. Ovviamente non è stata attaccata davvero. È solo stata protagonista di una dimostrazione che può essere d'aiuto ad altre aziende per individuare i propri punti deboli prima vengano sfruttati.
industry 4 0 lab, il sistema analizzato durante la ricercaIndustry 4.0 Lab, il sistema analizzato durante la ricercaI risultati della ricerca sono pubblicati in un interessante documento di 60 pagine intitolato "Attacks on Smart Manufacturing Systems - A Forward-looking Security Analysis". L'aspetto interessante è che i ricercatori non hanno sfruttato solo una vulnerabilità o solo un sistema, perché esistono molteplici modi per iniettare un codice malevolo in una struttura produttiva.

Ad esempio, i ricercatori hanno sabotato una serie di macchinari tramite un attacco alla catena di approvvigionamento. Sono riusciti a distorcere le letture della temperatura all'interno della fabbrica, interrompendo la produzione. I malware necessari sono stati veicolati tramite librerie software con cui interagiscono i macchinari.

L'idea è partita dal fatto che ABB dispone di un ampio ventaglio di applicazioni che gli ingegneri utilizzano per caricare il codice di programmazione dei robot. Questo "app store" era afflitto da una vulnerabilità che gli ha permesso di caricare il proprio codice nello store. Il problema in questo caso era che non era presente alcuna soluzione di sandboxing. È bastato un semplice plugin scaricato su una workstation per leggere ed esfiltrare i file. ABB alla fine ha risolto la vulnerabilità.
gli scenari di attacco che prevediamo alla luce dei nostri risultatiGli scenari di attacco alla luce dei nostri risultati, incluso la compromissione usando un componente industriale dannoso (a sinistra) e una libreria di terze parti "backdoored" (a destra)Quanto accaduto ha permesso di far capire che all'azienda che il personale non era in grado di rilevare gli attacchi. Se fosse stato un attacco reale, i cyber criminali avrebbero potuto prendere il controllo di diverse macchine in più fasi.

Un'altra simulazione riguarda i "digital twin”, in italiano i gemelli digitali. Sono repliche digitalizzate di una macchina o di un processo di fabbrica. Gli ingegneri li usano per testare le prestazioni. Un difetto nel software di gestione di questa funzione permetteva a un attaccante di manipolare il codice. E di indurre i macchinari veri a creare prodotti difettosi. Qui il problema era di grande portata, perché non esiste una procedura standardizzata per applicare controlli di integrità ai digital twin.

Conclusioni

Nelle conclusioni, Maggi e i suoi colleghi hanno tratteggiato uno scenario preoccupante. Spesso i sistemi di produzione sono progettati e implementati partendo dal presupposto che saranno isolati sia dal mondo esterno che dal resto della rete aziendale. Anche ammesso che questo sia vero, è imperativo tenere conto del fatto che un cyber criminale potrebbe usare strade non convenzionali per attaccarli. Per esempio, l'app store interno e ufficiale dell'azienda.

Oltre tutto, l'assunto del mondo chiuso implica automaticamente che gli aggressori che agiscono in loco avranno carta bianca. Proprio per via dell'isolamento, non ci sono controlli di sicurezza. Qualsiasi endpoint si fida di qualsiasi altro endpoint, e un cyber criminale può fare praticamente tutto ciò che vuole.
attacchiDettagli sugli attacchi inclusi nella case history e raccomandazioni sulle difese 
Come indicava Nate Warfield qualche settimana fa, un sistema di produzione intelligente vulnerabile e di alto profilo può apparire su motori di ricerca come Shodan. È quindi passibile di attacchi. Anche perché oggi i sistemi di produzione intelligenti, sebbene fatti di hardware, sono inseriti all'interno di un ecosistema con una complessa rete di interdipendenze. L'hardware è solo una piccola parte dell'equazione. Esistono software, librerie, sviluppatori, software utilizzato per sviluppare altri software. Librerie vendute da un'azienda utilizzata da un'altra azienda, integratori di sistema che lavorano per diverse fabbriche.

Tutto questo ha ripercussioni sui tipi di attacchi possibili nei sistemi di produzione intelligenti. Una volta che un utente malintenzionato è entrato in un sistema di produzione intelligente, ha opportunità uniche di muoversi lateralmente, alcune delle quali sono inesplorate.

Quello che i ricercatori hanno riscontrato sono problemi di progettazione critici nella logica di automazione dei robot. Non solo creano terreno per le vulnerabilità per le quali non esistono ancora scanner automatici. Consentono anche l'implementazione di azioni dannose che passeranno inosservate.

Alla luce di quanto visto, gli esperti reputano che gli aggressori esterni cercheranno di infettare indirettamente gli endpoint mediante malware mirati. Alcuni software OT possono offrire l'opportunità di colpire non solo una persona specifica, ma categorie più ampie di persone che usano lo stesso software. Ciò vale anche per le librerie software utilizzate per lo sviluppo IIoT (Industrial Internet of Things).
hack in fabbrica, opportunità di attaccoLe opportunità di attacco rilevateUtilizzando tali vettori di attacco, un cyber criminale può ottenere persistenza utilizzando, ad esempio, una logica di automazione compromessa. Altro elemento è che i programmi scritti in ambienti di sviluppo industriale, non impongono l'uso di componenti sicuri (ad esempio il sandboxing). Allo stesso modo, il firmware IIoT sottintende dipendenze complesse, e molte librerie "non ufficiali" finiscono per monitorare o influenzare il comportamento delle macchine.

Dato che tutti i componenti di un impianto di produzione intelligente sono generalmente collegati alla stessa rete, tutto può succedere. Le conseguenze sono difficili da stimare. Per cambiare questo approccio che non funziona è necessario che le persone che lavorano in ambienti OT smettano di considerare la sicurezza come un "componente aggiuntivo". È a tutti gli effetti un processo e così dev'essere gestito.

Se questo articolo ti è piaciuto e vuoi rimanere sempre informato con le notizie di SecurityOpenLab.it iscriviti alla nostra Newsletter gratuita.

Redazione SecurityOpenLab - 13/05/2020

Tag: cyber crime ics trend micro


Top trend

CoronaVirus
Ransomware
Phishing
Malware
Botnet
Vulnerabilità
Data Breach
IoT
Cyberwarfare



End of content

No more pages to load

Iscriviti alla nostra newsletter

Mantieniti aggiornato sul mondo della sicurezza

iscriviti

Redazione | Pubblicità | Contattaci | Copyright

SecurityOpenLab

SecurityOpenLab e' un canale di BitCity,
testata giornalistica registrata presso il tribunale di Como,
n. 21/2007 del 11/10/2007 - Iscrizione ROC n. 15698

G11 MEDIA S.R.L.
Sede Legale Via Nuova Valassina, 4 22046 Merone (CO) - P.IVA/C.F.03062910132
Registro imprese di Como n. 03062910132 - REA n. 293834 Capitale Sociale Euro 30.000 i.v.

Cookie | Privacy

statistiche contatore