# Benvenuti! Ciao e benvenuto!\ Mi chiamo Omar Morando e mi occupo di cyber security in campo IT e OT. In questo blog trovi argomenti inerenti la sicurezza offensiva, soprattutto legata al mondo dell'Automazione Industriale e dell'Automotive. ## Di cosa mi occupo ### Cyber security Ethical hacking, penetration test, analisi delle vulnerabilità e sicurezza della rete. Formazione e diffusione sui temi della protezione della privacy, della sicurezza informatica e della protezione dei dati. 20+ anni di esperienza nel mondo OT, con particolari competenze nell'Automazione Industriale ICS (PLC, I/O remoti, SCADA, fieldbus, reti) secondo lo standard ISA/IEC 62443 e nell'Automotive con ISO/SAE 21434. \- CompTIA Security+, PenTest+\ \- Ec-Council CPENT (pending)\ \- Bug Bounty Hunting\ \- Practical Ethical Hacking\ \- Kaspersky Industrial CyberSecurity Certified Professional\ \- Cyres Automotive CyberSecurity Certified Professional Mi occupo anche dello sviluppo di SCADAsploit, un framework "Metasploit like" realizzato in Python che contempla numerosi moduli ausiliari ed exploit dedicati ai sistemi OT, in particolare PLC e SCADA presenti sul mercato italiano. ScadaSploit è uno strumento molto utile durante l'analisi delle vulnerabilità e il penetration test. ### Coding Sviluppo di software per mobile robots, sistemi embedded, IoT e real-time apps.\ \- Linguaggi: C/C++, Python, C#, Ruby\ \- Embedded systems con RTOS\ \- Framework: Qt/QML, PyQt, ROS ### Contatti | [email](mailto:me@omarmorando.com) | [website](https://omarmorando.com) | [linkedin](https://www.linkedin.com/in/omorando/) | [twitter](https://twitter.com/OmarMorando) | [hackthebox](https://www.hackthebox.eu/profile/182845) | | ---------------------------------- | ---------------------------------- | ------------------------------------------------- | ------------------------------------------ | ------------------------------------------------------ | # OT/ICS Hacking Questa sezione è dedicata alla sicurezza e all'hacking dei sistemi di Automazione Industriale, più propriamente chiamati Operational Technology (OT) o Industrial Control System (ICS). Per chi non ha familiarità con questi sistemi consiglio di iniziare con una sintetica analisi delle differenze tra IT e OT. # Differenze tra IT e OT Per coloro che provengono dal mondo IT la sicurezza informatica dei sistemi ICS può rappresentare un ostacolo inizialmente frustrante. Questo perchè le loro conoscenze sulle tecnologie e sulle modalità di lavoro sono molto diverse nei sistemi OT, a partire dagli obiettivi che questi due settori hanno. ### Protezione dei dati vs. Protezione del processo Quando lavoriamo per proteggere i sistemi IT ci poniamo come obiettivo quello di proteggere i dati. Questi includono la proprietà intellettuale (IP), i numeri di carta di credito, le e-mail e le informazioni di identificazione personale (PII). Stiamo cercando di impedire all'hacker di avere accesso a quello che, per un'azienda, può rappresentare gran parte del proprio patrimonio. Ciò contrasta nettamente con i sistemi ICS in cui il principale obiettivo è **proteggere il processo**. Essi sono concepiti per un'elaborazione continua del ciclo di lavorazione, e non è solo per una questione economica. In alcuni casi, un arresto non previsto di un'impianto può richiedere giorni, settimane o addirittura mesi per il suo riavvio, causando ingenti danni. Basti pensare, ad esempio, a un sistema ICS che controlla la generazione e la distribuzione elettrica o agli impianti di acqua potabile e reflue, la cui interruzione può causare gravi problemi. Oltre al grande disagio si può incorrere in situazioni che mettono in pericolo la salute delle persone, sottolineando la necessità di proteggere il processo. ![](/files/-M7rI53_ylJGrdqeF_k-) ### Tecnologie Nei sistemi IT tradizionali siamo abituati a lavorare con protocolli come TCP, IP, UDP, DNS, DHCP, ecc. La maggior parte dei sistemi ICS utilizza uno degli oltre 100 protocolli dedicati, di cui alcuni proprietari. I più diffusi sul mercato sono Modbus, DNP3, ProfiNet/Profibus, OPC e altri ancora. Un sistema ICS basa il proprio funzionamento operativo sul *Controllore a Logica Programmabile* o PLC. Questi sono utilizzati per quasi ogni tipo di sistema di controllo industriale, sia che si tratti di produzione, raffinazione del petrolio, trasmissione di elettricità, trattamento delle acque, ecc. I PLC sono comparabili a computer industriali, con un loro Sistema Operativo proprietario. Utilizzano linguaggi di programmazione che derivano dal mondo della logica elettromeccanica, come il Ladder Logic, per controllare sensori, attuatori, valvole, allarmi e altri dispositivi. L'hacking dei sistemi ICS richiede spesso una conoscenza della programmazione di questi PLC. ![PLC Schneider Electric serie compatta](/files/-M7rIJYqTSZ-p6Q41xjE) ### Requisiti di disponibilità Sebbene la **disponibilità** (CIA) sia un componente chiave della sicurezza IT tradizionale, i sistemi ICS la portano ad un altro livello. Come accennato in precedenza, stiamo proteggendo il processo, piuttosto che i dati. Ciò significa che spesso l'opzione di applicare una patch software e riavviare il sistema potrebbe NON essere un'opzione se non a intervalli discreti, quali arresti di manutenzione annuali o trimestrali. Ciò può significare che il sistema operativo e le applicazioni possono rimanere privi di patch con vulnerabilità note per mesi, se non addirittura per anni. L'ingegnere dei sistemi SCADA o PLC deve spesso optare per controlli compensativi per prevenire intrusioni, rispetto ad un approccio molto più rapido di un amministratore della sicurezza IT che sarebbe in grado di applicare delle patch a intervalli molto più rapidi. ### Accesso ai componenti Con alcune eccezioni, nel tradizionale campo della sicurezza IT il tecnico della sicurezza ha accesso fisico diretto ai componenti del sistema. Nei sistemi ICS i componenti del sistema possono essere distribuiti su centinaia o migliaia di metri (es. condutture, rete elettrica, ecc.). Ciò può rendere difficile l'implementazione dei controlli di sicurezza. Le stazioni remote in campo possono diventare un punto di accesso per l'hacker all'intero sistema ICS. ### Sicurezza attraverso l'oscurità Negli ultimi tempi, e di recente col concetto di Industria 4.0, molti dei sistemi ICS sono stati progressivamente collegati a Internet tramite una connessione TCP/IP diretta. Sebbene la comunicazione interna possa essere ancora gestita con reti proprietarie, l'accesso remoto consente un monitoraggio continuo da parte dei responsabili degli impianti. Rimangono comunque delle eccezioni, come ad esempio alcune dighe e altri sistemi di infrastrutture pubbliche che rimangono off-line per proteggerli dagli aggressori. ![Sicurezza ottenuta tramite una protezione "air gap"](/files/-M7rJ22Hj91Gf1VqFspV) Per anni questi sistemi hanno beneficiato della **sicurezza attraverso l'oscurità**. In altre parole, erano al sicuro perché poche persone sapevano della loro esistenza e ancora meno capivano le loro tecnologie. I protocolli utilizzati erano noti solo a tecnici del settore, a chi aveva avuto modo di acquisire esperienza diretta lavorando a stretto contatto con SCADA, PLC e terminali HMI. Questo sta diventando il loro punto debole, perchè oggi sono esposti in rete senza che siano state implementate le misure di sicurezza più elementari. Un esempio è ciò che è accaduto nel 2016 ad opera del ricercatore indipendente Karn Ganeshen che è riuscito a entrare in un sistema di [Building Automation di Schneider Electric](https://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2016-025-01) sfruttando una vulnerabilità 0-day e ottenendo un accesso **root** al server. Con l'avvento di strumenti come [Shodan](https://www.shodan.io/) e di altri strumenti di ricognizione questi sistemi non possono più fare affidamento sulla sicurezza attraverso l'oscurità. L'industria sta iniziando solo ora ad attuare misure di sicurezza modeste. Una delle sfide più grandi è che molti prodotti di sicurezza standard IT non garantisco lo stesso livello di protezione con i protocolli industriali. Nella maggior parte dei casi occorre personalizzare i firewall e gli IDS per renderli compatibili ed applicabili all'OT. Di fronte alla minaccia del cyber terrorismo e della guerra cibernetica la protezione dei sistemi ICS è cruciale. A partire dal 2010 sono diventati i primi bersagli presi di mira non solo da hacker criminali ma anche da governi, come nel caso di [Stuxnet](https://it.wikipedia.org/wiki/Stuxnet) o del targeting Russo del sistema elettrico Ucraino durante il loro conflitto. Stay safe, stay free. # La sicurezza industriale ![](/files/-MKt2krbe5hyc3qAMc08) La sicurezza informatica industriale è sempre stata una sfida. Per quanto già complessa in sè, la pandemia che stiamo affrontando nel 2020 complicato ulteriomente le cose. Secondo il recente rapporto dell'ARC Advisory Group, il numero di lavoratori remoti tra le organizzazioni industriali è aumentato del 53%, creando attività aggiuntive per i professionisti IT e OT. Allo stesso tempo, solo circa un quarto delle società industriali ha sviluppato un piano strategico di risposta agli incidenti. ![](/files/-MKt3fM30uYipddY8Y9t) Mentre alcune delle grandi imprese industriali possono avere budget sufficienti e professionisti competenti per affrontare in modo efficacie un progetto di sicurezza OT, altre sperimentano la mancanza di risorse. Secondo lo stesso rapporto, il 24% delle organizzazioni industriali ha riscontrato una riduzione del budget ICS. Il paradosso è che crescono le esigenze di accesso, che richiedono la visibilità da remoto delle aree più critiche delle loro infrastrutture industriali. ![](/files/-MKt2TVXZJQzNg8k_b7P) ## Approccio strutturato alla sicurezza OT Ci sono buone notizie per le aziende, che stanno pensando a come affrontare il loro programma di sicurezza OT. Seguendo i 5 passaggi universali descritti di seguito, qualsiasi organizzazione industriale può riconoscere, strutturare e assegnare priorità alle proprie reali esigenze di sicurezza. Inoltre, può identificare le azioni più richieste con i budget e le risorse disponibili. ![](/files/-MKt3Kx4fUPZaMeXPuCO) ### FASE 1. Conduzione dell'audit di sicurezza Le aziende spesso sottovalutano l'importanza della diagnostica della sicurezza informatica. Tuttavia, questo passaggio è fondamentale per le reti OT sensibili, poiché consente di ottenere visibilità attraverso i processi di sicurezza esistenti. Aiuta anche a identificare i problemi, impostare obiettivi di sicurezza adeguati e pianificare i passaggi successivi con fiducia. Acquisendo la comprensione di quali tecnologie sono realmente necessarie, è possibile spendere saggiamente il budget disponibile. ### FASE 2. Trovare le tecnologie per la sicurezza Con l'elevata diversità degli ambienti OT su più verticali industriali, potrebbe essere difficile trovare una singola tecnologia o un fornitore in grado di soddisfare tutti i requisiti di sicurezza OT del cliente. È più comune trovare una combinazione di tecnologie compatibili scalabili per le esigenze dell'organizzazione industriale. Se non è disponibile una soluzione adeguata sul mercato, l'opzione migliore può essere quella di cercare una tecnologia adatta tra grandi o piccoli fornitori di sicurezza o persino svilupparla da zero. ### FASE 3. Implementare in modo adeguato la sicurezza La continuità dei processi industriali e la sicurezza umana e ambientale sono le massime priorità per le reti OT. Pertanto, le soluzioni di sicurezza OT devono essere attentamente implementate e configurate secondo gli standard di conformità locali e internazionali, che includono ISO/IEC 27001, NIST SP, ISA/IEC 62443, NERC CIP e altri standard di riferimento. ### FASE 4. Gestione professionale della sicurezza La gestione della sicurezza OT può essere complessa, poiché copre più aree e richiede competenze di gestione della sicurezza diverse. Inoltre, l'approccio alla sicurezza informatica delle reti IT e OT è diverso, portando alla carenza di professionisti della sicurezza tra le organizzazioni industriali. Le imprese industriali possono superare questa sfida ricoprendo ruoli di gestione della sicurezza e governando i progetti di sicurezza, internamente o con i servizi SOC in outsourcing. Il monitoraggio costante della sicurezza aiuta a riconoscere i modelli sospetti e rilevare incidenti di sicurezza e attacchi informatici nelle loro fasi iniziali. ### FASE 5. Formazione continua sulla sicurezza La sicurezza informatica è un'area in costante sviluppo, che richiede il contributo di ogni dipendente all'interno di un'organizzazione industriale. La formazione sulla consapevolezza della sicurezza comune viene utilizzata per sviluppare capacità di sicurezza e sane abitudini quotidiane tra i team non IT e i manager di livello C. Allo stesso tempo, la formazione avanzata, che include la sicurezza OT dedicata, la Threat Intelligence e altri corsi avanzati, viene utilizzata per migliorare le competenze dei professionisti IT e della sicurezza OT, responsabili della protezione delle infrastrutture OT contro gli attacchi informatici. Stay safe, stay free. # Hacking: trovare SCADA in rete usando Google Dorks Si stima che Google abbia archiviato più pagine di un qualsiasi altro motore di ricerca del mondo. Con oltre miliardi di pagine e un tempo relativamente basso di esecuzione, il popolare motore di ricerca californiano riesce a soddisfare tutte le ricerche, sia eseguite per fini di curiosità sia per scopi meno innoqui. Il motore di ricerca è così potente da poter categorizzare oltre 15 milioni di pagine in meno di un minuto. Oltre a ciò, si ipotizza che ogni secondo siano condotte oltre 60 mila ricerche attraverso motore di ricerca Google. Questo significa oltre **1.000 miliardi** di ricerche all’anno! Numeri astronomici a cui Google riesce a stare dietro con l’enorme infrastruttura che ha realizzato. Sicuramente i motori di ricerca hanno stravolto la vita di molte persone; avere così tante informazioni nel giro di 1 minuto è un punto di riflessione per chiunque. Ma la cosa più sorprendente, nonostante questi numero, è che sfruttiamo una parcentuale minima delle potenzialità che questo strumento ci offre. Poche persone sanno che Google ha un linguaggio proprietario per estrarre tali informazioni oltre a cercare tramite parole chiave. Anche solo con una scarsa conoscenza delle parole chiave di Google, puoi trovare molte più informazioni di quanto tu abbia mai immaginato.Vediamone alcune. ## Cosa sono le Google Dorks Le dork vengono definite come query di ricerca che, anzichè contenere semplicemente la descrizione di ciò che stiamo cercando, sono composte anche da diverse keywods che permettono di affinare i parametri della ricerca stessa, al fine di ottenere dei risultati specifici. ### Scopi per cui vengono utilizzate Come detto, le dorks vengono utilizzate principalmente per affinare i risultati di ricerca, al fine di avere un elenco di links più specifici. Come esempio molto semplice, proviamo ad eseguire la ricerca sulla "pizza napoletana". La semplice parola "pizza", cercata su Google, ha oltre 1.360.000.000 di risultati, mentre combinata con la parola "napoletana" i risultati scendono drasticamente (ne rimangono comunque più di 15 milioni...). Questa è già un tentativo di affinare la nostra ricerca per restringere il campo di ricerca. Partendo dal presupposto che alcuni sysadmin potrebbero non aver applicato alcune regole, è possibile cercare alcuni file riservati e/o confidenziali, non destinati al grande pubblico di Internet. Attenzione però: sebbene alcuni webmaster espongano informazioni sensibili per conto proprio, questo non significa che sia legale sfruttarle al fine di ottenerne un vantaggio (economico o non). La semplice consultazione non è reato, ma lo sfruttamento sì ed è perseeguito penalmente. È abbastanza facile tracciare l’IP di navigazione, anche se si utilizza un servizio VPN. Non è così anscarsa conoscenza delle parole chiave di Google, puoi trovare più informazioni di quanto tu abbia mai immaginato.onimo come si pensa. Molte vulnerabilità vengono cercate da **script kiddies** proprio tramite Google. Un’attenta query infatti cerca per messaggi di errori, file di configurazione o altro che potrebbero in qualche modo esporre all’esterno versione del software o dati riservati. ### Alcune dorks di esempio | Nome dorks | Descrizione | Esempio | | ------------------- | ------------------------------------------------------------------------------------------ | ------------------ | | site:*domain* | i risultati saranno file e pagine presenti nel dominio domain | site:w3school.com | | intitle:*parola* | i risultati conterranno nel titolo la parola dopo la dork “intitle” | intitle:hi | | inurl:*parola* | i risultati conterranno nel titolo la parola dopo la dork “inurl” | inurl:gallery | | intext:*testo* | i risultati conterranno pagine con il "testo" ricercato | intext:"Index of" | | ext:*estensione* | i risultati conterranno files con l'estensione richiesta | ext:jpg | | filetype:*type* | i risultati conterranno file della estensione specificata da type | filetype:pdf | | cache:*url* | reindirizza l’utente alla cache Google dell’url specificato | cache:cyberhood.eu | | info:*root\_domain* | il risultato conterrà il dominio principale (root domain) e tutte le informazioni relative | info:amazon.com | Va detto che le dorks possono essere concatenate in modo da affinare ulteriormente la nostra ricerca, come ad esempio `ext:ini intext:env.ini` oppure `ext:mdb inurl:*.mdb inurl:fpdb shop.mdb` . ## Google Dorks per gli SCADA Va detto che non esiste una singola dork di Google che rivelerà ogni interfaccia SCADA esistente in rete, questo perchè dipende molto dal produttore e dai prodotti utilizzati. Ogni azienda crea i propri sistemi embedded con caratteristiche proprietarie. Condividono protocolli e procedure comuni, ma in generale sono oggetti unici. Alcuni dei principali produttori sono: Siemens, Schneider Electric, Rockwell Automation, GE. Oltre a questo, va considerato che ognuna di queste aziende produce più prodotti appartenenti alla stessa famiglia, per cui la ricerca richiede che vengano sviluppate delle Google Dorks specifiche per ciascuno di essi. Di seguito una breve sintesi di alcune delle principali marche e relative queries. ![](/files/-M7vxGWALR-7FXA2vJSP) ### Uso delle Google Dorks Ora che abbiamo le idee un po' più chiare, almeno lo spero, proviamo ad eseguire alcune dorks per trovare specifici sistemi SCADA. Cominciamo con uno dei prodotti più diffusi in Italia negli impianti di automazione: il PLC della serie S7 di Siemens. Come nota, ti ricordo che è la stessa famiglia di controller che sono stati il bersaglio del famigerato attacco Stuxnet contro la centrale nucleare iraniana di Natanz nel 2010, probabilmente il più sofisticato attacco SCADA al momento mai realizzato. La nostra Google Dork è composta in questo modo: `inurl:/Portal/Portal.mwsl` Quando la utilizziamo in una ricerca di Google, otteniamo i risultati visualizzati di seguito. ![](/files/-M7veMvlG-MlZ4JRw7fP) Se selezioniamo la prima voce dell'elenco (Siemens S7-1200\_1) accediamo alla pagina seguente: ![](/files/-M7vfIwXclXjq3hrf5GJ) Questo sembra essere il portale di amministrazione del PLC Siemens S7 da qualche parte nel mondo. Per proseguire la nostra ricerca, inseriamo l'indirizzo IP che Google ci ha fornito (78.218.196.95) in Shodan per vedere dove si trovi. E' a Bruyères in Francia. ![](/files/-M7vhMuZ4gZRyYi_t4wX) Quando si fa clic sulla scheda "**Identification**" a sinistra, il PLC si identifica come una stazione S7-1200\_1/PLC\_1. Inoltre ci fornisce il numero di serie e la versione del firmware (così ci semplifica un eventuale attacco). ![](/files/-M7vhzllq0fD61LfDl1W) La stessa cosa succede se selezioniamo la voce "**Communication**" sempre dal menù a sinistra. ![](/files/-M7viMcSTS63ff4lAt0s) Come possiamo vedere, la sicurezza dei sistemi ICS è ancora agli inizi, basandosi principalmente sulla sicurezza per oscurità. Queste semplici Google Dorks espongono in modo fin troppo facile degli impianti spesso critici senza il minimo criterio di sicurezza. Anche un hacker con abilità rudimentali può accedere ai sistemi di controllo e provocare il caos. ## **Nota importante** Lo scopo di questo articolo è unicamente didattico e informativo. **Ogni azione non autorizzata** verso qualunque sistema di controllo presente su una rete pubblica o privata **è illegale**! Le informazioni contenute in questo ed altri articoli hanno lo scopo di far comprendere quanto sia necessario migliorare i sistemi di difesa, e non di fornire strumenti per effettuarne l'attacco. Violare un sistema informatico è perseguibile penalmente e può causare gravi danni a cose e persone, in modo particolare se si parla di ICS. Tutti i test che vengono illustrati nei tutorials sono stati effettuati in laboratori isolati, sicuri, o autorizzati dal produttore. Stay safe, stay free. # Hacking: Schneider Electric Building Automation I sistemi ICS controllano i processi industriali in tutto il mondo. Tutto, dalle ferrovie, ai semafori, alle raffinerie di petrolio, agli edifici commerciali, è controllato da almeno un PLC connesso a un terminale operatore HMI o a un software di controllo SCADA. Alcune delle recenti preoccupazioni legate ad essi è la possibile violazione da parte di cyber criminali o di enti governativi. In entrambi i casi i risultati potrebbero essere devastanti (il disastro di Bhopal nello stabilimento di Union Carbide è costato oltre 30.000 vite). Nonostante ciò, questi sistemi sono insolitamente vulnerabili all'hacking e alle attività dannose. In questo tutorial mostrerò come hackerare un sistema di controllo industriale di Schneider Electric, uno dei maggiori produttori al mondo di sistemi ICS e per la Buinding Automation. A causa della debole sicurezza integrata in fase di sviluppo, problema molto diffuso nei prodotti IIoT, alcuni di questi sistemi sono incredibilmente facili da violare e prenderne il controllo. ### Conosciamo meglio il nostro target [Schneider Electric](https://www.se.com/ww/en/) è una società con sede a Parigi, leader mondiale nel settore del controllo industriale. Sono stati tra i pionieri in questo campo introducendo molti concetti innovativi poi replicati dai concorrenti, e hanno anche il merito di aver sviluppato il protocollo di comunicazione più utilizzato nei sistemi di controllo industriale: il [Modbus](https://it.wikipedia.org/wiki/Modbus). Schneider Electric all'interno del proprio vasto catalogo conta anche una gamma di PLC dedicati all'automazione degli edifici. ![Un server della famiglia SmartStruxure](/files/-M7rQEuRt-2iULv2ohvN) Uno dei loro prodotti, lo SmartStruxure Automation Server, viene utilizzato negli edifici commerciali per controllare e automatizzare i numerosi sistemi tra cui riscaldamento e raffreddamento, illuminazione, sicurezza, ecc. Nel 2016, il ricercatore indipendente Karn Ganeshen ha individuato una vulnerabilità 0-day, oggetto poi di una patch da parte di Schneider, che permetteva di entrare nel server con una shell e acquisire i privilegi di root. Ma andiamo con ordine. ### Trovare i server Schneider Automation con Shodan Possiamo trovare questi server di automazione su Shodan cercando: `"schneider electric" automation` ![I risultati su Shodan](/files/-M7rRVDvdcXI15t3A1Tf) Come possiamo notare, compare un lungo elenco di dispositivi direttamente connessi a Internet, con il relativo indirizzo IP pubblico. Nel nostro caso userò un prodotto dimostrativo all'interno della rete locale. ## La vulnerabilità La vulnerabilità in oggetto consente all'autore dell'attacco di connettersi al server di automazione con una shell SSH utilizzando le credenziali predefinite e di ottenere facilmente i privilegi di "root". Così facendo, l'attaccante non possiede solo la "scatola", ma l'intero edificio! ### Connessione al Building Automation Server Innanzitutto, colleghiamoci al nostro server con una shell SSH. Userò Kali Linux, ma dal momento che questo hack è molto semplice può essere eseguito usando qualsiasi distribuzione, senza l'ausilio di strumenti di hacking particolari come ad es. Metasploit. ``` root@kali:~# ssh -l admin ``` Dopo che ci siamo connessi il server ci chiederà una password. Utilizziamo la password predefinita "**admin**". ![](/files/-M7rVqqA2wGM_2H6ZbuS) A questo punto siamo all'interno dell'account amministratore di Automation Server. Possiamo digitare `help` per vedere quali comandi possiamo usare con questo account. ![](/files/-M7rW72KM4l4xoSugzsT) Ad esempio, digitiamo `release`. Il sistema risponde con le informazioni sulla versione del server. Inoltre, va notato che uno dei comandi è `reboot`, che potrebbe essere utile nel caso di un attacco DoS. ![](/files/-M7rWbCHzgYfNl2t55MD) Possiamo inoltre vedere il tempo trascorso dall'ultimo avvio digitando il comando `uptime`. Questa informazione è sempre molto utile in fase di attacco perchè può indicare, normalmente, il tempo trascorso da quando il sistema ha subito una patch di aggiornamento. ``` admin:> uptime ``` ![](/files/-M7rX821PpCtWGZFqjdh) Uno dei punti deboli di questo sistema è che possiamo usare il comando Linux pipe "|" per inoltrare ulteriori comandi al server sottostante. Facendo un esempio pratico, possiamo vedere il file "passwd" sul server digitando: ``` admin:> uptime | cat /etc/passwd ``` ![](/files/-M7rXtB992nrrAgqCUsW) In questo modo abbiamo elencato tutti gli account presenti sul server. Naturalmente questo file contiene solo gli account e non le password, che invece si trovano nel file **/etc/shadow** accessibile unicamente con i diritti di **root**. ### Privilege escalation La fase di privilege escalation, nella maggior parte dei casi in campo IT, richiede procedure a volte lunghe e complesse, indipendentemente che si stia attaccando una macchina Windows o Linux. Ma come ho detto, nel campo OT non sempre i livelli di sicurezza sono (in questo caso, "erano") adeguati. Possiamo ottenere il livello di root semplicemente digitando: ``` admin:> sudo -i ``` ![](/files/-M7rYs10PhwWlYTVZ5_K) **Boom!** La configurazione predefinita di questo server di automazione dell'edificio non ha password per l'account "root", quindi è sufficiente premere Invio quando viene richiesta una password. Come possiamo vedere, il prompt diventa verde e indica che siamo root! Dato che ora abbiamo i privilegi di root siamo in grado di fare praticamente qualsiasi cosa. Digitiamo `cat /etc/shadow` per vedere se riusciamo a recuperare gli hash delle password nella cartella **/etc/shadow**. ![](/files/-M7rZljwjPAzFAx9xeM0) Ed ecco che siamo riusciti a ottenere tutti gli account e i loro hash delle password! Se necessario, potremmo scoprirle attraverso un attacco brute-force come **hashcat** per recuperare le password in chiaro. È probabile che il file di configurazione per Automation Server sia nella directory **/etc**. Entriamo in questa cartella ed elenchiamo tutti i file e le directory. ```bash root:> cd /etc root:> ls -l ``` ![](/files/-M7r_yZKZZ1sqYcrk5EY) Se scorriamo questo elenco troviamo un file chiamato "whitelist.rules", che probabilmente contiene le regole per la connessione al server. Apriamolo. ``` root:> cat whitelist.rules ``` ![](/files/-M7raMELIWURJMTS5o5d) L'amministratore di sistema non ha mai impostato "whitelist.rules" su questo server e, di conseguenza, chiunque può connettersi. Infine, poiché abbiamo i privilegi di root possiamo aggiungere un nuovo utente che possano fare da backdoor. Prima di partire, posso aggiungermi agli utenti, concedermi i privilegi di root e aggiungermi a whitelist.rules, in modo che anche se l'amministratore dovesse correggere questa vulnerabilità avrò comunque un account e potrò accedere ancora a questo server. ``` root:> useradd cyberhood ``` Questo esempio risale alle vulnerabilità scoperte nel 2016 e riconosciute da Schneider Electric, che successivamente ha aggiornato i propri sistemi al fine di impedire un accesso così facile al server. Maggiori informazioni le puoi [trovare qui](https://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2016-025-01). **N.B.** Lo scopo di questa guida non è certo quello di screditare un produttore a discapito di un altro, ma vuole unicamente evidenziare quanto lavoro ci sia da fare sui **prodotti OT di tutti i principali produttori** al fine di renderli "**secure by design**", progettati e costruiti con criteri di sicurezza intrinseca. ## **Nota importante** Lo scopo di questo articolo è unicamente didattico e informativo. **Ogni azione non autorizzata** verso qualunque sistema di controllo presente su una rete pubblica o privata **è illegale**! Le informazioni contenute in questo ed altri articoli hanno lo scopo di far comprendere quanto sia necessario migliorare i sistemi di difesa, e non di fornire strumenti per effettuarne l'attacco. Violare un sistema informatico è perseguibile penalmente e può causare gravi danni a cose e persone, in modo particolare se si parla di ICS. Tutti i test che vengono illustrati nei tutorials sono stati effettuati in laboratori isolati, sicuri, o autorizzati dal produttore. Stay safe, stay free. # Hacking: Metasploit SCADA modules Come penetration tester abbiamo molte risorse a disposizione per testare il livello di sicurezza di un sistema IT. Uno dei più diffusi strumenti è [Metasploit Framework](https://www.metasploit.com/), sviluppato da Rapid7. Si tratta di uno strumento in grado di coprire le fasi di enumeration, exploitation e privilege escalation, molto flessibile e modulare. Da diverso tempo ormai, vista l'attenzione che il mondo della cybersec sta dedicando alle infrastrutture ICS, possiamo trovare un lungo elenco di moduli Metasploit che hanno come target i sistemi SCADA, i PLC e i principali protocolli di comunicazione industriale. Ed è proprio per via del fatto che i siti ICS utilizzano hardware e protocolli diversi occorre svolgere una fase di reconnaissance molto attenta per portare un attacco di successo. Serve conoscere il produttore e il protocollo per trovare il modulo appropriato. Di seguito ho riassunto l'elenco dei moduli presenti al momento della scrittura di questo articolo, suddivisi tra ausiliari (reconnaissance e commands) e di exploitation. ![Auxiliary modules](/files/-M7rv8Yag64wvmQlYtPs) ![Exploit modules](/files/-M7rvOh3hrD2gBw3bIWQ) ## **Nota importante** Lo scopo di questo articolo è unicamente didattico e informativo. **Ogni azione non autorizzata** verso qualunque sistema di controllo presente su una rete pubblica o privata **è illegale**! Le informazioni contenute in questo ed altri articoli hanno lo scopo di far comprendere quanto sia necessario migliorare i sistemi di difesa, e non di fornire strumenti per effettuarne l'attacco. Violare un sistema informatico è perseguibile penalmente e può causare gravi danni a cose e persone, in modo particolare se si parla di ICS. Tutti i test che vengono illustrati nei tutorials sono stati effettuati in laboratori isolati, sicuri, o autorizzati dal produttore. Stay safe, stay free. # Hacking: Profibus/Profinet Una delle sfide del pentesting in ambito OT/ICS è data dai protocolli impiegati che possono essere anche molto diversi da quelli dell'IT. Le installazioni ICS utilizzano un'ampia varietà di protocolli che spesso condividono hanno ben poco in comune con gli standard Ethernet e TCP/IP. Questa differenza è stata per anni il punto di forza delle installazioni OT, proteggendole attraverso il meccanismo della "sicurezza per oscurità". Ora che questi protocolli stanno diventando sempre più conosciuti e compresi, le preoccupazioni di sicurezza in queste strutture sono state accentuate. In questo articolo vediamo le principali caratteristiche di uno di questi protocolli: il **Profibus.** ## Lo standard Profibus **Profibus** (**Pro**cess **Fi**eld**bus**) è uno standard aperto per la comunicazione industriale originariamente sviluppato in Germania. È iniziato da un gruppo di 21 aziende e istituzioni denominate "Central Association for Electrical Industry" (ZVEI), guidato dal gigante industriale Siemens. Per questa ragione Profibus è ampiamente utilizzato nei prodotti Siemens ed è il bus di comunicazione sfruttato dal malware Stuxnet nella centrale nucleare iraniana di Natanz durante il famoso attacco informatico. Profibus è un protocollo intelligente e bidirezionale multipunto, in cui tutti i dispositivi Profibus sono interoperabili. I dati possono rappresentare valori analogici o digitali. È un protocollo economico, semplice e ad alta velocità. Profibus utilizza una connessione a due fili per alimentazione e dati. La tipologia del protocollo è master-slave, come molti altri protocolli SCADA/ICS, che supporta i nodi master mediante l'uso della condivisione di un token. Simile al protocollo token-ring di IBM, solo quando il master ha il token può comunicare con gli slave. Lo slave Profibus può comunicare solo con un master. Il nodo Profibus master è in genere un PLC o RTU e gli slave sono sensori, motori o altri dispositivi di controllo. ![](/files/-M7wDa96Ss_jwtI-vG9a) ### Tipi di Profibus La famiglia dei protocolli Profibus si divide principalmente in due due categorie: Profibus DP e ProfiNet. Gli impieghi cambiano sensibilmente: mentre il primo è un tradizionale fieldbus master-slave con trasmissione seriale con rete ad anello, il secondo ne è la sua evoluzione e permette la comunicazione tra segmenti diversi di bus utilizzando Ethernet. ![](/files/-M7wKvvNjPe20JIxPqxJ) #### Profibus FMS Questo era il protocollo Profibus iniziale. È stato progettato per comunicare tra PLC e PC. Sfortunatamente questo semplice protocollo non era molto flessibile e, di conseguenza, non poteva funzionare in una rete più complessa e complicata. Sebbene sia ancora in uso, la stragrande maggioranza delle reti Profibus utilizza una delle versioni più recenti. #### Profibus DP (Decentralized Periphery) Profibus DP è probabilmente il più comune dei protocolli Profibus. È più semplice e veloce rispetto agli altri tipi. È disponibile in tre versioni separate: DP-V0 (scambio ciclico di dati), DP-V1 (scambio aciclico di dati) e DP-V2 (modalità slave-to-slave isocrono e scambio di dati) con ogni nuova versione che offre funzionalità aggiuntive. #### Profibus PA (Process Automation) Profibus PA, come suggerisce il nome, è stato sviluppato per Process Automation. Questa versione del protocollo standardizza il processo di trasmissione dei dati misurati. Inoltre, è stato progettato per l'uso in ambienti pericolosi utilizzando la tecnologia Manchester Bus Powered (MBS) che utilizza una potenza inferiore e quindi riduce la possibilità di scintille ed esplosioni. ### PrifiNet (Process Field Net) ProfiNet (**Pro**cess **Fi**eld **Net**) è un altro standard aperto per l'automazione industriale progettato per la scalabilità. Invece di scambiare dati utilizzando il bus di campo (seriale), utilizza Ethernet (IEEE802.3) come supporto. È incluso come parte di IEC-61158 e IEC-61784. Inizialmente utilizzava pacchetti TCP/IP standard. ProfiNet ha come punto di forza il fornire dati con vincoli di tempo ristretti. Esso utilizza standard IT come TCP/IP e XML per comunicare, configurare e diagnosticare macchine e dispositivi. Può funzionare fino a 100 Mbit/s su cavi a doppino intrecciato o fibra ottica. ProfiNet NON è Profibus su Ethernet, ma sono compatibili con l'uso di specifici proxy per collegarli. ProfiNet ha due classi di funzioni: 1. ProfiNet I/O (input/output) 2. ProfiNet CBA (automazione basata su componenti) #### ProfiNet I/O Collega i dispositivi di campo distribuiti e utilizza comunicazioni real-time (RT) e standard (TCP/IP). Il canale real-time (RT) viene utilizzato per dati critici che richiedono tempi di scambio ridottissimi, come dati di processo ciclici, allarmi e monitoraggio delle comunicazioni ed è in grado di eseguire cicli di 10 ms. Il canale standard viene utilizzato per il download di configurazione e parametri, diagnostica, informazioni sulla gestione del dispositivo e altre comunicazioni non critiche con tempi di scambio nell'intervallo di 100 ms. Appartenente sempre alla famiglia I/O esiste poi il ProfiNet IRT (Isochronous Real-Time), che viene utilizzato nei sistemi di azionamento con tempi di ciclo inferiori a 1 ms. Poiché ProfiNet IRT è una tecnologia Layer 2 basata su hardware non è instradabile. Profibus I/O utilizza le porte TCP/UDP numero 34962, 34963 e 34964. #### ProfiNet CBA E' progettato per applicazioni di automazione industriale distribuita. ProfiNet CBA è basato sullo standard DCOM (Distributed Component Model) e RPC (Remote procedure Call). Questo significa anche che ne eredita quindi le vulnerabilità di DCOM e RPC. ProfiNet CBA utilizza la porta standard TCP numero 135. ## La sicurezza dei protocolli Come molti protocolli OT/ICS, anche Profibus DP manca di autenticazione. Ciò significa che qualsiasi nodo può falsificare un nodo master. Poiché solo quest'ultimo può controllare gli slave, questa è una delle maggiori vulnerabilità del sistema. Un nodo master contraffatto sarebbe in grado di acquisire il token, interrompere le funzioni del nodo e persino causare un Denial of Service (DoS). Dal momento che la maggior parte dei nodi master in una rete Profibus DP sono collegati a una rete Ethernet, questo li rende sensibili a quasi tipo di attacco basato su Ethernet. La stessa cosa vale per ProfiNet. Poiché esistono diverse tecnologie in questa suite il rischio dipende da quella utilizzata. Fa eccezione, almeno in parte, il protocollo ProfiNet IRT che utilizza indirizzi non instradabili e quindi risulta immune alle vulnerabilità IP. ## **Nota importante** Lo scopo di questo articolo è unicamente didattico e informativo. **Ogni azione non autorizzata** verso qualunque sistema di controllo presente su una rete pubblica o privata **è illegale**! Le informazioni contenute in questo ed altri articoli hanno lo scopo di far com‌prendere quanto sia necessario migliorare i sistemi di difesa, e non di fornire strumenti per effettuarne l'attacco. Violare un sistema informatico è perseguibile penalmente e può causare gravi danni a cose e persone, in modo particolare se si parla di ICS. Tutti i test che vengono illustrati nei tutorials sono stati effettuati in laboratori isolati, sicuri, o autorizzati dal produttore. Stay safe, stay free. # Hacking: Modbus Una delle sfide del pentesting in ambito OT/ICS è data dai protocolli impiegati che possono essere anche molto diversi da quelli dell'IT. Le installazioni ICS utilizzano un'ampia varietà di protocolli che spesso hanno ben poco in comune con gli standard Ethernet e TCP/IP. Questa differenza è stata per anni il punto di forza delle installazioni OT, proteggendole attraverso il meccanismo della "sicurezza per oscurità". Ora che questi protocolli stanno diventando sempre più conosciuti e compresi, le preoccupazioni di sicurezza in queste strutture sono state accentuate. In questo articolo vediamo le principali caratteristiche di uno di questi protocolli: il **Modbus.** ## Lo standard Modbus Il protocollo Modbus si caratterizza principalmente per il supporto fisico di connessione, che può essere su porta seriale o su Ethernet. Esistono diverse varianti del protocollo: * Modbus RTU * Modbus ASCII * Modbus TCP * Modbus over TCP/IP o Modbus RTU/IP * Modbus over UDP * Modbus Plus (Modbus+) * Secure Modbus In questo articolo tratterò quelli più diffusi: Modbus RTU e Modbus TCP. Farò anche un cenno sul Secure Modbus, una versione del protocollo orientata alla sicurezza e che incorpora un layer per la cifratura dei dati. ### Modbus RTU Modbus RTU è stato sviluppato per la prima volta nel 1979 da Modicon (ora parte di Schneider Electric) per i propri sistemi di automazione industriale e PLC. È diventato lo standard de facto del settore. Modbus è un protocollo di dominio pubblico ampiamente accettato, è un protocollo semplice e leggero destinato alla comunicazione seriale. Ha un limite di dati di 253 byte. Modbus opera al livello 7 del modello OSI. È una metodologia di comunicazione efficiente tra dispositivi interconnessi utilizzando un modello di "richiesta/risposta". Proprio perché è semplice e leggero richiede poca potenza di elaborazione. Basti pensare che esistono librerie di comunicazione disponibili per praticamente qualunque dispositivo embedded, a partire da una semplice scheda Arduino fino alla più sofisticata Raspberry. Modbus è stato inizialmente implementato sulla tipologia fisica RS-232C (punto-punto) o RS-485 (multi-drop). Può avere fino a 32 dispositivi che comunicano tramite un collegamento seriale con ciascun dispositivo con un ID univoco. ![](/files/-M7wWZ4KRNIYNaZSKlu6) Modbus utilizza un'architettura master/slave (client/server) in cui solo un dispositivo può inviare le richieste. Gli slave/server forniscono i dati richiesti al master o eseguono l'azione richiesta dal master stesso. Uno slave è qualsiasi dispositivo periferico (trasduttore, valvola, unità di rete o altro ancora) che elabora le informazioni e invia il suo output al master tramite il protocollo Modbus. I master possono rivolgersi a singoli slave o inviare un messaggio in broadcast a tutti gli slave. Gli slave restituiscono una risposta a tutte le query indirizzate a loro individualmente, ma non rispondono alle query broadcast. Gli slave non generano messaggi, possono solo rispondere al master. La query di un master sarà composta dall'indirizzo slave (ID slave o ID unità), un codice funzione, tutti i dati richiesti e un campo di controllo degli errori CRC. Modbus comunica utilizzando i **Function Codes**, codici funzione che identificano un'ampia gamma di comandi. ![Principali Function Codes per accesso dati e diagnostica](/files/-M7wYlGPCJX0pNhKH0DH) ### Modbus TCP Modbus TCP è il protocollo Modbus incapsulato per l'uso su TCP/IP usando la porta 502. Utilizza la stessa richiesta/risposta di Modbus RTU, gli stessi codici funzione e lo stesso limite di dati di 253 byte. Il campo di controllo degli errori utilizzato in Modbus RTU viene eliminato poiché il livello di collegamento TCP/IP utilizza i suoi metodi di checksum. Modbus TCP aggiunge un livello applicazione (MBAP) al frame Modbus RTU. È lungo 7 byte con 2 byte per l'intestazione, 2 byte per l'identificatore del protocollo, 2 byte per la lunghezza e 1 byte per l'indirizzo (ID unità). ![](/files/-M7wf0JlwNBtJFW4gOnr) L'utilizzo di Ethernet consente di realizzare architetture più complesse, anche di tipo ibrido facendo uso di appositi gateway. ![Architettura ibrida RTU / TCP](/files/-M7wfLK_THgh7aBuB23f) ### Formato del pacchetto dati Un frame Modbus consiste in un Application Data Unit (ADU) che incapsula un Protocol Data Unit (PDU), secondo questo schema: * ADU = Address + PDU + Error check * PDU = Function code + Data L'ordine dei byte per i valori nei frame di dati Modbus è il byte più significativo di un valore multi-byte inviato prima degli altri. Tutte le varianti Modbus utilizzano uno dei seguenti formati di frame. #### Formato del frame Modbus RTU | Nome | Lung. (bits) | Funzione | | -------- | ------------ | --------------------------------------------------------------- | | Start | 28 | Almeno 3½ caratteri di inizio frame (con condizione del segno) | | Address | 8 | Indirizzo della stazione | | Function | 8 | Codice funzione, es. read coils/holding registers | | Data | n × 8 | Dati + lunghezza verranno riempiti in base al tipo di messaggio | | CRC | 16 | Cyclic Redundancy Check | | End | 28 | Almeno 3½ caratteri di silenzio tra i frames | Note sul calcolo del CRC: * Polinomiale: x16 + x15 + x2 + 1 (CRC-16-ANSI anche noto come CRC-16-IBM, polinomio algebrico esadecimale normale essendo `8005` e invertito `A001`). * Valore iniziale: 65.535. * Esempio di frame in esadecimale: `01 04 02 FF FF B8 80` (CRC-16-ANSI calcolato a partire da `01` fino a `FF` genera `80B8`, viene **prima** trasmesso il byte **meno** significativo). #### Formato del frame Modbus ASCII | Nome | Lung. (bytes) | Funzione | | -------- | ------------- | ------------------------------------------------------------------------------------------------------- | | Start | 1 | Inizia con `:` (valore ASCII`3A`) | | Address | 2 | Indirizzo della stazione | | Function | 2 | Codice funzione, es. read coils | | Data | n × 2 | Dati + lunghezza verranno riempiti in base al tipo di messaggio | | LRC | 2 | Checksum ([Longitudinal redundancy check](https://en.wikipedia.org/wiki/Longitudinal_redundancy_check)) | | End | 2 | \\ insieme (valori ASCII `0D`, `0A`) | #### Formato del frame Modbus TCP | Name | Lung. (bytes) | Funzione | | ---------------------- | ------------- | ------------------------------------------------------- | | Transaction identifier | 2 | Per la sincronizzazione tra messaggi di server e client | | Protocol identifier | 2 | 0 per Modbus/TCP | | Length field | 2 | Numero di byte rimanenti in questo frame | | Unit identifier | 1 | Indirizzo slave (255 se non usato) | | Function code | 1 | Codice funzione | | Data bytes | n | Dati come risposta o comandi | ## Sicurezza del protocollo Modbus Modbus deve la sua larghissima diffusione alla semplicità del protocollo e alla sua ormai storica presenza sul mercato. Ma proprio per questi due fattori offre il fianco a diverse possibilità di attacco, con numerose vulnerabilità note. Ecco come potrebbero essere eseguiti alcuni attacchi sfruttando le semplici funzioni che il protocollo stesso mette a disposizione, senza strumenti dedicati all'enumeration come **nmap**. > Un hacker può iniziare il suo attacco in fase di reconnaissance eseguendo lo scanning della rete per individuare i dispositivi Modbus usando i comandi di diagnostica del protocollo: **Clear Counter** e **Diagnostic Register**. Una richiesta inviata al PLC, con codice funzione 8 (0x08) e codice funzione secondaria 10 (0x0A), farà in modo che il server di destinazione cancelli i suoi contatori e il registro diagnostico. Questa funzione è in genere implementata solo nei dispositivi seriali. > Un altro comando di diagnostica che può essere utilizzato è il **Read Device Identification** come tentativo di raccogliere informazioni sul dispositivo Modbus: una richiesta con il codice funzione 43 di Read Device Identification farà sì che un server Modbus restituisca il nome del fornitore, il nome del prodotto e il numero di versione. Ulteriori informazioni possono essere fornite anche in campi opzionali. Un utente malintenzionato invia il pacchetto di richiesta Modbus con il codice funzione 43 a tutti i sistemi della rete e raccoglie informazioni che potrebbero essere utili per successivi attacchi. ### Vulnerabilità del protocollo Modbus L'implementazione del protocollo Modbus TCP contiene diverse vulnerabilità che potrebbero consentire a un utente malintenzionato di eseguire attività di enumeration o di inviare comandi arbitrari. 1. **Mancanza di riservatezza**: tutti i messaggi Modbus vengono trasmessi in chiaro attraverso il supporto di trasmissione. 2. **Mancanza di integrità**: non esistono controlli di integrità all'interno del protocollo e, di conseguenza, dipende da protocolli di livello inferiore preservare l'integrità dei dati. 3. **Mancanza di autenticazione**: non esiste autenticazione a nessun livello del protocollo, con la possibile eccezione di alcuni comandi di programmazione non documentati. 4. **Framing semplicistico**: i frame Modbus TCP vengono inviati tramite connessioni TCP stabilite. Sebbene tali connessioni siano generalmente affidabili, presentano un significativo svantaggio per via del punto successivo. 5. **Mancanza di struttura della sessione**: come molti protocolli di richiesta/risposta (es. SNMP, HTTP, ecc.) Modbus TCP è costituito da transazioni di breve durata in cui il master invia una richiesta allo slave che si traduce in una singola azione. Se combinato con la mancanza di autenticazione e la scarsa generazione del TCP Initial Sequence Number (ISN) in molti dispositivi embedded, diventa possibile per gli aggressori immettere comandi senza conoscere la sessione esistente. **Vulnerabilità "Illegal Function Exception"**\ Queste vulnerabilità consentono a un utente malintenzionato di svolgere attività di ricognizione sulla rete di destinazione. La prima vulnerabilità esiste perché un dispositivo slave Modbus può restituire una *Illegal Function Exception* per le query che contengono un codice funzione non supportato. Un utente remoto non autenticato può sfruttare questa vulnerabilità inviando codici funzione predisposti per effettuare ricognizioni sulla rete di destinazione. **Vulnerabilità "Illegal Address Exception"**\ Un'ulteriore vulnerabilità di ricognizione è dovuta alle molteplici risposte di *Illegal Address Exception* generate per le query che contengono un indirizzo slave illegale. Un utente malintenzionato non autenticato può sfruttare questa vulnerabilità inviando query che contengono indirizzi non validi alla rete di destinazione e raccogliere informazioni sugli host di rete dai messaggi restituiti. **Vulnerabilità sull'autenticazione**\ Un'altra vulnerabilità è dovuta alla mancanza di controlli di sicurezza nell'implementazione del protocollo Modbus TCP. Le specifiche del protocollo non includono un meccanismo di autenticazione per la convalida della comunicazione tra i dispositivi master e slave. Questo difetto potrebbe consentire a un utente non autenticato di inviare comandi arbitrari a qualsiasi dispositivo slave tramite un master di attacco. **Vulnerabilità DoS**\ Il protocollo Modbus TCP contiene anche vulnerabilità che potrebbero consentire a un utente malintenzionato di causare una condizione di Denial of Service (DoS) su un sistema di destinazione. La vulnerabilità è dovuta a un errore di implementazione nel protocollo stesso durante l'elaborazione dei messaggi di richiesta e risposta di input discreti. **Vulnerabilità di buffer overfllow**\ Un altro attacco a Modbus può essere il pacchetto dati che supera la lunghezza massima. Il protocollo limita la dimensione della PDU a 253 byte per consentire l'invio del pacchetto su una linea seriale, es. interfaccia RS-485. Modbus TCP antepone alla PDU un'intestazione Modbus Application Protocol (MBAP) di 7 byte e il tutto, MBAP+PDU, viene incapsulato in un pacchetto TCP. Ciò pone un limite massimo alla dimensione del pacchetto. Un utente malintenzionato crea un pacchetto appositamente predisposto di lunghezza superiore a 260 byte e lo invia a un client e server. Se il client o server sono stati programmati in modo errato ciò potrebbe provocare un overflow del buffer o un attacco denial-of-service. **Sniffing del protocollo**\ L'attacco più semplice da usare contro Modbus è lo sniffing del traffico di rete, trovare i dispositivi connessi e quindi inviare comandi dannosi ai dispositivi. Non avendo funzionalità di sicurezza o crittografia, è facile utilizzare Wireshark per raccogliere informazioni da pacchetti di dati che sulla rete da e verso una porta Modbus su un dispositivo e leggere il contenuto di tali pacchetti. Wireshark consente di vedere facilmente cosa è contenuto in questi pacchetti, esaminare gli indirizzi IP, vedere i codici funzione delle richieste e alterare il corretto funzionamento dei dispositivi. ![Whireshark in azione](/files/-M7wsbMP9hyljyhWJziT) ### Secure Modbus L’approccio più comune alla protezione dei protocolli OT è quello di incapsularli all’interno di un protocollo TLS (Transport Layer Security) e utilizzare l’autenticazione reciproca. Molti organismi di standardizzazione pubblicano linee guida per farlo a seconda dei protocollo, ad esempio: * ODVA specifica come applicare la crittografia TLS al protocollo EtherNet/IP. * Schneider Electric ha recentemente lavorato per creare una versione **Secure Modbus**, che prevede anche l’aggiunta dell’estensione X.509 per la definizione delle autorizzazioni (read-only o read-write). * IEC 62351-3 definisce come utilizzare TLS per il settore dell’industria energetica sui protocolli basati su TCP. ![Modbus TCP Security](/files/-M7wtn9xDyhsf0U4zZC8) ![](/files/-M7wtu_fCz6TwbF8zSad) ## **Nota importante** Lo scopo di questo articolo è unicamente didattico e informativo. **Ogni azione non autorizzata** verso qualunque sistema di controllo presente su una rete pubblica o privata **è illegale**! Le informazioni contenute in questo ed altri articoli hanno lo scopo di far com‌prendere quanto sia necessario migliorare i sistemi di difesa, e non di fornire strumenti per effettuarne l'attacco. Violare un sistema informatico è perseguibile penalmente e può causare gravi danni a cose e persone, in modo particolare se si parla di ICS. Tutti i test che vengono illustrati nei tutorials sono stati effettuati in laboratori isolati, sicuri, o autorizzati dal produttore. Stay safe, stay free. # Hacking: simulazione Modbus TCP in Linux I sistemi ICS utilizzano molti protocolli diversi per comunicare rispetto ai sistemi IT standard. Lo standard più utilizzato è il protocollo [Modbus](https://it.wikipedia.org/wiki/Modbus). Sviluppato per la prima volta da Modicon (ora Schneider Electric) nel 1979 come protocollo seriale, è stato modificato e aggiornato per funzionare su rete Ethernet TCP, assumendo il nome di Modbus TCP. Di seguito puoi vedere un diagramma che riassume la struttura del pacchetto RTU (seriale) e quella TCP. ![](/files/-M7wf0JlwNBtJFW4gOnr) Se vuoi approfondire l'argomento ti suggerisco di leggere la guida che ho scritto "[Hacking: Modbus](/hacking/ot-ics-hacking/hacking-modbus)". In questo tutorial simuleremo una configurazione master e slave Modbus per illustrare come questo protocollo ormai quasi onnipresente nei sistemi OT funzioni in un ambiente industriale. Lo scopo è di capire meglio come funziona il protocollo e come può essere hackerato, manipolato e protetto. ## Installazione Modbus utilizza un'architettura master/slave (client/server) in cui solo un dispositivo può inviare le richieste. Gli slave/server forniscono i dati richiesti al master o eseguono l'azione richiesta dal master stesso. Uno slave è qualsiasi dispositivo periferico (trasduttore, valvola, unità di rete o altro ancora) che elabora le informazioni e invia il suo output al master tramite il protocollo Modbus. Nel nostro caso useremo due software di simulazione disponibili in forma gratuita, uno con funzionalità di master chiamato [QModMaster](https://sourceforge.net/projects/qmodmaster/) e l'altro in versione slave, dal nome [ModbusPal](https://sourceforge.net/projects/modbuspal/). **QModMaster** è un'applicazione open source basata sul framework Qt che implementa le funzioni di un master Modbus. E' dotata di una GUI che consente una facile configurazione delle modalità di comunicazione (RTU, TCP) e di un bus monitor per analizzare il traffico dei pacchetti di comunicazione. Nel caso si utilizzi Windows è disponibile la versione binaria pre-compilata. Nel nostro caso, faremo il download del codice sorgente e ne eseguiremo la compilazione su una macchina Linux. ![QModMuster in esecuzione su Linux](/files/-M8ALFFdPD2mVCbacCxu) **ModbusPal** è un'applicazione scritta in Java, quindi non necessita di alcuna compilazione in quanto indipendente dall'host di esecuzione. Simula un dispositivo slave Modbus, con alcune funzioni avanzate come gli scripts Python. ![ModbusPal con la tipica interfaccia "Java style"](/files/-M8ALWM-NOFN3rP6ZtrG) Come detto, dobbiamo compilare QModBus in modo che possa essere eseguito su sistemi Linux, nel mio caso Kubuntu 19.10. Scarichiamo il coside sorgente [qModMaster-code-0.5.2-3.zip](https://sourceforge.net/projects/qmodmaster/files/qModMaster-code-0.5.2-3.zip/download) e salviamolo in una cartella di lavoro, nel mio caso `~/Develop/Projects/Modbus/qModMaster-code-0.5.2-3`. Se listiamo i files presenti nella cartella vediamo che è presente il file `qModMaster.pro`, tipico di un progetto sviluppato con Qt. Per la compilazione è necessario disporre di una versione minima Qt 5.2.1 o superiore, scaricabile da [questo link](http://www.qt.io/download/). ![](/files/-M8ANGX46MjO-DlnRPep) A questo punto possiamo usare il comando `qmake` per convertire il file .pro in Makefile, compilabile con il più classico `make`. ``` $ qmake -o Makefile qModMaster.pro $ make ``` Dopo alcuni secondi di elaborazione abbiamo il nostro eseguibile pronto! ## Utilizzo del simulatore Per prima cosa dobbiamo configurare lo slave, in modo che metta a disposizione le proprie risorse da far leggere al master, in questo caso configuriamo dei registri "Holding Registers". {% hint style="info" %} Entrambe le applicazioni richiedono privilegi `sudo` per poter accedere alla porta 502/TCP, per cui occorre avviarle con `sudo ./ModbusPal` e `sudo ./qModMaster` nelle rispettive cartelle di lavoro. {% endhint %} ### **Configurazione del modulo slave ModbusPal** **Link settings**\ Selezioniamo "TCP Port 502".\ Il protocollo Modbus TCP usa di default la porta 502 per la comunicazione TCP **Modbus slaves**\ Aggiungiamo un nodo slave premendo il pulsante "Add", selezioniamo il numero dello slave e inseriamo un nome, nel nostro caso "Slave1". ![](/files/-M8AeE0gPI0_TuNY-Djk) A questo punto dobbiamo configurare i parametri che rendiamo disponibili nel nostro slave. Click sull'icona con l'occhio per aprire la schermata delle proprietà. Successivamente, click su "Add" e inseriamo il numero di registri che vogliamo aggiungere, nel nostro caso da 1 a 8. ![](/files/-M8Af-_3Z8VwYTAhiqzC) Ed ecco che compare la lista degli holding registers che abbiamo creato, con valori di default a 0. Possiamo già modificare il loro valore a piacimento, oppure farlo quando anche il master è attivo per vederne la lettura aggiornata in tempo reale. ![](/files/-M8AgrwnhsZFPiO1idWr) Siamo pronti per avviare lo slave, premiamo il pulsante "Run" della schermata principale e passiamo a configurare il master. ### **Configurazione del modulo master QModMaster** La configurazione del modulo master è altrettanto semplice, occorre tener presente alcuni parametri coerenti con lo slave che abbiamo creato: **Mobbus Mode:** TCP\ **Unit ID:** 1 (corrisponde al numero dello slave che abbiamo dichiarato prima)\ **Function Code:** Read Holding Registers (0x03)\ **Number of Registers:** 8 ![](/files/-M8AkXsPh57vngNOJgdp) I "Function Code" e "Mumber of Registers" corrispondono al tipo e alla quantità di dati che abbiamo dichiarato nel modulo slave. Di fault l'app master è configurata in modo che comunichi con indirizzp IP 127.0.0.1 e porta 502 (come anche lo slave). Possiamo cambiare questi valori selezionando la schermata dal menù "Options" e poi "Modbus TCP". ![](/files/-M8AlvyOkAvrQ7cSCYrk) A questo punto non ci resta che attivare la connessione e l'aggiornamento continuo dei dati tramite i pulsanti "Connect" e "Scan". Il tempo di aggiornamento continuo dei dati è determinano dal parametro "Scan Rate (ms)", che nel nostro caso corrisponde a un intervallo di 1 secondo. ### Aggiornamento dei dati ![](/files/-M8AlGrG3-kzCos1WEua) Ed ecco che se andiamo a modificare i dati dei registri del nostro slave avremo il corrispondente aggiornamento sul master. ### Proviamo a scrivere col master Ora che abbiamo visto come sia possibile leggere i dati dallo slave proviamo a modificare i valori dei registri dal master. Interrompiamo lo scan continuo e scegliamo "Write Multiple Registers" nel parametro "Function Code" della schermata principale di QModMaster. ![Selezioniamo Write Multiple Registers](/files/-M8At4cfAxtdQsnQS3-U) Riattiviamo lo scan continuo, ora possiamo fare un doppio click su ciascun campo del registro per modificarne il valore, che vedremo aggiornarsi sul modulo slave. ![](/files/-M8Asm5lxsts1wEW9pn7) ## **Nota importante** Lo scopo di questo articolo è unicamente didattico e informativo. **Ogni azione non autorizzata** verso qualunque sistema di controllo presente su una rete pubblica o privata **è illegale**! Le informazioni contenute in questo ed altri articoli hanno lo scopo di far com‌prendere quanto sia necessario migliorare i sistemi di difesa, e non di fornire strumenti per effettuarne l'attacco. Violare un sistema informatico è perseguibile penalmente e può causare gravi danni a cose e persone, in modo particolare se si parla di ICS. Tutti i test che vengono illustrati nei tutorials sono stati effettuati in laboratori isolati, sicuri, o autorizzati dal produttore. Stay safe, stay free. # Hacking: attaccare un PLC con Stuxnet Stuxnet docet... Per illustrare come sia possibile attaccare un PLC e quali potrebbero essere le conseguenze di ciò diamo un'occhiata al worm [Stuxnet](https://en.wikipedia.org/wiki/Stuxnet). ![](/files/-M8BUyrWWTm9mSwPWzAC) ## Introduzione a Stuxnet Stuxnet è un worm indipendente, destinato esclusivamente ai sistemi di controllo di supervisione e acquisizione dati (SCADA) di Siemens. Il worm è stato progettato per attaccare specifici PLC Siemens e ha sfruttato quattro vulnerabilità 0-day. La versione finale di Stuxnet è stata scoperta per la prima volta in Bielorussia nel giugno 2010 da [Sergey Ulasen](https://eugene.kaspersky.com/2011/11/02/the-man-who-found-stuxnet-sergey-ulasen-in-the-spotlight/) di Kaspersky Labs. Una versione precedente di Stuxnet era già stata scoperta nel 2009. Tuttavia, il worm è stato sviluppato molto prima, probabilmente già nel 2005. Stuxnet è stato progettato principalmente per danneggiare una centrale nucleare situata a Natanz, in Iran. Sfortunatamente però Stuxnet si è diffuso in oltre 115 paesi, il che dimostra come anche un attacco mirato potrebbe diffondersi e causare danni al di fuori del suo scopo principale. Il worm è stato appositamente progettato per modificare la velocità del rotore delle centrifughe all'interno della centrale nucleare di Natanz, causandone l'esplosione. Ciò che è interessante con Stuxnet è che si trattava di un worm mirato, progettato con cura per causare danni solo se fossero stati soddisfatti determinati criteri, il che significa che la maggior parte degli impianti in cui si è successivamente diffuso non avrebbero dovuto subire danni. In effetti, Stuxnet aumenterebbe la velocità del rotore delle centrifughe solo se l'architettura del sistema di controllo industriale corrispondesse all'impianto nucleare di Natanz. Per la sua struttura e complessità, Stuxnet è stata definita come una minaccia persistente avanzata (APT). Un APT raccoglie i dati ed esegue i comandi continuamente per un lungo periodo di tempo senza essere rilevato. Questo è anche noto come attacco "basso e lento". ## Come funziona Il worm Stuxnet è stato portato nella struttura di Natanz attraverso un'unità flash USB, consentendogli di attaccare il sistema dall'interno. Ciò era considerato uno dei prerequisiti per l'attacco in quanto la struttura di Natanz non era direttamente accessibile da Internet ma potretto tramite air gap. ![Un PLC Simatic S7-300](/files/-M8BZxNPO2G-PvgpLA_v) Dopo l'esecuzione, il worm si è diffuso su tutta la rete fino a quando non ha trovato un sistema operativo Windows con STEP 7. ![Siemens Step 7](/files/-M8B_ST_ljzKze3STG9w) STEP 7 è il software di programmazione Siemens progettato per i propri PLC. Il computer che esegue STEP 7 è noto come computer di controllo e interagisce direttamente con e invia comandi al PLC. Una volta arrivato con successo al computer di controllo STEP 7, Stuxnet ha manipolato i blocchi di codice inviati dal computer di controllo, eseguito comandi pericolosi sul PLC e fatto girare le centrifughe a una frequenza superiore rispetto a quanto inizialmente programmato. {% hint style="info" %} Il software STEP 7 utilizza una libreria chiamata **s7otbxdx.dll** per eseguire la comunicazione con il PLC. Ad esempio, se un blocco di codice deve essere letto dal PLC viene chiamata la routine "s7blk\_read". Stuxnet usa una tecnica di DLL hijacking per intercettare tutti i comandi provenienti da STEP 7 e WinCC (il sistema SCADA di Siemens) e, a sua volta, li inoltra alla libreria originale dopo averne modificato il contenuto. In questo modo invia comandi imprevisti al PLC restituendo agli utenti un loop di valori di funzionamento normale. {% endhint %} ![L'attacco di tipo DLL hijacking sulle librerie STEP 7](/files/-M8Bae1sx7IaravLEK-l) Gli attacchi al PLC sono stati eseguiti ogni 27 giorni circa per rendere l'attacco furtivo e difficile da rilevare, che rappresenta una parte centrale di un APT. Stuxnet ha inoltre rilevato il computer di controllo e visualizzato un output falso sul software STEP 7. Questo passaggio dell'attacco era una parte fondamentale nota come "inganno". Gli ingegneri situati nella centrale nucleare non hanno ricevuto alcuna indicazione di errori, supponendo che le centrifughe stessero ruotando alla frequenza corretta. Ricevendo un output falso in STEP 7, essi presumevano che il tracollo fosse stato causato da un errore umano anzichè da un malware. Stuxnet ha anche nascosto il codice direttamente sul PLC dopo l'infezione ed è stato quindi definito anche un rootkit del PLC. ![Un esempio di sistema SCADA basato su Siemens WinCC](/files/-M8B_yErj-zldPRY6Rpt) Per la sua diffusione in rete Stuxnet ha sfruttato una delle vulnerabilità 0-day dei sistemi operativi Windows. Esso infatti si è diffuso attraverso il protocollo di condivisione dei file Server Message Block (SMB) come documentato nel rapporto sulla vulnerabilità [CVE-2008-4250](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4250) nel National Vulnerability Database. La vulnerabilità ha consentito l'esecuzione di codice in modalità remota, diffondendosi in modo aggressivo sulla rete locale. Il worm aveva diverse altre funzionalità, come l'auto-replica, si aggiornava usando un centro di comando e controllo, conteneva un rootkit di Windows che nascondeva i suoi file binari e tentava di aggirare i sistemi di sicurezza presenti sui computer (anti-virus e anti-malware). ## Le conseguenze del suo attacco Stuxnet è conosciuta come la prima arma digitale del mondo e ha distrutto circa 1.000 centrifughe all'interno della centrale di Natanz. Gli attacchi informatici che causano danni fisici hanno rivoluzionato il modo in cui gli esperti di sicurezza informatica eseguono l'analisi delle minacce, nonché il modo in cui i produttori di PLC li progettano. Se vogliamo trovargli un merito, Stuxnet ha spazzato via la convinzione che i sistemi ICS fossero inviolabili, sicuri perchè isolati e perchè così diversi dai tradizionali dispositivi presenti nel mondo IT. Ma la conseguenza più grande è determinata dal fatto che per la prima volta un ente governativo, in questo caso quello americano insieme a quello israeliano, ha creato un'arma informatica in grado di causare danni a persone e cose. Non si era ancora visto qualcosa del genere e di questa entità, hackers e malwares avevano finora l'obiettivo di estorcere denaro, rubare informazioni o infrangere barriere politiche, ma nessuno aveva superato la soglia del danno tangibile. ## Hacking di un PLC Una parte di Stuxnet consisteva nell'utilizzare i PLC di destinazione come strumento hacker mediante un rootkit del PLC e manipolando la comunicazione tra il computer di controllo (SCADA) e il PLC stesso. Mirando entrambi questi dispositivi Stuxnet è riuscito a raggiungere il suo obiettivo e allo stesso tempo ha ingannato gli operatori, avendo così abbastanza tempo per distruggere le centrifughe. Stuxnet come APT è un attacco sofisticato che richiede una significativa raccolta di informazioni e risorse per essere eseguito. È inoltre necessario disporre di conoscenze approfondite sui protocolli di comunicazione proprietari in uso e sull'architettura dei PLC target, in particolare per la realizzazione del rootkit. Il suo codice è ora pubblicamente disponibile e può essere studiato in modo approfondito. Un sistema di controllo industriale (ICS) e un PLC fanno uso di più protocolli di comunicazione. Tra i più utilizzati troviamo [Profinet, Profibus](/hacking/ot-ics-hacking/hacking-profibus-profinet) e [Modbus](/hacking/ot-ics-hacking/hacking-modbus). La maggior parte di essi sono stati concepiti all'origine senza misure di sicurezza integrate, con la conseguenza di permettere l'esecuzione di codice in modalità remota, lo sniffing dei pacchetti e gli attacchi replay a causa della mancanza di autenticazione e crittografia. Profinet utilizza l'hardware Ethernet tradizionale, che lo rende compatibile con la maggior parte delle apparecchiature. Profinet è ampiamente utilizzato nel settore dell'automazione e il suo design si basa sul modello Open Systems Interconnection (OSI). Profinet consente la comunicazione bidirezionale ed è il protocollo di comunicazione preferito per i PLC Siemens Simatic. ![](/files/-M7wKvvNjPe20JIxPqxJ) Profibus è uno standard di comunicazione internazionale per bus di campo. Viene utilizzato per collegare insieme più dispositivi e consente la comunicazione bidirezionale. Esistono due tipi di Profibus: Profibus Decentralized Peripherals (DP) e Profibus Process Automation (PA). Una limitazione con Profibus è che è in grado di comunicare solo con un dispositivo alla volta. La nuova versione di Profibus è standardizzata in IEC 61158. Modbus è un protocollo di comunicazione seriale progettato e pubblicato da Modicon (Schneider Electric) nel 1979. Modbus esegue una comunicazione di tipo master e slave, con un numero massimo di dispositivi fino a 247. Il computer di controllo - HMI o SCADA - normalmente funge da master, mentre i dispositivi di automazione, o i PLC, sono gli slave. È stato originariamente progettato come protocollo di comunicazione per PLC e successivamente è diventato uno standard internazionale per il collegamento di più dispositivi industriali. Modbus è facile da implementare, economico e ampiamente accettato come standard di comunicazione. Esistono almeno tre varianti del protocollo Modbus: American Standard Code for Information Interchange (ASCII), unità terminale remota (RTU) e TCP/IP. ![](/files/-M7wfLK_THgh7aBuB23f) Esistono diversi scanner [Metasploit](/hacking/ot-ics-hacking/hacking-metasploit-scada-modules) che consentono il rilevamento e lo sfruttamento di Modbus e Profinet. Scanner simili in Python sono disponibili anche su GitHub. Nel 2011 Dillon Beresford, ingegnere senior per la ricerca delle vulnerabilità presso Dell, ha lanciato exploit remoti verso la serie di PLC Simatic di Siemens attravero Profinet, che comunica utilizzando la porta TCP 102. Ciò che è interessante di questi exploit è che scaricano e visualizzano la memoria, e sono in grado di effettuare comandi ON/OFF sull'unità centrale di elaborazione (CPU) del PLC. Un esempio è l'exploit chiamato "remote-memory-viewer", che esegue l'autenticazione utilizzando una password backdoor codificata nel PLC Simatic S7-300 di Siemens. In questo exploit, il modulo di avvio/arresto della CPU esegue il codice shell verso il PLC e lo accende/spegne da remoto. Lo stesso exploit start/stop può essere trovato per la serie S7-1200. Inoltre, iniettando shellcode, è anche possibile ottenere l'accesso remoto al PLC. A causa della mancanza di controlli di integrità, i PLC più vecchi eseguono comandi indipendentemente dal fatto che vengano ricevuti da una fonte legittima. La ragione di ciò è che non ci sono checksum sui pacchetti di rete. È stato dimostrato che una serie di attacchi replay funziona contro un gran numero di PLC, il che consente all'attaccante di inviare comandi di esecuzione in remoto. Pertanto, lo sfruttamento dei PLC in remoto con strumenti open source costituisce una grave minaccia per i sistemi SCADA. Durante il BlackHat USA nel 2011, Beresford ha presentato una demo live creata per le serie Siemens Simatic S7-300 e 1200. Gli exploit utilizzati durante la sua demo sono programmati in Ruby, reso compatibile con il Metasploit Framework. Gli exploit remoti su ICS erano una parte essenziale del worm Stuxnet. Tuttavia, Beresford ha dimostrato come sia possibile ottenere l'accesso remoto a un PLC utilizzando la password hardcoded integrata nel software, e per certi versi rappresenta un passo avanti rispetto a quanto fatto in Stuxnet. ## Ma succede solo con Siemens? Meglio precisarlo: questo non è esclusivamente un problema di Siemens. Rockwell Automation ha anche sperimentato un buffer overflow su stack che potrebbe consentire l'accesso remoto al sistema iniettando codice arbitrario, secondo [CVE-2016-0868](https://nvd.nist.gov/vuln/detail/CVE-2016-0868) del National Vulnerability Database. La vulnerabilità è stata segnalata il 26 gennaio 2016 e riguardava il PLC MicroLogix 1100. Inoltre, ci sono molti altri exploit e scanner disponibili nel progetto Metasploit che possono essere utilizzati per eseguire comandi da remoto su diversi modelli di PLC. Il computer di controllo può anche essere utilizzato come strumento di hacker principalmente a causa di vari exploit software, alcuni dei quali garantiscono il controllo della workstation di un sistema SCADA o ICS. Ciò consente all'attaccante di manipolare i dati inviati al PLC ed eseguire il pivoting all'interno della rete. Un exploit creato da James Fitts, collaboratore del Exploit Database, consente a un utente malintenzionato remoto di immettere codice arbitrario nel software di programmazione PLC di Fatek, WinProladder, come documentato [CVE-2016-8377](https://nvd.nist.gov/vuln/detail/CVE-2016-8377) del National Vulnerability Database. Anche se l'hacker può attivare l'exploit in remoto, quest'ultimo richiede comunque l'interazione dell'utente, come una visita a una pagina Web dannosa o l'apertura di un file infetto, per sfruttarlo correttamente. L'exploit è un buffer overflow su stack disponibile in Ruby per l'importazione di Metasploit. Le applicazioni programmate in C sono spesso più vulnerabili agli overflow del buffer rispetto ad altri linguaggi di programmazione e ci sono molti pacchetti software basati su C in uso nei sistemi di controllo industriale. Ad esempio, l'iniezione di shellcode attraverso una vulnerabilità di buffer overflow può consentire l'accesso remoto al sistema o essere utilizzato per l'escalation dei privilegi. ## Siamo spacciati? La mancanza di sicurezza nei sistemi di controllo industriale è una delle principali preoccupazioni per la sicurezza. Un PLC è stato originariamente progettato per funzionare solo come operatore automatico in un sistema di controllo industriale e non per essere collegato a componenti esterni e raggiungibile da Internet. Tuttavia, l'evoluzione nella progettazione di ICS ha iniziato a esporre i PLC a Internet, che può essere mostrato attraverso ricerche utilizzando strumenti come Shodan. I PLC si basano su reti con protezione "air-gapped" e accesso fisico limitato come misura di sicurezza. Le reti air-gapped hanno più volte dimostrato di essere un design imperfetto e non sono in alcun caso un legittimo argomento di sicurezza nei moderni ICS. Ciò è stato dimostrato dall'attacco di Stuxnet, che si è diffuso in oltre 115 paesi, infettando le infrastrutture critiche in tutto il mondo anche se la maggior parte dei sistemi di controllo sono stati progettati in isolamento. Questo cambiamento negli ambienti ICS e nelle infrastrutture critiche implica che i PLC sono esposti a una maggiore minaccia alla sicurezza rispetto a prima. *(Grazie al lavoro di Siv Hilde Houmb e Erik David Martin da cui è tratto questo articolo)* ## **Nota importante** Lo scopo di questo articolo è unicamente didattico e informativo. **Ogni azione non autorizzata** verso qualunque sistema di controllo presente su una rete pubblica o privata **è illegale**! Le informazioni contenute in questo ed altri articoli hanno lo scopo di far com‌prendere quanto sia necessario migliorare i sistemi di difesa, e non di fornire strumenti per effettuarne l'attacco. Violare un sistema informatico è perseguibile penalmente e può causare gravi danni a cose e persone, in modo particolare se si parla di ICS. Tutti i test che vengono illustrati nei tutorials sono stati effettuati in laboratori isolati, sicuri, o autorizzati dal produttore. Stay safe, stay free. # Hacking: attacco tipo Stuxnet a un PLC Modicon I ricercatori di [Airbus CyberSecurity](https://airbus-cyber-security.com/applying-a-stuxnet-type-attack-to-a-modicon-plc/) hanno recentemente dimostrato che gli hacker potrebbero lanciare un attacco in stile Stuxnet contro i controllori logici programmabili (PLC) Modicon di Schneider Electric, ma si ritiene che anche i prodotti di altri fornitori potrebbero essere vulnerabili allo stesso tipo di attacco. ## Come funziona Il famigerato malware [Stuxnet](https://blog.omarmorando.com/hacking/ot-ics-hacking/hacking-attaccare-un-plc-con-stuxnet), che gli Stati Uniti e Israele usavano per danneggiare il programma nucleare iraniano, è stato progettato per colpire i PLC SIMATIC S7-300 e S7-400 prodotti da Siemens. Stuxnet ha caricato codice dannoso su PLC mirati abusando del software STEP7 di Siemens, fornito dal colosso industriale tedesco per programmare i controller. ![](/files/-MBiqs-LMsw6oyvfUoVH) Come ho descritto nell'articolo precedente, Stuxnet ha sostituito una libreria denominata s7otbxdx.dll, che STEP7 utilizza per accedere a un PLC, con una versione dannosa usando un metodo chiamato "**reflective DLL loading**". Questa tecnica prevede di rinominare la DLL interessata (es. asmArm.dll) con un altro nome (es. asm\_Arm.dll) e di creare una seconda DLL con il nome di quella originale (asmArm.dll) che, a sua volta, richiama le funzioni della prima. Ciò ha consentito agli aggressori di iniettare il loro codice dannoso nel controller di destinazione. ![](/files/-MBiqwoYLzNanpS6FTeJ) I ricercatori di Airbus CyberSecurity hanno analizzato il PLC Modicon M340 di Schneider Electric per determinare se è vulnerabile ad attacchi simili. L'attacco ha preso di mira il controller tramite il software di ingegneria Schneider EcoStruxure Control Expert, precedentemente noto come Unity Pro. La loro analisi ha portato alla scoperta di una vulnerabilità che può essere sfruttata per caricare codice dannoso sui PLC Modicon M340 e M580 sostituendo uno dei file DLL associati al software di ingegneria, seguendo lo stesso schema di Stuxnet. ![](/files/-MBir4zGhXnPPwySq3FK) "Un simile attacco potrebbe avere gravi conseguenze, tra cui l'interruzione dei processi di produzione o altri tipi di danni", ha dichiarato Airbus CyberSecurity. "Ancora più interessante dal punto di vista IT, l'attaccante potrebbe trasformare il PLC in un proxy", hanno spiegato i ricercatori di Airbus. “Ciò gli consentirebbe di inviare richieste e comunicare con la rete a cui è collegato il PLC. Ad esempio, potrebbe accedere alla rete aziendale interna per rubare la proprietà intellettuale o lanciare attacchi per colpire altri sistemi connessi". "Il legittimo software di automazione sarebbe in esecuzione senza mostrare alcun segno della presenza di un programma dannoso. La parte malware invia periodicamente richieste a un server di comando e controllo gestito dall'aggressore via Internet", hanno spiegato. ## Come portare l'attacco Mentre un simile attacco potrebbe essere altamente dannoso o dirompente - o potrebbe dare un vantaggio all'attaccante - lo sfruttamento della vulnerabilità non è un compito facile. L'hacker deve prima ottenere l'accesso al perimetro ICS dell'organizzazione target ed essere in grado di comunicare con il PLC target. "Questa è già un'operazione molto significativa che probabilmente implica l'accesso privilegiato su un numero di macchine. Se gli aggressori hanno raggiunto questo punto, diverse misure di difesa di sicurezza non sono in atto o hanno fallito ”, hanno osservato i ricercatori di Airbus CyberSecurity. L'utente malintenzionato deve quindi scaricare il programma di automazione dal PLC. Questo può essere fatto da una stazione di ingegneria compromessa o se il PLC è accessibile a qualsiasi macchina sulla rete senza autenticazione. L'autore dell'attacco deve quindi ricompilare il programma di automazione utilizzando le tecniche descritte dai ricercatori Airbus e creare un programma dannoso da incorporare nel legittimo software di automazione. Infine, l'attaccante deve caricare il programma modificato sul PLC ed eseguirlo, ma ciò richiede l'arresto e l'avvio del software di automazione e gli esperti affermano che questa operazione potrebbe essere notata. ## Le soluzioni in atto La vulnerabilità scoperta dai ricercatori Airbus nei prodotti Schneider Electric viene indicata come [CVE-2020-7475](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7475) e classificata come severa. È stata patchata dalla società con un aggiornamento rapido per EcoStruxure Control Expert e aggiornamenti del firmware per i controller Modicon M340 e M580, come indicato in [questa nota](https://www.se.com/ww/en/download/document/SEVD-2020-080-01/). Schneider Electric e Airbus incoraggiano tutte le aziende clienti a implementare le migliori pratiche di cybersicurezza in tutte le loro operazioni nel tentativo di ridurre il rischio di attacchi. "Se necessario, ciò include la localizzazione di sistemi industriali e dispositivi accessibili in remoto dietro i firewall; installazione di controlli fisici per impedire accessi non autorizzati; impedire l'accesso a sistemi e dispositivi mission-critical da reti esterne; applicazione sistematica di patch di sicurezza e attivazione di software antivirus; e l'applicazione di soluzioni di whitelisting ", ha detto Schneider. ## **Nota importante** Lo scopo di questo articolo è unicamente didattico e informativo. **Ogni azione non autorizzata** verso qualunque sistema di controllo presente su una rete pubblica o privata **è illegale**! Le informazioni contenute in questo ed altri articoli hanno lo scopo di far com‌prendere quanto sia necessario migliorare i sistemi di difesa, e non di fornire strumenti per effettuarne l'attacco. Violare un sistema informatico è perseguibile penalmente e può causare gravi danni a cose e persone, in modo particolare se si parla di ICS. Tutti i test che vengono illustrati nei tutorials sono stati effettuati in laboratori isolati, sicuri, o autorizzati dal produttore. Stay safe, stay free. # Hacking: Pentest con un PLC ## Penetration Test con un PLC La protezione di un ambiente ICS, inclusi i PLC, non è banale, poiché questi sistemi non sono progettati per essere resistenti ad attacchi cyber. Ciò significa che bisogna in qualche modo integrare le misure di resilienza della cybersicurezza all'interno e intorno all'ICS. Tali misure includono, ad esempio: * la difesa perimetrale come i firewall per ridurre il rischio di traffico di rete indesiderato; * il monitoraggio della rete e preferibilmente di tipo non intrusivo, specifico per ICS, basato su anomalie in modo da non creare alcun carico aggiuntivo sulle reti ICS; * ultimo ma non meno importante, la protezione e il monitoraggio degli endpoint per ridurre l'esposizione dei PLC agli attacchi tramite connessioni remote. Ma un altro aspetto molto importante è identificare e comprendere i rischi. **Quali sono le superfici di attacco, i metodi attuati, le vulnerabilità e le potenziali conseguenze?** Inoltre, è importante valutare e rivalutare continuamente la probabilità di potenziali attacchi. ![](/files/-M8BdEJL23Vl5rqpCXQD) Un metodo per ottenere informazioni dettagliate sull'esposizione al rischio è il **test di penetrazione**, il cui l'obiettivo è identificare i vettori di attacco e simulare un vero e proprio attacco al sistema, controllato e consapevole. Tuttavia, i test di penetrazione in un ambiente ICS richiedono un approccio attento significativamente diverso rispetto alle tecniche di test di penetrazione standard per i sistemi IT. I sistemi ICS contengono apparecchiature delicate, come i PLC, dodate di un'unità di elaborazione sensibile, che può causare congelamenti, ripristini della configurazione e guasti se sollecitati a causa della bassa gestione dello stack. Test di penetrazione standard come una semplice scansione delle porte eseguita da strumenti come Nmap potrebbero essere sufficienti per sovraccaricare l'unità di elaborazione. A causa della debole gestione dello stack di rete, alcuni dispositivi non sono in grado di sopportare il numero di pacchetti di rete generati da Nmap e strumenti simili. Pertanto, è consigliabile non eseguire test di penetrazione in un ambiente ICS live, ma eseguirli solo in un ambiente di laboratorio controllato o durante fermi macchina programmati. Ci sono molte metodologie di test di penetrazione tra cui scegliere, anche se poche su misura per ICS. Una metodologia compatibile con ICS è la metodologia "**zero entry**" per i test di penetrazione. Essa comprende quattro fasi: **reconnaissance, scanning, exploitation e post-exploitation**. Il post-exploitation potrebbe comportare il mantenimento dell'accesso al sistema, che è ciò che fa un APT quando stabilisce un percorso per la comunicazione del centro di controllo e comando, che viene utilizzato per inviare informazioni di intelligence sul sistema di destinazione e per caricare nuovi exploit/malware. Inoltre, coprire le tracce per nascondere i passi dell'attacco rappresenta il ​​quinto step. La reconnaissance si concentra sulla raccolta di informazioni sulla destinazione, come ad esempio l'indirizzo IP e i record DNS (Domain Name System) e la lettura delle vulnerabilità comuni per i PLC di destinazione. Lo scanning prevede la scansione attiva del target alla ricerca di porte aperte, il rilevamento del sistema operativo e l'esecuzione dei servizi. Nmap, incluso Nmap Script Engine (NSE), è un esempio di uno strumento che viene spesso utilizzato per la scansione. Nel caso in cui venga rilevata una vulnerabilità, la fase di attacco passa all'exploitation. Nella maggior parte dei casi, tali vulnerabilità vengono utilizzate per ottenere l'accesso al sistema attraverso diversi servizi in esecuzione sul PLC. Dopo aver sfruttaSploitkitto la vulnerabilità, è preferibile rendere persistente l'accesso. Tuttavia, non tutti i servizi offrono l'opportunità di creare una backdoor persistente. Per molti PLC, è possibile estrarre dettagli sul sistema usando una scansione Nmap controllata verso il PLC stesso. Questo deve essere eseguito con cura per evitare di interromperne il funzionamento. Abbiamo una configurazione di laboratorio in cui eseguiamo test di penetrazione controllata su PLC e altre apparecchiature ICS, appartenenti a diversi produttori al fine di avere un campione rappresentativo di quanto presente sul mercato. In uno dei test di penetrazione la scansione Nmap con l'uso di script in Nmap Script Engine (NSE) ha rivelato l'indirizzo MAC, le informazioni hardware e firmware, le porte aperte 80, 102 e 443 e altro ancora. Queste informazioni dettagliate possono essere utilizzate per sviluppare exploit e indagare le vulnerabilità verso le serie PLC specifiche. ![](/files/-M8F70NOmUDnEV8VBqP7) Molte di queste vulnerabilità sono segnalate e discusse nel National Vulnerability Database. Sfruttando la loro presenza in molti casi è possibile decifrare la password e ottenere l'accesso al PLC (e spegnerlo). ## **Nota importante** Lo scopo di questo articolo è unicamente didattico e informativo. **Ogni azione non autorizzata** verso qualunque sistema di controllo presente su una rete pubblica o privata **è illegale**! Le informazioni contenute in questo ed altri articoli hanno lo scopo di far com‌prendere quanto sia necessario migliorare i sistemi di difesa, e non di fornire strumenti per effettuarne l'attacco. Violare un sistema informatico è perseguibile penalmente e può causare gravi danni a cose e persone, in modo particolare se si parla di ICS. Tutti i test che vengono illustrati nei tutorials sono stati effettuati in laboratori isolati, sicuri, o autorizzati dal produttore. Stay safe, stay free. # SCADAsploit Framework Questa sezione è dedicata a **SCADAsploit**, un framework su cui sto lavorando dedicato al penetration testing in ambito OT/ICS. Vi chiederete: "Ma non c'è già Metasploit che lo fa?". Certo! E allora che bisogno c'è di creare un nuovo tool del genere? Provo a dare qualche risposta: * framework esclusivamente dedicato alle vulnerabilità di SCADA, PLC e altri dispositivi ICS * scritto in Python, sia il core del framework sia i moduli aggiuntivi * interfaccia "Metasploit like" basata su [Sploitkit](https://pypi.org/project/sploitkit/) * focus maggiore su parco PLC installato, specialmente europeo * open source. Non so se questi punti siano sufficienti a dare maggior senso al progetto, per me è stato così. Volevo raccogliere in un unico ambiente gli scripts che comunemente vengono utilizzati durante i pentest in automazione, e casualmente ho intercettato Sploitkit. Metasploit attualmente conta quasi 70 moduli dedicati ai sistemi ICS, ma la maggior parter di essi sono per dispositivi praticamente inesistenti sul mercato italiano. Se consideriamo il parco dei PLC installato in Italia negli ultimi 20 anni, troviamo che Siemens + Schneider Electric ne fanno da padrone con quasi i 2/3 delle parti di mercato. Seguono Rockwell Automation (ex Allen-Bradley), GE, Omron soprattutto sulle macchine utensili, qualche Phoenix e Wago e poi pochi altri. Da qui è nata l'idea di SCADAsploit, un database di moduli ausiliari e di exploit dedicati ai principali produttori e protocolli di comunicazione, che faciliti le fasi di pentest. L'uso di Python lo rende probabilmente più accessibile anche a scopo didattico. ![](/files/-MAfWtorQeXd3wF-Wb6k) ## Principali moduli attualmente presenti Seguendo la stessa filosofia di approccio di Metasploit, anche in ScadaSploit troviamo due categorie di moduli: "auxiliary" ed "exploit". I moduli ausiliari sono dedicati ad operazioni di ricognizione, scanning, lettura/scrittura di dati ecc., mentre gli exploit basano il loro comportamento sullo sfruttamente di una vulnerabilità. In entrambe le categorie troviamo un'ulteriore suddivisione in funzione dei diversi produttori di PLC, che al momento si limitano a Schneider Electric e Siemens. ![](/files/-MAfXQzPK1JUC-pDc5-f) # Modulo: Modbus Scan Iniziamo a conoscere un po' meglio ScadaSploit partendo da uno dei moduli ausiliari presenti: **Modbus Scan**. Posizioniamoci nella cartella dove abbiamo installato ScadaSploit e avviamolo tramite il comando `$ ./scadasploit.py`. Seguendo la stessa filosofia di approccio di Metasploit, possiamo cercare tutti i moduli che contengono una parola chiave usando il comando `search ` oppure visualizzare l'elenco completo dei moduli presenti con il comando `show modules`. Nel nostro caso useremo `search modbus` per individuare i moduli di SCADAsploit che possono aiutarci durante il nostro lavoro di pentesting su una rete Modbus TCP. ![](/files/-MAfbnqt66nXaTw02HAd) L'elenco comprende sia i moduli ausiliari sia gli exploit, riconoscibili tramite la colonna "Path". Per il nostro primo test decidiamo di eseguire la scansione di una rete Modbus TCP, quindi selezioniamo il modulo **Modbus Scan** tramite il comando `use auxiliary/schneider/modbus_scan` e visualizziamo l'elenco dei parametri tramite il comando `show options`. Come possiamo notare il modulo appartiene alla categoria degli "auxiliary". ![](/files/-MAfcOAD5SzUuEEnmQUI) **Modbus Scan** è un modulo per la scansione di dispositivi connessi a una rete Modbus TCP. Può essere utilizzato per eseguire lo scanning di tutti i devices alla ricerca di informazioni sulla scheda di comunicazione, la versione del firmware, il MAC address. La scansione della rete può avvenire specificando l'indirizzo IP di un singolo dispositivo o un range di indirizzi usando la notazione CIDR (es. 10.43.10.0/23). In alternativa, è possibile inserire il nome di un file di testo che contiene l'elenco degli indirizzi IP degli hosts, seguendo un semplice formato che specifica l'indirizzo e l'eventuale porta non standard. ``` 10.43.10.100 10.40.11.58:5020 10.0.1.1/24 ``` Nel nostro caso facciamo lo scanning di un singolo device. ![](/files/-MAjRvLVtioh-1jQ-I5M) Ed ecco che in un attimo siamo in grado di riconoscere il nostro dispositivo, la versione del firmware installato e il MAC address, tutte informazioni utili per una successiva azione di exploit. ## PLC Schneider Modicon e UMAS I PLC della serie Schneider Modicon programmati con UnityPro e basati su Unity OS a partire dalla versione 2.6 utilizzano il protocollo **UMAS**. Si tratta di un protocollo a livello di kernel che prevede anche un livello di controllo amministrativo. La struttura di UMAS sfrutta quella del Modbus ed è un derivato del vecchio protocollo Xway utilizzato sin dalle prime serie di PLC Telemechanique. La caratteristica principale è che utilizza il codice funzione **90 (0x5a)** del protocollo Modbus per inviare e ricevere un set molto più ricco di informazioni. L'impacchettamento del payload è little-endian, il che può sembrare strano dal momento che Modbus è big-endian. Il pacchetto UMAS inizia con un campo a 16 bit che specifica un "UMAS Function Subcode", seguito da un numero variabile di byte che compongono il payload. ![](/files/-MBY7pqjX7g9h0leZj3w) Le richieste UMAS hanno quindi una struttura di questo tipo: ``` [TCP Packet] [Modbus Header] [5A] [UMAS CODE (16 bit)] [UMAS PAYLOAD (Variable)] ``` Tutte le risposte seguono invece questo schema: ``` [TCP Packet] [Modbus Header] [5A] [RETURN CODE (16 bit)] [UMAS PAYLOAD (Variable)] 0x01 0xFE - OK 0x01 0xFD - Error ``` Quando un PLC Schneider riceve un pacchetto Modbus controlla se il codice funzione è 0x5A e, in tal caso, utilizza alcune librerie specifiche per la gestione dell'estensione UMAS. Esistono diversi "UMAS codes" in grado di eseguire numerose operazioni sul PLC, di seguito ne elenco alcuni: | UMAS code | Function | Description | | --------- | ------------------------- | ------------------------------------------------------ | | 0x01 | INIT\_COMM | Initialize a UMAS communication | | 0x02 | READ\_ID | Request a PLC ID | | 0x03 | READ\_PROJECT\_INFO | Read Project Information | | 0x04 | READ\_PLC\_INFO | Get internal PLC Info | | 0x06 | READ\_CARD\_INFO | Get internal PLC SD-Card Info | | 0x0A | REPEAT | Sends back data sent to PLC (used for synchronization) | | 0x10 | TAKE\_PLC\_RESERVATION | Assign an owner to the PLC | | 0x11 | RELEASE\_PLC\_RESERVATION | Release the reservation of a PLC | | 0x12 | KEEP\_ALIVE | Keep alive message | | 0x20 | READ\_MEMORY\_BLOCK | Read a memory block of the PLC | | 0x22 | READ\_VARIABLES | Read system bits, system words and strategy variables | | 0x23 | WRITE\_VARIABLES | Write system bits, system words and strategy variables | | 0x24 | READ\_COILS\_REGISTERS | Read coils and holding registers from PLC | | 0x25 | WRITE\_COILS\_REGISTERS | Write coils and holding registers into PLC | | 0x30 | INITIALIZE\_UPLOAD | Initialize strategy upload (copy from PC to PLC) | | 0x31 | UPLOAD\_BLOCK | Upload a strategy block to the PLC | | 0x32 | END\_STRATEGY\_UPLOAD | Finish strategy upload | | 0x33 | INITIALIZE\_DOWNLOAD | Initialize strategy download (copy from PLC to PC) | | 0x34 | DOWNLOAD\_BLOCK | Download a strategy block from the PLC | | 0x35 | END\_STRATEGY\_DOWNLOAD | Finish strategy download | | 0x39 | READ\_ETH\_MASTER\_DATA | Read Ethernet master data | | 0x40 | START\_PLC | Starts the PLC | | 0x41 | STOP\_PLC | Stops the PLC | | 0x50 | MONITOR\_PLC | Monitors variables, systems bits and words | | 0x58 | CHECK\_PLC | Check PLC connection status | | 0x70 | READ\_IO\_OBJECT | Read IO Object | | 0x71 | WRITE\_IO\_OBJECT | Write IO Object | | 0x73 | GET\_STATUS\_MODULE | Get status module | ## Modbus Scan di SCADAsploit Il modulo **Modbus Scan** di SCADAsploit supporta l'estensione UMAS e questo ci permette di recuperare ulteriori dettagli quando abbiamo a che fare con un PLC programmato con UnityPro, come ad es. il nome del modulo CPU, il modello di scheda di memoria e alcuni dati sul file di progetto che è stato caricato. La natura del protocollo Modbus che non prevede alcuna autenticazione facilita il gathering delle informazioni. ![Scanning di un PLC Modicon M580](/files/-MAfZgH0haoEPIYhJLDW) Come possiamo vedere, oltre ai dati standard siamo in grado di raccogliere dettagli importanti anche sul progetto. Facendo un esempio pratico di come utilizzare queste informazioni, la data dell'ultima modifica ci fa capire da quando tempo il PLC è in funzione senza interventi di manutenzione al software. Questo può voler dire che potrebbe essere esposto a vulnerabilità note riscontrate in data successiva e che magari non sono state affrontate. ## **Nota importante** Lo scopo di questo articolo è unicamente didattico e informativo. **Ogni azione non autorizzata** verso qualunque sistema di controllo presente su una rete pubblica o privata **è illegale**! Le informazioni contenute in questo ed altri articoli hanno lo scopo di far comprendere quanto sia necessario migliorare i sistemi di difesa, e non di fornire strumenti per effettuarne l'attacco. Violare un sistema informatico è perseguibile penalmente e può causare gravi danni a cose e persone, in modo particolare se si parla di ICS. Tutti i test che vengono illustrati nei tutorials sono stati effettuati in laboratori isolati, sicuri, o autorizzati dal produttore. Stay safe, stay free. # Modulo: Modbus Payload Transfer Il secondo modulo che andiamo ad esplorare si chiama "**Modbus Payload Transfer**" e appartiene alla categoria degli auxiliary. ## A cosa serve Il modulo "**Modbus Payload Transfer**" è uno script che permette di memorizzare e recuperare un payload/shellcode negli "holding registers" di un PLC tramite il protocollo Modbus TCP. Esistono numerosissimi PLC esposti a Internet, con questo modulo è possibile sfruttare la loro memoria per fare un upload di un payload (shellcode/malware) in modo che possa essere recuperato in un secondo momento. Uno scenario di utilizzo potrebbe prevedere i seguenti steps: 1. Un attaccante individua un PLC esposto su Internet con spazio sufficiente per memorizzare un determinato payload. 2. L'attaccante carica il payload nella memoria del PLC. 3. L'attaccante infetta un host in grado di comunicare in Modbus TCP recuperando il payload dal PLC per poi eseguirlo. La stessa cosa ovviamente potrebbe avvenire anche con un PLC non esposto su Internet ma presente in una rete locale. I principali vantaggi di questo metodo sono: 1. L'uso di PLC di terze parti fornisce l'anonimato e rende difficile la tracciabilità. Non è necessario caricare il payload su un server. 2. Il payload è archiviato nella memoria del PLC, rendendo difficile l'analisi forense. Inoltre, una volta recuperato il payload il suo contenuto potrebbe essere sovrascritto facilmente (anche dall'host stesso). Questo approccio potrebbe essere utile anche in alcuni ambienti ICS in cui protocolli diversi da Modbus potrebbero mettere in allerta sistemi IDS/IPS. In un contesto di questo tipo hai solo bisogno di un device Modbus o anche semplicemente di un emulatore che può fungere da server quando il target host si connette ad esso. Esistono poi dei PLC direttamente esposti in Internet e gestiti da remoto che possono diventare un buon posto dove despositare un payload/malware. **Nota importante**: non eseguire nessuna di queste azioni su PLC di terze parti. Qualsiasi scrittura sui registri dei PLC può interrompere la strategia di controllo del processo per cui è stata programmata. ## Come funziona Per prima cosa possiamo cercare il modulo interessato usando il comando `search modbus`, che presenterà l'elenco dei moduli ausiliari e gli exploits che fanno uso di questo protocollo. Una volta individuato ciò che cerchiamo lo selezioniamo col comando `use auxiliary/modbus/modbus_payload_transfer`. Il comando `show info` ci fornisce alcuni dettagli sul funzionamento del modulo. ![](/files/-MBncQ14GIsxrLGLmfKE) A questo punto passiamo a configurare il modulo. Il comando `show options` visualizza la lista dei parametri, in questo caso troviamo: * ADDRESS: indirizzo di partenza dell'holding register per l'upload/download del payload * FILENAME: il nostro file contenente il payload (si raccomandano dimensioni di qualche Kb) * MODE: per selezionare se eseguire un upload o un download dal PLC * NBYTES: il numero di bytes che dobbiamo scaricare durante un download (non necessario per l'upload) * RHOST ed RPORT per impostare l'indirizzo IP e la porta TCP del nostro PLC ![](/files/-MBncpwsPqQC_t8ms0My) Quando abbiamo configurato correttamente la lista dei parametri non ci resta che eseguire il nostro modulo ausiliario, usando il comando `run`. In questo caso stiamo eseguendo un upload di un file chiamato `payload.bin` della dimensione di 300 bytes, su un PLC con indirizzo 10.43.10.58 a partire dall'holding register 200. ![](/files/-MBnbkYJMTk4w37arbsK) Per la caratteristica del protocollo Modbus il file viene suddiviso in pacchetti da 250 bytes. Se il payload ha un numero dispari di byte verrà aggiunto un carattere "0x90" per evitare problemi durante il recupero. A seconda del tipo di PLC in uso avremo a disposizione una quantità maggiore o minore di memoria accessibile, pertanto lo script verificherà prima che vi sia spazio sufficiente per il payload. Per verificare le dimensioni viene inviata una richiesta Modbus con un ID operazione 03 (Read Holding Register), tentando di leggere un determinato record a partire dall'indirizzo che abbiamo impostato come parametro (ogni record è di 16 bit). Se si ottiene un'eccezione 0x83 significa che il PLC non è in grado di contenere il nostro payload e l'operazione fallisce. > Il recupero del payload avviene usando lo stesso modulo "**Modbus Payload Transfer**", andando semplicemente a selezionare la modalità MODE = DOWN e la quantità di bytes che dobbiamo scaricare tramite il parametro NBYTES. > > Anche in questo caso il download avviene a blocchi di 250 bytes (125 holding registers) per volta. Il file viene poi ricomposto e salvato integralmente. ## Attenzione alla perdita dei dati Oltre a utilizzare lo script per caricare un determinato payload come ad esempio un malware o una shellcode, è ovvio che può essere utilizzato anche per caricare qualsiasi tipo di file di dimensioni contenute. Penso che sia un modo interessante per esfiltrare e condividere informazioni. Chi sospetterebbe che gli holding registers di un determinato PLC memorizzino un file .docx o .zip? È importante notare che gli holding registers in cui viene caricato il payload possono essere modificati dal PLC stesso. Dato che non conosciamo la gestione della memoria e la strategia di controllo del processo è probabile che dobbiamo cercare un intervallo di memoria che non sia suscettibile di modifiche. L'idea potrebbe essere quella di caricare il payload in una determinata sezione dei registri e quindi verificare, per qualche tempo, che il payload non subisca alcuna modifica. ## **Nota importante** Lo scopo di questo articolo è unicamente didattico e informativo. **Ogni azione non autorizzata** verso qualunque sistema di controllo presente su una rete pubblica o privata **è illegale**! Le informazioni contenute in questo ed altri articoli hanno lo scopo di far comprendere quanto sia necessario migliorare i sistemi di difesa, e non di fornire strumenti per effettuarne l'attacco. Violare un sistema informatico è perseguibile penalmente e può causare gravi danni a cose e persone, in modo particolare se si parla di ICS. Tutti i test che vengono illustrati nei tutorials sono stati effettuati in laboratori isolati, sicuri, o autorizzati dal produttore. Stay safe, stay free.