Inverter solari IoT e vulnerabilità Trickle-Down

3 settembre 2019, di Jos Wetzels, Consulente Principale di Sicurezza di Bureau Veritas Cybersecurity

Omniksol

Omnik è un produttore cinese-tedesco di inverter e accessori per il fotovoltaico (PV) molto diffuso nei Paesi Bassi, in Germania e in Belgio.

Gli inverter Omnik dispongono di due porte RJ-45 attraverso le quali è possibile collegare in serie fino a 50 inverter, per consentire la configurazione e il trasferimento dei dati tramite RS-485. Inoltre, sono disponibili moduli di connettività Wi-Fi e GPRS come schede interne o kit esterni (collegati all'inverter tramite RS-485) per il monitoraggio remoto dello stato, il datalogging e la configurazione di un'intera cascata di inverter.

Tenga presente che questi sono solo gli account pubblici e solo quelli visibili nel portale Omnik. Altri marchi che rivendono la soluzione SolarMAN potrebbero utilizzare i propri portali.

Oltre alla mappa di cui sopra degli utenti di kit Wi-Fi, possiamo trovarne decine esposti pubblicamente su Internet utilizzando i motori di ricerca Shodan e Censys:

Il kit Wi-Fi SolarMAN / iGEN

Bene, diamo un'occhiata più da vicino al kit Wi-Fi. La prima cosa da notare è che l'AP aperto è l'opzione predefinita. Sebbene la configurazione consenta di 'nascondere' l'AP, di impostare la crittografia WEP / WPAPSK / WPA2PSK e di modificare il nome utente e la password del server web, non richiede all'utente finale di farlo e quindi il dispositivo sembra tipicamente distribuito in modo insicuro fuori dalla scatola. Inoltre, se l'AP aperto viene utilizzato solo per la configurazione iniziale del dispositivo, non viene disattivato in seguito, lasciandolo aperto su molti dispositivi 'setup and forget'.

Quindi, cosa possiamo fare con l'accesso all'AP? Beh, prima di tutto ci permette di interagire con gli inverter fotovoltaici tramite varie interfacce, di cui parleremo più avanti. In secondo luogo, il kit Wi-Fi deve essere in grado di connettersi a Internet per comunicare con il backend del cloud SolarMAN, che raccoglie i dati dell'inverter e li mette a disposizione dell'utente tramite un'app mobile. Per questo motivo, il kit è collegato a una rete interna tramite un cavo Ethernet o un AP Wi-Fi (per il quale è necessario inserire l'SSID e le credenziali nell'interfaccia di configurazione web). Oltre al fatto che questo significa affidare al backend del cloud sia i dati del suo inverter fotovoltaico che potenzialmente le sue credenziali Wi-Fi personali, significa anche che l'AP del kit funge ora da punto di accesso alla sua rete privata. Un rischio che riguarda molti dispositivi IoT.

Per avere un'idea più precisa della posizione di sicurezza del kit, ho deciso di dare un'occhiata ai suoi vari servizi. Una rapida scansione nmap rivela che l'indirizzo MAC corrisponde a Drogoo Tecnologia Co. con sede a Shenzhen e che sono esposti i seguenti servizi:

* 53/UDP, DNS
* 80/TCP, HTTP
* 8899/TCP, Info Datalogger
* 48899/UDP, interfaccia HF AT

Interfaccia web (80/TCP)
Sulla porta 80 troviamo un server web che, dopo aver superato una richiesta di autenticazione di base HTTP, fornisce un'interfaccia di configurazione che supporta le tipiche opzioni di configurazione (impostazioni per la rete wireless e via cavo, datalogger, server cloud, comunicazioni seriali), oltre alla possibilità di modificare il nome utente e la password dell'interfaccia web e di aggiornare i firmware del kit Wi-Fi e dell'inverter.

Info Datalogger (8899/TCP)
Il servizio su questa porta è utilizzato per le comunicazioni con il datalogger, per il quale esistono diversi script open-source della comunità, ma dal punto di vista della sicurezza questo servizio non è terribilmente interessante, quindi ho deciso di non indagare ulteriormente.

Interfaccia HF AT (48899/UDP)
Supponiamo che l'utente finale abbia configurato una password forte per l'interfaccia web e che non si voglia seguire la strada dell'exploit della corruzione della memoria in nessuno dei servizi esposti. In questo caso, questa interfaccia, che ho chiamato 'interfaccia HF AT' (per motivi che saranno chiari in seguito), sembra la nostra migliore possibilità.

L'interfaccia viene utilizzata per la scoperta della rete, rispondendo con informazioni identificative a specifici messaggi broadcast UDP contenenti la stringa "WIFIKIT-214028-READ", come si può vedere durante il reverse engineering dell'applicazione mobile SolarMAN:

L'ID FCC sembra appartenere al modulo Wi-Fi incorporato HF-A11 prodotto da Shanghai Hi-Flying Tecnologia. La presenza di questo modulo, che si basa sull'architettura MIPS ed esegue l'RTOS eCos, può essere osservata sul PCB del kit dopo aver aperto l'involucro:

Inoltre, una rapida analisi del firmware del kit conferma che esegue eCos su MIPS e mostra le stringhe Hi-Flying e HF-A11:

Hi-Flying

Shanghai High-Flying Electronics Tecnologia Co., Ltd è un produttore di prodotti di comunicazione wireless e un fornitore di servizi cloud che produce vari moduli e dispositivi IoT. Questi moduli e dispositivi sono venduti anche da altri venditori, come USR IOT, e sono adottati da vari ODM e OEM IoT a basso costo in un'ampia varietà di prodotti che vanno dalle lampadine intelligenti, come la nota MiLight, alle spine elettriche intelligenti, alle webcam, alle macchine per il caffè e agli allarmi di sicurezza, fino alle RTU industriali, ai convertitori seriali-eternet, ai gateway e ai data logger degli inverter solari, tutti nuovamente ribrandizzati da reti di nomi di aziende.

Una diapositiva di una presentazione del profilo aziendale di Hi-Flying mostra alcuni importanti clienti internazionali (tra cui Omnik) e un ampio portafoglio di moduli:

Questi moduli sono in genere costituiti da un chip di comunicazione wireless off-the-shelf (ad esempio MediaTek MT5931) in bundle con un RTOS (ad esempio eCos, FreeRTOS, Contiki, ARM mbed) o Linux, diverse librerie di comunicazione e di rete, server web, ftp e telnet incorporati e funzionalità proprietarie di individuazione della rete, configurazione remota e aggiornamento firmware OTA. I moduli hanno la capacità di funzionare come punto di accesso (AP) e/o stazione (STA) e possono interagire con un'interfaccia di comando UART AT.

Sembra che esistano due diversi protocolli di configurazione / OTA, entrambi dotati di un'interfaccia sulla porta 48899/UDP:

* Interfaccia AT HF (alternativamente denominata SmartConfigure Smart Link), utilizzata dai moduli delle serie HF-A, HF-LPT, HF-LPB, ecc.
* IOTService / IOTManager, utilizzato dai moduli delle serie Eport e Wport.

Inoltre, alcuni moduli (come HF-LPB125 e HF-LPT330) supportano WeChat AirKiss che, come documentato nella guida Espressif ESP-TOUCH, è essenzialmente un'interfaccia a canale nascosto per configurare le impostazioni Wi-Fi su dispositivi embedded che non dispongono di altre interfacce. Ciò avviene facendo in modo che il dispositivo si avvii in modalità di acquisizione dei pacchetti e che l'app AirKiss invii una serie di pacchetti UDP all'AP Wi-Fi, codificando l'SSID e la password nei campi di lunghezza del pacchetto. Poiché il campo di lunghezza non è crittografato, il nodo in ascolto può analizzare l'SSID e la password e unirsi alla rete Wi-Fi, dopodiché può iniziare la configurazione. Anche se in genere AirKiss è attivo solo durante la configurazione iniziale, l'approccio è fondamentalmente un rischio per la sicurezza.

Interfaccia AT HF / SmartConfigure Smart Link

Anziché essere utilizzato semplicemente per la scoperta della rete, questo servizio espone effettivamente l'interfaccia AT del modulo tramite UDP e funziona nel modo seguente:

* Scansiona la rete con una stringa di trasmissione UDP sulla porta 48899.
* I nodi risponderanno con IP,MAC,MID
* Risponde con "+ok", il nodo entra in modalità AT
* Possiamo ora eseguire comandi AT arbitrari.
* Mantenere un nodo in modalità comando inviando AT+W a intervalli di 1 minuto; il nodo non accetterà altre richieste di connessione per 1 minuto.
* Inviare AT+Q per uscire dalla modalità di comando AT.

L'interfaccia AT consente di accedere a vari tipi di funzionalità sensibili, come ad esempio:

* Aggiornamento del firmware
* Ottenere / Impostare i dati di configurazione Wi-Fi (comprese le chiavi)
* Ottenere/impostare le credenziali del servizio (ad esempio, il server web).
* Ottenere / Impostare la configurazione 'utente' (informazioni specifiche del dispositivo)
* Impostazione dello stato dei pin GPIO
* Navigazione verso URL in modo simile al proxy

Inoltre, gli OEM possono aggiungere comandi specifici del dispositivo (come l'aggiornamento del firmware per i moduli o i dispositivi collegati al modulo Wi-Fi, come l'inverter fotovoltaico nel caso del kit SolarMAN).

L'unica protezione per questo servizio è una 'password' che funge da stringa di scoperta della rete. La password è codificata nel firmware e non può essere modificata; inoltre, poiché fa parte del protocollo di scoperta, non può essere considerata riservata. Per impostazione predefinita, la password è 'HF-A11ASSISTHREAD'.

In alcuni casi (ad esempio, i kit e le schede WiFi Omniksol) gli OEM hanno modificato questa password, ma ciò non aggiunge molta sicurezza, in quanto basta che un aggressore ottenga un'immagine del firmware del dispositivo, un'applicazione mobile o un gateway di integrazione per estrarre la password. Gli OEM possono cambiare la password nelle nuove versioni del firmware, ma questo romperebbe la compatibilità con alcune applicazioni e strumenti che utilizzano l'interfaccia per la scoperta del dispositivo e l'aggressore può semplicemente ripetere il trucco.

L'estrazione della password AT per un'immagine firmware di un dispositivo basato su HF è semplice e comporta la decompressione del firmware (estrazione del blob compresso LZMA dall'immagine U-boot) e il recupero della password hardcoded dall'immagine decompressa. Questo può essere fatto in modo 'intelligente' (caricandolo in IDA, identificando la funzione di autenticazione dell'interfaccia AT con una firma FLIRT e trovando il riferimento alla password) o in modo semplice, sfruttando il fatto che per le immagini basate su eCos la password è sempre inserita tra le stesse due stringhe:

Pertanto, il seguente oneliner è sufficiente per ottenere la password AT da un'immagine firmware basata su HF eCos:

Per le immagini basate su FreeRTOS, Contiki o mbed, il seguente schema sembra arrivare dopo la password:

Il che ci dà l'oneliner:

Come risulta, i problemi con questa interfaccia sono stati scoperti in modo indipendente da più parti che hanno esaminato diversi prodotti IoT negli ultimi anni, come le prese intelligenti CSL e Orvibo S20 e le lampadine Wi-Fi Flux, LimitlessLED e Zengge, con alcuni lavori precedenti che hanno mostrato come raccogliere SSID e chiavi da dispositivi basati su Hi-Flying rivolti a Internet e poi geolocalizzare le reti in questione.

IOTService / IOTManager

Il protocollo IOTService è utilizzato dallo strumento e dall'app IOTService per scoprire e configurare i dispositivi Hi-Flying basati su Eport e Wport. È molto simile all'interfaccia AT ed espone essenzialmente la CLI HF, che può essere resa disponibile anche via telnet, impacchettata in JSON sulla porta 48899/UDP senza autenticazione. La comunicazione viene avviata da un client che invia un messaggio di scoperta broadcast, dopodiché i nodi rispondono con le informazioni sul loro dispositivo e il client può iniziare a inviare comandi CLI avvolti in JSON. La funzionalità esposta è simile a quella dell'interfaccia AT e consente di scaricare e modificare le credenziali Wi-Fi e di servizio, modificare il firmware, ecc.

Per illustrare come si può abusare di questo protocollo, ho scelto come bersaglio il convertitore seriale / gateway Hi-Flying HF2211.

I convertitori seriali / gateway sono utilizzati in una varietà di ambienti (come l'automazione industriale e degli edifici) come interfaccia tra diversi protocolli seriali (ad esempio, bus di campo su RS-232 o RS-485) ed Ethernet e sono tipicamente collegati ad apparecchiature di automazione (come i PLC) o a dispositivi di campo. Tali convertitori sono stati storicamente molto insicuri e i prodotti di Hi-Flying non fanno eccezione in questo senso.

L'HF2211 si basa sulla serie di moduli Wport e, come altri dispositivi basati su Hi-Flying, imposta di default un AP aperto denominato 'HF2211_XXXX', dove XXXX sono gli ultimi 2 byte del MAC. HF2211 esegue eCos su un SoC MIPS Ralink RT5350f ed espone i seguenti servizi:

* 23/TCP, Telnet (Eport/Wport CLI)
* 53/UDP, DNS
* 80/TCP, HTTP
* 8899/TCP, Servizio Convertitore Seriale
* 48899/UDP, servizio IOTService

Utilizzando lo strumento di gestione IOTService e intercettando il traffico (non autenticato, in chiaro), possiamo analizzare il protocollo e costruire i nostri script per scaricare le credenziali WiFi o modificare il firmware del convertitore per eseguire attacchi MITM efficienti sul traffico seriale elaborato (e quindi influenzare negativamente i processi industriali controllati da esso).

A proposito di quegli inverter

Bene, torniamo agli inverter solari che hanno dato il via a questa indagine. Come abbiamo visto, un aggressore con accesso a una delle interfacce di gestione del kit WiFi può scaricare una nuova immagine del firmware sugli inverter collegati tramite la connessione seriale. E dato che non esiste un meccanismo di autenticazione del firmware sull'inverter, possiamo apportare modifiche arbitrarie, che vanno dal brick ad azioni più sofisticate.

Influenza la stabilità della rete elettrica

Gli inverter solari esistono per convertire l'uscita variabile di corrente continua (DC) dei sistemi fotovoltaici in una corrente alternata (AC) a frequenza di utilità che può essere immessa in una rete elettrica commerciale o in una rete elettrica locale 'off-grid'. L'energia così generata può essere immessa direttamente nella rete elettrica, come nel caso di un parco solare commerciale, oppure può essere utilizzata per soddisfare le richieste di consumo di energia domestica, sia direttamente, con l'immissione in rete della sola energia in eccesso, sia indirettamente, con l'aiuto di un'apparecchiatura di misurazione netta.

L'equilibrio tra domanda e offerta di energia è fondamentale per il corretto funzionamento della rete, al fine di evitare l'instabilità. I sistemi fotovoltaici influenzano l'equilibrio della rete sotto forma di riduzione della domanda e aumento dell'offerta, in genere alimentando direttamente le esigenze locali e immettendo l'energia in eccesso nella rete. Gli inverter solari sono fondamentali per mantenere l'equilibrio tra la generazione di corrente continua degli array solari e il carico di corrente alternata della famiglia e della rete elettrica. I picchi o i cali derivanti da eventi come eclissi solari, copertura nuvolosa, guasti temporanei o produzione nelle ore di punta (ad esempio, a mezzogiorno) sono gestiti da una combinazione di aziende di servizi pubblici che pianificano in anticipo, fornendo buffer e capacità di intervento e inverter che assicurano di corrispondere accuratamente alla tensione, alla frequenza e alla fase dell'onda sinusoidale CA della rete, di appianare le fluttuazioni e di fornire capacità anti-islanding disconnettendosi dalla rete se questa va in tilt per garantire la sicurezza dei lavoratori.

Come sottolineato nel lavoro precedente su questo argomento (https://www.mdpi.com/1996-1073/12/4/725/pdf), (https://horusscenario.com/), un aggressore con un controllo sufficiente sulla funzionalità di un inverter (ad esempio scaricando un firmware modificato) potrebbe manipolarlo per influire potenzialmente sulla stabilità della rete. Un aggressore potrebbe cercare di manipolare l'uscita di potenza dell'inverter (e potenzialmente influenzare il sistema di gestione delle batterie) per provocare un calo della fornitura complessiva e influenzare negativamente il compenso finanziario individuale ricevuto per l'energia fornita alla rete o cercare di iniettare una potenza eccessiva e/o manipolare la tensione per amplificare gli stati indesiderati della rete.

Ovviamente la complessità di tali attacchi non è da sottovalutare. Oltre alla presenza difensiva dei sistemi di protezione della rete e all'intervento dell'operatore, un attacco di questo tipo richiederebbe scala e coordinamento. Questi fattori sono a loro volta influenzati dal grado di penetrazione del solare nelle fonti di generazione di energia della rete globale e dal controllo dell'attaccante su una quota significativa di inverter fotovoltaici, quest'ultimo a sua volta influenzato dall'eterogeneità e dall'esposizione delle soluzioni di inverter.

In ogni caso, anche in assenza di dimostrazioni reali di fattibilità su banchi di prova rappresentativi, la protezione dei sistemi connessi alla base di varie risorse energetiche distribuite (DER) come il solare, l'eolico, la biomassa e il piccolo idroelettrico è di importanza cruciale per gli sforzi di protezione della rete globale.

Colpire la sicurezza dell'inverter

Un altro scenario potenzialmente dannoso prevede che un aggressore modifichi il firmware dell'inverter al fine di influire negativamente sulla sicurezza, ad esempio provocando un incendio. Se sia possibile o meno provocare in modo affidabile un incendio dell'inverter esclusivamente attraverso il software è ancora da dimostrare e quindi è necessaria cautela nel giudicare il realismo di questo scenario, ma dato il tipico grado di controllo del firmware dell'inverter sulle ventole interne, sui monitor della temperatura di regolazione della tensione, ecc.

Le cause più comuni di incendio di un inverter sono l'arco e il riscaldamento resistivo (come precursore dell'arco o di per sé), che sono in genere il risultato di una produzione e/o installazione inadeguata, delle condizioni ambientali e dell'invecchiamento dei componenti. Per influire negativamente sulla sicurezza degli inverter, un aggressore dovrebbe indurre artificialmente un guasto ai materiali (ad esempio, attraverso il riscaldamento resistivo e le alte temperature ambientali) come precursore dell'arco o come causa diretta dell'accensione, oltre a superare i meccanismi di sicurezza come i rilevatori di guasti ad arco e il monitoraggio della temperatura.

Interno del firmware dell'inverter Omnik

Esistono diverse linee di inverter Omnik, ma in generale tutti hanno un firmware per un modulo CPU master, un modulo CPU slave e un modulo display. Per illustrare l'interno del firmware, diamo un'occhiata all'inverter trifase senza trasformatore Omniksol-13k/17k/20k-TL.

I moduli master e slave sono basati sul microcontrollore TMS320F2802x che esegue l'RTOS Micrium µC/OS-II, con stringhe nel firmware che suggeriscono una relazione di toolchain con il modem TMS320C2000 single frequencypower line communication (SFPLC). Il modulo di visualizzazione si basa sul microcontrollore AT91SAM9261 con Windows CE.

Come possiamo vedere dagli snippet di disassemblaggio di cui sopra, il firmware ha un controllo granulare su un'ampia gamma di funzionalità, dalla ventola, all'uscita dell'inverter e a vari aspetti della sincronizzazione della rete fino all'inseguimento del punto di massima potenza (MPPT), consentendo così a un aggressore in grado di modificare il firmware di regolare maliziosamente le operazioni dell'inverter in modo molto preciso. Se questo sia davvero sufficiente per ottenere i risultati desiderati, richiederà ulteriori ricerche.

Conclusione

Sebbene l'impatto potenziale delle vulnerabilità discusse sugli inverter solari collegati e sui convertitori seriali sia preoccupante, non sono il vero problema di questa storia. È (o dovrebbe essere) risaputo che la maggior parte dei sistemi embedded connessi (sia per i consumatori che per i Settori industriali) sono in genere tristemente insicuri e nell'ultimo decennio è aumentata anche la consapevolezza degli 'attacchi cyber-fisici', in cui i problemi di sicurezza nel mondo digitale influenzano direttamente il regno fisico.

A mio avviso, l'aspetto più preoccupante è l'illustrazione degli effetti dannosi dell'opacità della catena di fornitura sulla gestione delle vulnerabilità. Le complicate catene di fornitura dei sistemi embedded connessi coinvolgono molti attori su più livelli, che forniscono e integrano diversi componenti hardware e software, a partire dai SoC e dalle librerie, fino ad arrivare allo stesso prodotto che finisce a più OEM diversi, che effettuano una personalizzazione minima prima di passarlo a un altro livello di rivenditori che in pratica ci appongono sopra un nuovo logo. Una vulnerabilità in qualsiasi componente, a qualsiasi livello, può 'scendere' lungo una catena di fornitura sempre più opaca per finire nelle apparecchiature ICS, nei terminali POS e nelle bambole connesse a Internet, e più le vulnerabilità risalgono la catena di fornitura, più ampia è la gamma di prodotti in cui tendono a finire e più difficile è tracciarle e mitigarle senza la collaborazione attiva di tutte le parti coinvolte. Per esempio: se pensa che vulnerabilità come Broadpwn, Blueborne, Devil's Ivy, Shellshock o Heartbleed non possano più essere trovate in natura perché le parti direttamente responsabili del codice vulnerabile hanno rilasciato una patch, avrà una brutta sorpresa.

Dal momento che nessuna singola entità supervisiona l'intero ciclo di vita dello sviluppo e della manutenzione del software, spesso non esiste un insieme unico e coerente di requisiti di sicurezza e più si sale nella catena (come i venditori di SoC o RTOS), più ampia è la base di clienti a cui bisogna rivolgersi e questo in genere significa rivolgersi al minimo comune denominatore in termini di capacità, spese generali e vincoli di costo. Inoltre, non esiste un'entità unica e chiara che abbia la capacità di rilasciare direttamente e centralmente le patch per qualsiasi vulnerabilità nel prodotto finale. Invece, gli OEM devono aspettare che i loro fornitori (o i fornitori dei loro fornitori) rilascino le proprie patch e le integrino nelle nuove versioni del firmware che possono poi distribuire ai loro clienti, i quali spesso devono applicarle manualmente a tutti i prodotti interessati (o affidarsi a qualche piccolo fornitore IoT con capacità di aggiornamento del firmware arbitrarie su un gruppo di dispositivi nelle loro reti, il che potrebbe essere peggio).

In sintesi, è necessario un approccio più olistico alla sicurezza IoT, che copra tutti gli aspetti rilevanti del ciclo di vita del prodotto e che garantisca che i prodotti soddisfino una linea di base minima comune.

Cronologia della divulgazione delle vulnerabilità:

* 6 ottobre 2018 - Prima segnalazione a Hi-Flying
* 26 maggio 2019 - Segnalazioni a SolarMAN e Omnik e a NCSC-NL
* Dal 26 maggio al 22 luglio 2019 - NCSC-NL ha tentato di contattare i produttori, ma senza risposta, escalation a CNCERT/CC
* 15 agosto 2019 - Ancora nessuna risposta da parte di alcun produttore, decisione di pubblicare

Grazie a Peter-Jan Pinxteren per aver individuato gli AP aperti originali e aver creato il collegamento con i kit di connettività Omnik.