Industria 4.0: Trend Micro scopre gravi vulnerabilità nei gateway industriali

Industria 4.0: Trend Micro scopre gravi vulnerabilità nei gateway industriali

Trend Micro ha svelato alcune falle nei traduttori di protocolli che consentirebbero a degli attaccanti di ottenere accessi non autorizzati ai sistemi industriali e di sferrare attacchi critici al settore dell'industria 4.0

di pubblicata il , alle 17:31 nel canale Security
Trend Micro
 

Durante la conferenza Black Hat USA tenutasi in maniera virtuale il 5 agosto, Trend Micro ha svelato alcune vulnerabilità dei gateway industriali (noti anche come traduttori di protocolli). Si tratta di apparecchiature che consentono di integrare macchinari e sensori industriali all'interno di un sistema IT, così da consentire l'acquisizione di dati sul funzionamento delle macchine e garantire un maggiore controllo sui sistemi di produzione. 

Le vulnerabilità identificate da Trend Micro potrebbero portare ad accessi non autorizzati ai sistemi e consentire agli attaccanti di sabotare i processi produttivi

Gateway industriali: cosa sono e perché sono fondamentali per l'industria 4.0

 

Lost in Translation_ When Protocol Translation Goes Wrong

 

Il mondo dell'industria è sempre più informatizzato e oggi praticamente tutti i macchinari industriali sono connessi a un'infrastruttura IT. Questo permette di tenere sotto controllo i parametri di funzionamento di ogni macchina, ottimizzando la produzione e anticipando eventuali guasti grazie a sistemi di manutenzione predittiva che avvisano gli operatori non appena qualche parametro è fuori dalla norma. I macchinari (chiamati OT, Operation Technologies) e i sistemi IT, però, non parlano lo stesso linguaggio e per garantire la comunicazione fra questi due mondi si fa affidamento a dei Protocol Gateway, che fondamentalmente "traducono" le informazioni dei controller industriali, i PLC, in uno standard utilizzabile dai sistemi IT. 

Balduzzi-Industrial-Protocol-Gateways-Under-Analysis

Si tratta di dispositivi di dimensioni compatte che in certi casi possono rappresentare una porta di accesso per un attaccante. A svelarlo è Trend Micro, che ha pubblicato uno studio intitolato Lost in Translation: When Protocol Translation Goes Wrong, liberamente consultabile a questo indirizzo, al quale ha collaborato il Senior Research Scientist Marco Balduzzi, che sottolinea come “Gli attacchi che sfruttano queste problematiche potrebbero permettere di ottenere dati sensibili (ad esempio sulla produzione), sabotare o manipolare importanti processi industriali, attraverso messaggi di attacco che vengono appositamente camuffati in modo da apparire come legittimi, e quindi più difficilmente identificabili dai tradizionali sistemi di detection".

Sfruttando queste vulnerabilità, un attaccante potrebbe essere in grado di spegnere il motore di un macchinario, rallentare una centrifuga industriale, invertire il verso di funzionamento di un nastro trasportatore o modificare i limiti di temperatura dei macchinari. Quest'ultimo scenario, in particolare, può avere un grande impatto in certi ambiti, come la lavorazione delle plastiche o nel settore alimentare: pensiamo ai danni che potrebbe derivare se non venisse garantita la catena del freddo in tutto il processo produttivo e di impacchettamento di beni alimentari. 

Lo studio pubblicato da Trend Micro spiega nel dettaglio come è possibile sfruttare queste vulnerabilità e allo stesso tempo offre una serie di raccomandazioni su come mettere in sicurezza le infrastrutture industriali. In particolare, l'azienda consiglia di : 

  • Considerare con attenzione il design del prodotto e assicurarsi che abbia adeguate funzionalità di sicurezza, in modo che i dispositivi non siano soggetti a errori di traduzione o denial of service
  • Non fare affidamento su un unico punto di controllo per la sicurezza della rete. Combinare firewall ICS con il monitoraggio del traffico
  • Dedicare tempo a configurare e proteggere i gateway, utilizzando credenziali forti, togliendo i servizi non necessari e abilitando la crittografia dove supportata
  • Applicare la gestione della security ai gateway industriali e a tutti gli asset OT critici. Per esempio, svolgere valutazioni sulle errate configurazioni o vulnerabilità e provvedere a un patching regolare
La sicurezza gli impianti industriali è un tema di crescente interesse. Come abbiamo avuto modo di specificare qui, gli attaccanti sono sempre più interessati a compromettere queste infrastrutture, che si rivelano ottimi bersagli sia per chi vuole monetizzare dagli attacchi, sia per gli attori sponsorizzati da nazioni. 
9 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
Qarboz12 Agosto 2020, 21:52 #1
Non di tratta di falle, i gateway devono funzionare in quel modo. Casomai le falle sono nel firewall che fa entrare chi non è autorizzato nella rete aziendale...


Ps
C'è un errore nell'immagine: l'HMI è collegato al PLC e non alla rete aziendale.
deggial13 Agosto 2020, 10:12 #2
Originariamente inviato da: Qarboz
Non di tratta di falle, i gateway devono funzionare in quel modo. Casomai le falle sono nel firewall che fa entrare chi non è autorizzato nella rete aziendale...


Ps
C'è un errore nell'immagine: l'HMI è collegato al PLC e non alla rete aziendale.


1) I gateway devono funzionare in quel modo, ma se tu produci gateway devi avere sempre stampato in testa questo concetto: NON sai chi gestisce il firewall (e se c'è un firewall) quindi è buona cosa che che te lo proteggi da te il tuo dispositivo.

2) credo che sia un discorso più filosofico che tecnico, ma il concetto di Industria 4.0 è rendere "l'accesso alle macchine" fruibile anche al di fuori del mondo PLC... quindi è giusto che l'HMI sia collegato al di là del firewall e non nella stessa rete del PLC.
Quello che intendi tu è che ad oggi (e a ieri, diciamo fino all'Industria 2.0 o 3.0 che non so nemmeno che step siano...) l'accesso al mondo macchine e plc era autorizzato a poche persone, e queste avevano la loro interfaccia nella rete del plc ovviamente. Se servivano informazioni sullo stato di una macchina (ad esempio diagnostica di un componente, usura di un rotore) il tecnico addetto ne dava comunicazione a chi di competenza nel reparto giusto.
Il concetto di Industria 4.0 è (tra le altre cose) che non deve essere più così: l'usura di un componente me la posso controllare anche io a 10.000km di distanza dal sito di funzionamento, tramite webserver accessibile da internet (e si spera molto molto protetto).
giovanni6913 Agosto 2020, 11:37 #3
Originariamente inviato da: deggial
me la posso controllare anche io a 10.000km di distanza dal sito di funzionamento, tramite webserver accessibile da internet (e si spera molto molto protetto).


..e nel frattempo arricchire con la tua esperienza l'altro settore del machine learning che apprenderà il tuo know-how da impartire all'AI per le manutenzioni future.
Qarboz14 Agosto 2020, 12:01 #4
Originariamente inviato da: deggial
1) I gateway devono funzionare in quel modo, ma se tu produci gateway devi avere sempre stampato in testa questo concetto: NON sai chi gestisce il firewall (e se c'è un firewall) quindi è buona cosa che che te lo proteggi da te il tuo dispositivo.

2) credo che sia un discorso più filosofico che tecnico, ma il concetto di Industria 4.0 è rendere "l'accesso alle macchine" fruibile anche al di fuori del mondo PLC... quindi è giusto che l'HMI sia collegato al di là del firewall e non nella stessa rete del PLC.
Quello che intendi tu è che ad oggi (e a ieri, diciamo fino all'Industria 2.0 o 3.0 che non so nemmeno che step siano...) l'accesso al mondo macchine e plc era autorizzato a poche persone, e queste avevano la loro interfaccia nella rete del plc ovviamente. Se servivano informazioni sullo stato di una macchina (ad esempio diagnostica di un componente, usura di un rotore) il tecnico addetto ne dava comunicazione a chi di competenza nel reparto giusto.
Il concetto di Industria 4.0 è (tra le altre cose) che non deve essere più così: l'usura di un componente me la posso controllare anche io a 10.000km di distanza dal sito di funzionamento, tramite webserver accessibile da internet (e si spera molto molto protetto).


1)
No, non produco gateway
Comunque, lo scopo del gateway non è quello di proteggere la rete del PLC ma fa da "traduttore" (sw ed in alcuni casi anche hw) fra il mondo IT e quello PLC, ed anche fra PLC e PLC di diversi modelli/costruttori. Vedilo come fosse un'acces point o uno switch di rete: servono per collegare fra loro diversi apparati, e non credo che chi li costruisce (gli switch) si chiede se nella rete dove verranno utilizzati è presente un firewall...

2)
Il discorso è interessante e molto vasto... Nel precedente post ho fatto quell'affermazione, in effetti un po' troppo categorica, perché in caso di un singolo guasto che può essere il gateway, il firewall, un'apparecchiatura di rete, ecc. (ed in ambito industriale se ne tiene conto dei probabili guasti), la macchina comandata dal PLC potrebbe non essere più utilizzabile. Diciamo che mi sono espresso male e in modo affrettato, forse avrei fatto meglio a scrivere "Manca almeno un HMI nella rete del PLC". Perché l'HMI non serve solo al manutentore per pianificare le riparazioni (ed in questo caso potrebbe essere anche a 10.000 km), ma anche al funzionamento della macchina, questo in qualsiasi "revisione" delle rivoluzioni industriali.
Esempio stupido. Le auto Tesla sono connesse "always on"; in questo modo il "manutentore", che potrebbe essere negli USA, in Svizzera o a Passerano Marmorito, potrebbe monitorare i parametri di funzionamento ed avvisare il proprietario di recarsi in officina in caso di anomalie rilevate (in realtà non so se questo servizio è realmente disponibile alla Tesla), o intervenire da remoto nel caso il problema fosse risolvibile tramite sw. Però il volante ed i pedali (HMI) sono sull'auto e collegati direttamente ai sistemi che comandano, non passano di certo da un firewall
deggial15 Agosto 2020, 09:12 #5
Originariamente inviato da: Qarboz
1)
No, non produco gateway
Comunque, lo scopo del gateway non è quello di proteggere la rete del PLC ma fa da "traduttore" (sw ed in alcuni casi anche hw) fra il mondo IT e quello PLC, ed anche fra PLC e PLC di diversi modelli/costruttori. Vedilo come fosse un'acces point o uno switch di rete: servono per collegare fra loro diversi apparati, e non credo che chi li costruisce (gli switch) si chiede se nella rete dove verranno utilizzati è presente un firewall...

2)
Il discorso è interessante e molto vasto... Nel precedente post ho fatto quell'affermazione, in effetti un po' troppo categorica, perché in caso di un singolo guasto che può essere il gateway, il firewall, un'apparecchiatura di rete, ecc. (ed in ambito industriale se ne tiene conto dei probabili guasti), la macchina comandata dal PLC potrebbe non essere più utilizzabile. Diciamo che mi sono espresso male e in modo affrettato, forse avrei fatto meglio a scrivere "Manca almeno un HMI nella rete del PLC". Perché l'HMI non serve solo al manutentore per pianificare le riparazioni (ed in questo caso potrebbe essere anche a 10.000 km), ma anche al funzionamento della macchina, questo in qualsiasi "revisione" delle rivoluzioni industriali.
Esempio stupido. Le auto Tesla sono connesse "always on"; in questo modo il "manutentore", che potrebbe essere negli USA, in Svizzera o a Passerano Marmorito, potrebbe monitorare i parametri di funzionamento ed avvisare il proprietario di recarsi in officina in caso di anomalie rilevate (in realtà non so se questo servizio è realmente disponibile alla Tesla), o intervenire da remoto nel caso il problema fosse risolvibile tramite sw. Però il volante ed i pedali (HMI) sono sull'auto e collegati direttamente ai sistemi che comandano, non passano di certo da un firewall


Riguardo al punto 2, sì hai ragione. Ora abbiamo una idea condivisa.

Riguardo al punto 1, il mio "tu" era generico, non riferito proprio alla tua persona :-)
Detto questo, IO produco gateway (o meglio, li creo di volta in volta ad hoc per l'applicazione che serve), e non mi sono mai sognato di lasciarne sprotetto qualcuno, proprio perché spesso scopro che ho a che fare con informatici che hanno installato il loro primo firewall l'altro ieri.
Visto che di base di lavora con piattaforme Linux, un minimo di regole iptables ce le metto sempre, oltre a filtrare le chiamate lato software.

Poi vabbè, penso che entrambi sappiamo quello di cui stiamo parlando e abbiamo solo visioni leggermente diverse
Qarboz15 Agosto 2020, 10:46 #6
Originariamente inviato da: deggial
Riguardo al punto 2, sì hai ragione. Ora abbiamo una idea condivisa.

Riguardo al punto 1, il mio "tu" era generico, non riferito proprio alla tua persona :-)
Detto questo, IO produco gateway (o meglio, li creo di volta in volta ad hoc per l'applicazione che serve), e non mi sono mai sognato di lasciarne sprotetto qualcuno, proprio perché spesso scopro che ho a che fare con informatici che hanno installato il loro primo firewall l'altro ieri.
Visto che di base di lavora con piattaforme Linux, un minimo di regole iptables ce le metto sempre, oltre a filtrare le chiamate lato software.

Poi vabbè, penso che entrambi sappiamo quello di cui stiamo parlando e abbiamo solo visioni leggermente diverse


Per il punto 1
Complimenti, perché credo che realizzare quei gateway non sia per nulla banale
A questo punto mi hai stuzzicato la curiosità: se occorre eseguire delle modifiche al sw del PLC, come fai a capire se i comandi arrivano da una "Engineering workstation" fidata? Dall'indirizzo IP? Dal mac adress? Tramite password (ma occorrerebbe che il sw di sviluppo contempli questa possibilità? Altro?
deggial16 Agosto 2020, 11:14 #7
Originariamente inviato da: Qarboz
Per il punto 1
Complimenti, perché credo che realizzare quei gateway non sia per nulla banale
A questo punto mi hai stuzzicato la curiosità: se occorre eseguire delle modifiche al sw del PLC, come fai a capire se i comandi arrivano da una "Engineering workstation" fidata? Dall'indirizzo IP? Dal mac adress? Tramite password (ma occorrerebbe che il sw di sviluppo contempli questa possibilità? Altro?


Allora, considera che dipende dal plc di cui si sta parlando... ma in genere hai una seriale con modbus a cui interfacciarti (almeno nei miei casi).
Quindi il "gateway" è diviso in due:
Interfaccia eth-modbus, basata su linux, con API web.
Ma anzichè dare accesso a questa interfaccia, è lei che tramite client VPN si connette a un server centrale (all'esterno della rete del sito quindi) e tutte le richieste dell'utente finale passano attraverso il server.

Niente porte da aprire in ingresso nel firewall, nessuna necessità di conoscere IP del sito (da parte dell'utente finale). L'unica cosa è che deve conoscere è il server di smistamento centrale.

E quella è la parte più a rischio da parte mia... Però è ben protetto da una password robustissima: BellaPwd123!
Qarboz16 Agosto 2020, 12:33 #8
Originariamente inviato da: deggial
Allora, considera che dipende dal plc di cui si sta parlando... ma in genere hai una seriale con modbus a cui interfacciarti (almeno nei miei casi).
Quindi il "gateway" è diviso in due:
Interfaccia eth-modbus, basata su linux, con API web.
Ma anzichè dare accesso a questa interfaccia, è lei che tramite client VPN si connette a un server centrale (all'esterno della rete del sito quindi) e tutte le richieste dell'utente finale passano attraverso il server.

Niente porte da aprire in ingresso nel firewall, nessuna necessità di conoscere IP del sito (da parte dell'utente finale). L'unica cosa è che deve conoscere è il server di smistamento centrale.

E quella è la parte più a rischio da parte mia... Però è ben protetto da una password robustissima: BellaPwd123!


Grazie per le info, anche se non credo di aver capito bene...
Correggimi se sbaglio
I gateway che programmi accettano input solo da client che si collegano ad un certo sito web che non c'entra nulla con la lan dell'azienda dove è installato il PLC. Se ho capito giusto è uno scenario differente da quello dell'immagine dell'articolo in quanto in quest'ultima i device collegati alla control network si trovano comunque nello stesso sito produttivo, non c'è nessuna VPN rappresentata.
Altro dubbio nei gateway che programmi: chi si collega dalla lan dell'azienda al PLC deve sempre passare dal sito esterno?
deggial16 Agosto 2020, 12:52 #9
Originariamente inviato da: Qarboz
Grazie per le info, anche se non credo di aver capito bene...
Correggimi se sbaglio
I gateway che programmi accettano input solo da client che si collegano ad un certo sito web che non c'entra nulla con la lan dell'azienda dove è installato il PLC. Se ho capito giusto è uno scenario differente da quello dell'immagine dell'articolo in quanto in quest'ultima i device collegati alla control network si trovano comunque nello stesso sito produttivo, non c'è nessuna VPN rappresentata.
Altro dubbio nei gateway che programmi: chi si collega dalla lan dell'azienda al PLC deve sempre passare dal sito esterno?


Non ti posso rispondere in linea generale perchè io non faccio "lavori in serie"... ma ogni cliente ha le sue necessità e bisogna studiare la soluzione per lui. Io comunque ti descrivo la "mia" situazione di mercato; e l'esempio che ho fatto è quello con cui ho più a che fare di solito.

Ti rispondo a questa domanda:
Altro dubbio nei gateway che programmi: chi si collega dalla lan dell'azienda al PLC deve sempre passare dal sito esterno?
RISPOSTA: per come te l'ho descritto io sì, ma naturalmente, se mi trovassi in una situazione del genere, studierei una soluzione leggermente diversa, in cui è aperta una porta tra gateway e rete aziendale tramite firewall. Quello apre poi altri scenari di sicurezza.

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^