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 è 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.

Schneider Electric all’interno del proprio vasto catalogo conta anche una gamma di PLC dedicati all’automazione degli edifici.

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

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 <IP_address> -l admin

Dopo che ci siamo connessi il server ci chiederà una password. Utilizziamo la password predefinita “admin”.

A questo punto siamo all’interno dell’account amministratore di Automation Server. Possiamo digitare help per vedere quali comandi possiamo usare con questo account.

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.

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

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

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

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.

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.

root:> cd /etc
root:> ls -l

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

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.

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.