È recente la notizia della divulgazione di NUCLEUS:13, una suite di ben tredici vulnerabilità scoperte nel sistema operativo real-time Nucleus RTOS del gigante Siemens, alla base di numerosissimi dispositivi e sistemi embedded utilizzati nei settori medico, aerospaziale, automobilistico, IoT e in generale (ma non solo) nel mondo industriale.
Il set di vulnerabilità NUCLEUS:13 inficia lo stack TCP/IP di RTOS e potenzialmente può essere sfruttato da un attacker per avviare l’esecuzione da remoto di comandi arbitrari su dispositivi vulnerabili, generare le condizioni per un DDoS e/o per ottenere informazioni industriali riservate (riservate perché vitali, non mi riferisco solo a brevetti).
Indice degli argomenti
I dettagli delle vulnerabilità NUCLEUS:13
Le vulnerabilità sono state scoperte da ricercatori delle società Forescout e Medigate, aziende attive nel campo della ricerca e sviluppo di soluzioni di sicurezza informatica per il mondo IoT.
Il bollettino di sicurezza è l’ultima parte di una più ampia iniziativa di Forescout che ha coinvolto anche università e istituti di ricerca per analizzare congiuntamente la sicurezza (non solo la cyber security, ma anche l’impatto che questa può innegabilmente avere sulla safety) di più stack TCP/IP.
Una dozzina delle vulnerabilità di NUCLEUS13 hanno ricevuto valutazioni di gravità media e alta, di cui tre che consentono l’esecuzione del codice remoto: CVE- 2021-31886, CVE-2021-31887 e CVE-2021- 31888.
Tutte le vulnerabilità indicate in questi tre CVE coinvolgono l’FTP server predefinito fornito con lo stack TCP/IP di Nucleus RTOS, ma quella che si è distinta sulle altre è la vulnerabilità descritta in CVE-2021-31886, che si basa sulla mancata gestione delle dimensioni dell’input utente (parametro in ingresso al servizio nel momento in cui il client si autentica) passato al comando ftp “USER”.
Per sfruttare CVE-2021-31886, l’attacker effettuerà un tentativo di autenticazione al server FTP target, inviando sulla shell il comando “USER” al daemon, ma diversamente da una normale sessione di autenticazione, l’attacker passerà al posto dell’username una stringa confezionata ad arte, con una lunghezza maggiore del buffer interno pensato originariamente dai progettisti del firmware RTOS.
A seguito dell’invio della stringa (in cui all’interno avrà incapsulato anche lo shellcode) avvenuto con successo, l’attacker provocherà uno stack-overflow nella memoria del processo di autenticazione, consentendogli di scrivere nella memoria del processo e provocando l’hijacking del flusso di esecuzione, consentendogli quindi di eseguire codice a sua discrezione.
(Fonte: forescout.com).
Visionando il codice contenuto all’interno della funzione FSP_Server_USER nello screenshot di sopra, chi si occupa di Secure Code Review ed è pratico di “bounds checking” e dei suoi abusi, noterà velocemente dove si annidano le chiamate insicure (o meglio, dove e come sono utilizzate funzioni insicure per gestire i parametri in ingresso), le medesime chiamate su cui poi i ricercatori di Forescout hanno lavorato e hanno sfruttato per realizzare l’exploit funzionale alla loro ricerca, i cui dettagli sono disponibili a questo URL (è una lettura per addetti ai lavori).
Come vengono abusate le vulnerabilità NUCLEUS:13
È formativo e interessante dedicare qualche minuto per visionare questo video di Stanislav Dashevskyi, uno dei ricercatori Forescout: ci mostra – modellini di impianti ospedalieri e di reti ferroviarie alla mano – in che modo un attacker possa abusare facilmente delle vulnerabilità descritte da NUCLEUS13.
L’auspicio, ovviamente, è che nelle reti ospedaliere italiane, diversamente da quanto invece Dashevskyi ipotizza nel video, non sia possibile ad un utente non autorizzato né censito (ossia anche ad un eventuale attacker) collegarsi velocemente alle LAN da un qualunque switch ospedaliero semplicemente inserendo un cavo di rete in una porta libera per manomettere PLC, sistemi HVAC (un insieme di sistemi, strumentazioni macchine e tecnologie utilizzate per fornire ad ambienti industriali e non il riscaldamento, il raffreddamento, la ventilazione e l’aria condizionata a edifici di diverse tipologie e dimensioni), e perfino i sistemi di allarme e sistemi di rilevamento in taluni impianti ferroviarie.
È bene sottolineare che le tecnologie e le soluzioni per prevenire questi scenari preoccupanti ci sono da anni e passano attraverso la segmentazione, l’adozione di VLAN e l’utilizzo di protocolli di autenticazione come l’802.1X: tutti strumenti che non richiedono neanche chissà quali investimenti in termini di budget e forniture hardware.
NUCLEUS13 ci ricorda una verità che a volte taluni dimenticano: per quanto sicuro un vendor possa dichiarare un prodotto o un sistema, per quanto un benchmark o un blog possano dichiarare “sicuro” il tal o tal altro sistema IoT, il tal o tal altro appliance, se un sistema è digitale ed è dotato di interfacce di rete (ethernet o wireless) girerà su di un sistema operativo di base, magari dotato anche di CLI.
Considerazioni finali
Ecco quindi che, al di là delle best practice e delle mitigazioni suggerite dai ricercatori per arginare in questo caso la problematica (problematica che, ricordo, può impattare innumerevoli device e sistemi IoT che montano le esatte versioni di Nucleus RTOS citate nell’analisi tecnica di Forescout), e che possiamo consultare sul portale Forsecount piuttosto che sul portale Siemens, le vulnerabilità evidenziate in NUCLEUS:13 ci ricordano un leitmotiv della cyber security: un appliance, un servizio, un device IoT, un programma o un processo in real-time non sono sicuri perché il vendor stesso o un commerciale di un distributore li “vende” come sicuri o perché l’azienda cliente ha affidato l’analisi del traffico di rete di quel device o di quel servizio a un SOC (Security Operation Center).
Invece sono/saranno verosimilmente sicuri e a prova di un buon numero di attacchi informatici se sono stati o saranno progettati/ingegnerizzati in maniera sicura (seguendo tecniche di “secure by design”, ad esempio, ma non solo).
Gli IDS, gli IPS, i SIEM, gli antimalware, gli EDS e tutto il rimanente armamentario a disposizione di un Blue team non potranno mai anteporsi in toto alla buona progettazione.
È la buona progettazione che dovrebbe essere la priorità, è l’ingegneria della Sicurezza Informatica che è in grado di vincere in gran parte già con i suoi metodi, con le sue architetture e con i suoi modelli scientifici le sfide della sicurezza della complessità computazionale del futuro che ci attende, ma anche del nostro presente.
Nel nostro sistema di Asset Management, sono già censiti tutti gli apparati basati su Nucleus RTOS? E se lo sono, le versioni attualmente in produzione, sono mica le analoghe versioni segnalate nelle ricerche e nei CSV di Forescout?
