cyber security, OT/IoT

Se il target sono i Sistemi Industriali e le Infrastrutture Critiche

Con Operation Technology (OT) ci riferiamo alle infrastrutture tecnologiche (hardwaere e software) che consentono il funzionamento di un sistema “fisico”, tipicamente in ambito industriale o di automazione e gestione di sistemi elettro-attuali. Il tema spazia dal sistema di controllo e gestione delle pompe di un acquedotto alla linea di produzione industriale completamente robotizzata. I sistemi coinvolti oggi dialogano con protocolli molto specifici (es: SCADA) e di fatto sono costituiti da Endpoint di una rete TCP/IP, tipicamente dei computer — in diverse forme — su cui vengono installate le componenti client dei software, da dei sistemi server e da una rete di sensori/rivelatori/attuatori/???ori utilizzata dai sistemi di controllo per leggere dati (telemetrie, rilevazioni, immagini, ecc.) ed eseguire azioni nel mondo fisico. Oggi le reti OT dialogano con le reti IT e spesso il confine tra questi due mondi non è ben definito in quanto l’evoluzione tecnologica li ha portati a condividere tecnologie e risorse a vari livelli.

Non è quindi una sorpresa che gli attacker prendano di mira i sistemi OT tanto quanto i sistemi IT, anzi, di fatto non vi è discriminante per attaccare l’uno o l’altro in quanto vi sono eguali opportunità di mettere in scacco una realtà produttiva (nel caso migliore) o un’infrastruttura critica (nel caso peggiore). Gli impatti sono evidenti: nel caso della realtà produttiva un fermo della produzione ha un impatto diretto sul ciclo di Business (si perdono soldi), nel caso di un’infrastruttura critica (trasporti, sistemi logistici, sistemi di comunicazione, distrubizione elettrica, ecc) vi è un impatto diretto sulla vita dei cittadini, sulle persone (in alcuni contesti si rischia di perdere vite).

Ovviamente queste evidenze massimizzano il modello di Business del criminale informatico. Quanto è disposta a pagare un’azienda per vedere sbloccati i sistemi di produzione messi fuori uso da un attacco informatico? Quanto è disposto a pagare un Ente/Governo per vedere ripristinato il traffico ferroviario nazionale manomesso da un attacker? Purtroppo il problema è reale. Purtroppo è ancora preso troppo alla leggera e l’epilogo tocca leggerlo sulle prime pagine dei giornali quando qualcosa — che si poteva evitare — va storto.

Mettiamoci il cappello bianco

La nota positiva, parlando con aziende strutturate del panorama industriale italiano, è che gli addetti ai lavori se ne sono resi conto e non da poco. La nota negativa è che il management fa ancora fatica a mettere a fuoco il tema. In questa differenza di vedute i criminali informatici prosperano.

Qualificare un’azienda come potenziale target è relativamente semplice, basta fare delle verifiche sul fatturato negli ultimi anni ed analizzare qualche dato sulla reputazione del brand per farsi un’idea. Se l’azienda piace e sta bene economicamente probabilmente ha tanto da perdere e quindi l’attacker ha tanto da guadagnare. Ragionamenti tanto banali quanto reali che si mescolano ad un tema che avevo trattato in passato legato alla “reputazione”.

Che la produzione non si debba fermare non è un’ipotesi, è una certezza. Ci sono aziende che basano il proprio modello di Business proprio sulla velocità della produzione, ovvero competono sul tempo che impiegano a trasformare l’ordine, che spesso arriva dall’e-commerce, in prodotto da consegnare. Perdere un ordine significa perdere soldi se non addirittura il cliente.

Questi sono esempi di modelli di Business che reppresentano reali opportunità per il cyber-crime, sono modelli che richiedono spesso una forte esposizione per funzionare e dove l’automazione del processo produttivo è moltissima e trasversale.

La progettazione di un attacco, in questi contesti, non è molto differente dal puro contesto IT ma lo scenario propone delle differenze: abbiamo a che fare con una rete non sempre segmentata, che interconnette sistemi spesso non aggiornabili (ambienti legacy) dove non è consentito l’utilizzo di appositi strumenti di protezione, il tutto interconnesso in qualche modo a parte dei sistemi IT e dove l’utilizzatore potrebbe non sapere nulla di informatica.

La superficie aggredibile è vastissima, ma è opinione — errata — comune che non vi siano particolari strumenti attaccabili in un rete OT. La realtà è che ogni sistema automatizzato funziona grazie ad un computer (di varie tipologie) con a bordo un sistema operativo e applicazioni anche molto datate, perfettamente funzionanti ma spesso molto vulnerabili. Esistono tecniche e vottori d’attacco studiati appositamente per il mondo OT: con il Red Team di VERSIVO abbiamo avuto modo di sperimentare alcuni vettori d’attacco specifici che mescolano tecniche di code injection e DNS tunneling, tecniche relativamente semplici da intercettare e bloccare ma che in un contesto di automazione industriale rischiano di attecchire con estrema facilità.

Piccola parentesi tecnica. Un attacco particolarmente interessante prevede la manomissione dei file di progetto dei sistemi industriali, formati proprietari che contengono le informazioni su come la macchina dovrà comportarsi per la lavorazione di un “pezzo” o di un “prodotto”. Questi file di base contengono istruzioni e alcuni formati consentono l’injection di codice arbitrario (es: javascript) o a livello scripting interpretabile poi dal software che utilizza il file in oggetto.

La tecnica è molto simile a quella utilizzata con file PDF (JS Injection) o sui file del pacchetto Office (Macro Injection) ma riportata in un contesto dove non si utilizzano né PDF né file di Word. Inoltre i formati utilizzati nel mondo OT raramente sono “compresi” dai sistemi di sendboxing, risulta quindi molto difficile verificare la presenza di codice malevolo.

Rischio elevato / Impatto elevato

Su questo fronte non possiamo non considerare l’impatto che avrebbe un Security Incident: perdere un dato è un conto, perdere il controllo di un sistema industriale o di un’infrastruttura critica è un altro paio di maniche. Non voglio fare paragoni sull’importanza a livello Business, mi riferisco all’impatto diretto e potenzialmente devastante che potrebbe avere un attacco sferrato contro un target critico. Penso il tema sia meritevo di considerazione a tutti i livelli.

cyber security

Sistemi non vulnerabili e tecniche di “elusione”.

Discutendo con il mitico Fabio di 802.1x e MITM, ed in particolare del fatto che esistono protocolli/tecnologie che al momento non presentano bug specifici, risultando così non attaccabili dirittemente, mi è venuto in mente che nello sviluppo di un attacco informatico questo scenario si presenta abbastanza spesso e nel tempo si sono sviluppate tecniche specifiche per “aggirare” l’ostacolo.

Chi si occupa di progettare e realizzare infrastrutture informatiche cerca di utilizzare soluzioni ovviamente sicure, resilienti, con funzionalità evolute anche in relazione alla sicurezza informatica. Il tal senso il livello di sicurezza di una certa soluzione, presa a se, è identificabile dalle funzionalità specifiche che offre e dalla presenza o meno di vulnerabilità note censibili nel tempo e, si spera, prontamente corrette.

Si tende quindi a credere che la somma di strumenti e soluzioni sicure generi, automaticamente, sistemi sicuri. Ma il processo che porta ad un incremento della sicurezza non può passare solo dall’avere prodotti validi, è sicuramente un passo necessario ma non è la soluzione definitiva. Non a caso aziende ed enti, con fior di tecnologie implementate, subiscono attacchi anche con impatti elevati sul proprio business.

Mettiamoci il “cappello nero” e cerchiamo di affrontare la questione in un contesto reale di progettazione di un attacco. Per praticità uso casi di studio reali e scenari anche molto diffusi, alcuni dei quali sperimentati personalmente con VERSIVO ed in passate attività di Ethical Hacking (sono certo che chi fa questo mestiere da tempo potrebbe raccontarne molte).

Capita spesso — fortunatamente — di operare in contesti dove i sistemi sono stati dotati di dispositivi di sicurezza: servizi di analisi e monitoraggio del traffico, sistemi di detection, sistemi di autenticazione, fino ad arrivare a SIEM, SOC, ecc… Tutto molto bello.

Prima di iniziare a “martellare” sui sistemi (lo so, lo ripeto sempre, ma non è mai abbastanza) di solito si eseguono una serie di ricognizioni atte a comprendere il perimetro attaccabile (che è sempre più ampio di quello che si crede) e raccogliere informazioni sul target.

A tal proposito: è inutile chiedere assessment o penetration testing su specifici perimetri. Non esiste un attacker che, individuato un target, si scaglia solo su un fronte da noi selezionato, meglio se quello appena aggiornato e protetto… non sono così fessi.

La raccolta di informazioni, assieme alle successive fasi, consente di creare un modello rappresentativo del target anche molto dettagliato: ovviamente l’individuazione di sistemi di sicurezza fa parte del gioco e spesso, per stanarli, vengono eseguiti volutamente attacchi inutili al mero scopo di verificare come i sistemi rispondono.

Capito il perimetro, fatto di sistemi/persone/device/procedure/ecc, e ipotizzate le aree ben presidiate da sistemi di sicurezza efficienti, di solito molte ma mai tutte, si inizia a lavorare sulle aree scoperte o su quei sistemi di sicurezza che consentono tecniche “evasive”. Non è scritto da nessuna parte che si debba attaccare frontalmente il proprio bersaglio, è molto più logico sfruttare i punti deboli o, nei casi più complessi, errori di design nell’implementazione di un sistema di sicurezza.

Due esempi reali e chiarificatori. In relazione al tema dei “punti deboli”, devo prendere atto della tendenze — errata — a non dare la stessa importanza ai diversi device che si connettono alla rete. Tornando al caso che discutevo con Fabio: è verissimo che EAP-TLS al momento non presenta vulnerabilità apprezzabili che si possano sfruttare, ma è anche vero che le aziende si trovano a dover utilizzare sistemi che non supportano protocolli sicuri: stampanti, SmartTV, mi è capitato di trovare una PlayStation4. Per non parlare del tema SmartPhone: ottimo avere i NAC più potenti dell’universo, ma se poi gli utenti possono usare la rete WiFi aziendale con il proprio SmartPhone, che immancabilmente non gestiamo, abbiamo un bel problema.

L’introduzione di una tecnologia deve essere supportata da una corretta contestualizzazione a livello di DESIGN e PROCEDURE al fine di gestire le immancabili eccezioni.

Altro scenario abbastanza frequente è relativo all’utilizzo quanto meno curioso che si fa di alcune tipologie di sistemi di protezione evoluta come i Web Application Firewall (WAF) o vari servizi/sistemi anti DDoS. Si tratta di oggeti meravigliosi che per ragioni ignote usiamo malissimo lasciando la porta aperta a tecniche di “evasion”. Senza scomodare le tecniche più astute e anche più complesse da realizzare (quindi costose in termini di effort per l’attacker) spesso si sfruttano banali errori di design: ho perso il conto che WAF configurati per controllore il traffico di “www.sito-target.test” e non quello di “demo.sito-target.test” dove entrambi i nomi dominio puntano allo stesso sistema. Se posso bypassare il WAF non me lo faccio dire due volte.

E anche oggi non parlo di Social Engineering … ma ci arriviamo.