Alla fine del 2020, Nozomi Networks Labs ha iniziato un progetto di ricerca su MELSOFT, il protocollo di comunicazione utilizzato dai PLC di sicurezza Mitsubishi e GX Works3, il software corrispondente delle workstation di progettazione. Abbiamo focalizzato la nostra analisi specificamente sull’implementazione dell’autenticazione poiché abbiamo notato che prodotti OT simili di altri fornitori contengono vulnerabilità in questa superficie di attacco.
Oltre a rivelare a Mitsubishi le vulnerabilità, abbiamo condiviso proattivamente i PoC e tutti i dettagli tecnici della nostra ricerca affinché l’azienda potesse elaborare una strategia risolutiva[1].
Come forse già sapete, gli aggiornamenti per prodotti come i PLC di sicurezza o i dispositivi medici richiedono più tempo per essere distribuiti rispetto ad altri software perché, oltre a sviluppare e testare la patch, i vendor sono tenuti a rispettare processi di certificazione specifici. A seconda del tipo di dispositivo e del quadro normativo, potrebbe essere necessaria la procedura di certificazione per ogni singolo aggiornamento.
Mentre aspettavamo che il processo di sviluppo e distribuzione della patch fosse completato, abbiamo distribuito la logica di rilevamento ai clienti del nostro servizio di Threat Intelligence e iniziato la ricerca di strategie di rilevamento più generali da condividere con la comunità di sicurezza ICS.
È probabile che i problemi rilevati influenzino l’autenticazione dei protocolli OT di più di un singolo fornitore, e desideriamo aiutare a proteggere quanti più sistemi possibile. La nostra preoccupazione è che i clienti possano fare troppo affidamento sulla sicurezza degli schemi di autenticazione propri dei protocolli OT, senza conoscere i dettagli tecnici e i modelli di failure di queste implementazioni.
Descrizione delle vulnerabilità di autenticazione di Mitsubishi MELSOFT
Modelli di minaccia
In questa ricerca abbiamo considerato due modelli di minaccia. Nel primo, l’attaccante è limitato e può solo scambiare pacchetti con il PLC di destinazione. Nel secondo, oltre allo scambio di pacchetti, è anche in grado di effettuare lo sniffing del traffico di rete tra la stazione di lavoro (EWS) e il PLC di destinazione.
Panoramica sull’autenticazione MELSOFT
Abbiamo analizzato MELSOFT sulla porta TCP 5007. L’autenticazione è implementata con una coppia nome utente/password. In questo schema, l’EWS invia prima un pacchetto contenente il nome utente in chiaro e riceve una risposta dal PLC che conferma se il nome sia valido. In caso affermativo, l’EWS invia un secondo pacchetto contenente un hash generato da un insieme di elementi, uno di questi è la password in chiaro.
Segue una descrizione di alto livello delle vulnerabilità che abbiamo scoperto.
Brute-force del nome utente
Per quanto ne sappiamo, l’esposizione del nome utente in chiaro via cavo è stata affrontata con una serie di mitigazioni[2]. Abbiamo invece cercato di capire se la lista dei nomi utente validi potesse essere rivelata attraverso tecniche brute-force. Per verificare la nostra ipotesi, abbiamo implementato un PoC, e il risultato è che gli username sono effettivamente brute-forceable. Il fattore limitante per un attaccante è la lunghezza massima per un nome utente, che è di 20 caratteri.
La funzionalità anti-password brute-force porta a un meccanismo di blocco dell’account eccessivamente restrittivo.
Una volta implementate le primitive di MELSOFT per eseguire un’autenticazione di successo, abbiamo esteso il nostro PoC iniziale con un forzatore di password che, dato un utente valido, prova ripetutamente una combinazione di password fino a trovare quella corretta. Fortunatamente, in questo caso, c’è un meccanismo anti-brute-force che blocca efficacemente un attaccante.
Tuttavia, l’implementazione del meccanismo è eccessivamente restrittiva. Non blocca solo un potenziale aggressore che usa un singolo IP, ma qualunque utente da qualsiasi IP per un certo periodo di tempo.
La conseguenza di questo design è che se un attaccante invia un numero limitato di password al PLC, sufficiente ad attivare la protezione anti-brute-force, tutti gli utenti con credenziali legittime sono effettivamente bloccati dall’autenticazione. Se un attacco di questo tipo è in corso, il proprietario della risorsa ha due opzioni:
- Bloccare i pacchetti password brute-force dal raggiungere il PLC e aspettare che la finestra temporale scada prima di autenticarsi
- Riavviare fisicamente il dispositivo e autenticarsi immediatamente dopo che il processo di riavvio è stato completato
Fughe di segreti equivalenti alle password
Abbiamo trovato due casi in cui un segreto derivato dalla password in chiaro è trapelato in un pacchetto. Un attaccante in grado di leggere tale pacchetto potrà usarlo per autenticarsi con il PLC. A causa del modo in cui l’autenticazione è implementata, questo segreto è funzionalmente equivalente alla password in chiaro. Abbiamo implementato un PoC che esegue un’autenticazione con questo segreto, invece di usare la password in chiaro.
Gestione dei gettoni di sessione
Dopo che un’autenticazione con un nome utente/password corretto è stata completata, viene generato un token di sessione che viene trasmesso in chiaro via wire. Il problema principale della gestione della sessione di MELSOFT è che questo token non è legato a un indirizzo IP, né viene invalidato una volta che l’applicazione EWS viene chiusa. Un attaccante in grado di leggere un singolo comando privilegiato contenente un token di sessione può quindi riutilizzarlo da un altro IP dopo che è stato generato, in una finestra di poche ore.
Ideare uno scenario d’attacco concatenando più vulnerabilità
Se concateniamo alcune delle vulnerabilità identificate, emergono diversi scenari di attacco. È importante capire questo approccio perché gli attacchi del mondo reale sono spesso eseguiti sfruttando diverse vulnerabilità per raggiungere l’obiettivo finale.
In questo caso, un attaccante può iniziare registrando un singolo pacchetto che contiene il token per una sessione autenticata di un amministratore PLC, scegliendo il momento in cui ritiene ci siano minori possibilità di essere notati. L’attaccante chiederà poi al PLC la lista degli utenti registrati che conterrà anche il segreto equivalente alla password per ognuno di essi. Una volta che questi segreti sono stati ottenuti, non c’è bisogno di fare affidamento sul token di sessione, che dura solo poche ore.
La fase successiva può quindi avvenire quando si avrà la possibilità di avere l’impatto maggiore. L’attaccante può accedere con credenziali reali e cambiare la logica del PLC di sicurezza per poi iniziare un attacco brute-force alla password per bloccare tutti fuori dal PLC. Quando gli ingegneri cercheranno di riottenere l’accesso attraverso la workstation di ingegneria, non saranno in grado di farlo a meno che non riescano a impedire ai pacchetti di password brute-force di raggiungere il PLC.
Infine, se l’attaccante cambia le password degli utenti registrati, non c’è altra scelta che spegnere fisicamente il PLC per prevenire potenziali danni.
[1] https://www.mitsubishielectric.com/en/psirt/vulnerability/index.html
[2] https://us-cert.cisa.gov/ics/advisories/icsa-20-175-01
