Nozomi Network Labs individua vulnerabilità nei PLC di sicurezza Mitsubishi

Nozomi Networks Labs ha identificato una serie di vulnerabilità sui PLC di sicurezza di Mitsubishi e  GX Works3. Nello specifico, sono stati rilevati alcuni problemi nel protocollo di autenticazione MELSOFT. Se singolarmente nessuno di questi bug consente a un attaccante di violare i sistemi, concatenandoli potrebbe prendere il controllo dell'intero sistema.

Le vulnerabilità del protocollo MELSOFT

I ricercatori di Nozomi Labs hanno analizzato il protocollo di comunicazione MELSOFT, al quale si appoggiano i PLC di sicurezza Mitsubishi e GX Works3, alla ricerca di possibili bug. L'analisi si è incentrata sull'implementazione dell'autenticazione, dato che già altri sistemi OT di altri produttori soffrivano di simili problemi. 

Nello specifico, si sono concentrati su due tipi di minaccia: uno più limitato, dove l'attaccante è solo in grado di scambiare pacchetti con il PLC di destinazione, a uno più evoluto, dove è in grado di intercettare l'intero traffico di rete fra la workstation e il PLC.

La prima vulnerabilità è dovuta al fatto che quando un utente si connette sulla porta TCP 5007, viene inviato in chiaro il nome utente e, in caso di match (l'utente è presente nel database) viene inviato un pacchetto dati che contiene anche la password in chiaro. Uno scenario che consente a un attaccante di eseguire un attacco di tipo brute-force sul nome degli utenti per ottenere la password. Fortunatamente, però, è presente un sistema anti-brute-force, in grado di rilevare questo tipo di attacchi. Un sistema implementato in maniera un po' rozza, però, dato che non si limita a bloccare l'IP da cui proviene l'attacco, ma per un lasso di tempo impedisce a chiunque di autenticarsi.

In pratica, un attaccante può bloccare l'accesso al sistema senza fatica né competenze tecniche. 

Un altro problema è che in seguito a un’autenticazione viene generato un token di sessione che viene trasmesso in chiaro. Questo token non è però legato a un indirizzo IP, né viene invalidato una volta che l’applicazione EWS viene chiusa: questo significa che 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.