Ricerca di: Andrea D’Ubaldo, Antonio Montillo
Swascan ha scoperto una backdoor nei dispositivi di monitoraggio fotovoltaico (PV) di Solar-Log GmbH con un impatto su migliaia di clienti. La backdoor consente, in maniera non autenticata, di accedere da remoto alle funzionalità di super admin nell’area riservata del dispositivo.
Technical Summary
| Vulnerability | CVSSv3.1 | CWE |
Hidden Functionality in slcore component v4.2.7 up to v5.1.1 (included) | 9.8 [AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H] | CWE-912: Hidden Functionality |
Remediation
Download del nuovo Firmware versioni 5.1.2_156 e 4.2.8_117 https://www.solar log.com/it/supporto/firmware.
Background
Nel 2021, Swascan ha identificato durante un’attività di Penetration Testing un dispositivo per il monitoraggio di pannelli solari prodotto dall’azienda tedesca Solar-Log. Nel dispositivo era presente la vecchia versione del firmware con vulnerabilità note ed exploit disponibili online. Il team di Swascan ha deciso di indagare ed approfondire la ricerca per identificare ulteriori possibili falle nelle versioni più recenti del firmware.
Il vendor Solar-Log GmbH
Solar-Log Gmbh è un’azienda pioniere e leader nel monitoraggio d’impianti fotovoltaici, Smart Energy, nella gestione dell’energia e dell’emissione d’energia e calore. Solar-Log™ è compatibile con oltre 2000 componenti, rendendolo un sistema unico di gestione dell’energia per l’energia rinnovabile.
I prodotti principali di Solar-Log sono:
- Solar-Log 50 Gateway, Residential Solar Monitoring: gateway compatto e semplificato per monitorare impianti fotovoltaici residenziali fino a 15kwp.
- Solar-Log Base Data Logger & Energy Manager: dispositivo universale di monitoraggio e gestione dell’energia.
La diffusione dei prodotti Solar-Log
Nei giorni in cui questa ricerca è stata condotta, Solar-Log conta più di diecimila dispositivi raggiungibili su Internet. Di seguito una query effettuata su Zoomeye, mostra tutti i dispositivi che ripspondono alla ricerca di pagine di login esposte dei gateway Solar-Log. Tuttavia, come menzionato dal fornitore stesso, Solar-Log è ampiamente diffuso in tutti i paesi; pertanto, i numeri potrebbero essere ancora più grandi.
Il dispositivo
Il dispositivo che abbiamo analizzato è il Solar-Log 50 Gateway, utilizzato principalmente per il monitoraggio di impianti solari fotovoltaici residenziali, pertanto è il prodotto più economico e più popolare della gamma di prodotti Solar-Log.
Come funzionano i dispositivi Solar-Log
In uno schema semplificato e generico, potremmo dire che Il dispositivo Solar-Log si trova tra i pannelli fotovoltaici ed altri oggetti collegati, come sensori, inverter o altri dispositivi. Il gateway raccoglie e processa i dati trasmessi dagli oggetti, tramite RS232 o RS422, e ne mostra i risultati sul web server locale tramite un’apposita dashboard. In alternativa, se configurato dall’utente, può inviare i dati raccolti alla piattaforma cloud, chiamata WEB-Ernest, che però non è stata interessata da questa ricerca.
Nell’immagine successiva, un diagramma generico che descrive la comunicazione dei dispositivi Solar-Log tra più componenti.
Vulnerabilità Note
I dispositivi di Solar-Log non sono nuovi a vulnerabilità, in passato sono stati pubblicati alcuni exploit su exploit-db.com:
- Solar-Log 250/300/500/800e/1000/1000 PM+/1200/2000: https://www.exploit-db.com/exploits/41671
- Solar-Log 500: https://www.exploit-db.com/exploits/49987
Il fornitore specifica che tutti i problemi di sicurezza sopra riportati sono stati risolti. I modelli 250, 300, 1200 e 200 continueranno a ricevere supporto tecnico, ma i modelli 500, 800e, 1000, 1000PM+ e 1200 sono “End-of-Life”.
L’analisi
La scheda
Il dispositivo è composto da una scheda personalizzata, con connessione USB, RS232, RS4222 ed Ethernet. Nell’immagine di seguito il fronte e il retro della board analizzata.
Nella parte posteriore della board, al centro, è possibile vedere il System-On-Module. Di seguito una breve descrizione.
System-on-Module (SOM)
Il System-on-Module è un circuito elettronico che integra le funzioni di sistema in un singolo modulo ed è tipicamente utilizzato nei sistemi embedded per applicazioni industriali che richiedono elevate prestazioni e affidabilità.
Le parti principali sono:
- i.MX6UltraLite 1x Arm® Cortex®-A7 @528 MHz Processor by NXP https://www.nxp.com/part/MCIMX6G2CVK05AB#/
- NAND FLASH Memory by WINBOND – 25M02GVZEIG https://www.alldatasheet.com/datasheet-pdf/pdf/932060/WINBOND/25M02GVZEIG.html
- RAM: DDR3-RAM 256 MB
Memoria flash NAND Winbond
La NAND flash è un Winbond W25M02GV (con tecnologia SpiStack), un pacchetto multi chip 2x1G-bit, basato sulla serie W25N SLC NAND SpiFlash. La differenza tra questa NAND e la maggior parte delle altre NAND è che la W25M è composta da due singole flash NAND W25N01GV impilate in un unico package WSON8 (8 pin). Questo dettaglio ha reso più complicata la ricerca di un programmer in grado di leggere questa NAND.
Analizzare l’identificatore “W25M02GVZEIG” è utile per capire meglio come interagire con la memoria flash NAND:
Dissaldare la memoria NAND
A questo punto è stato possibile dissaldare la memoria flash NAND dal SOM utilizzando una pistola termica che ha richiesto alcuni minuti, ma è stata rimossa con successo dalla scheda.
Lettura della memoria
Il tool flashrom e il programmatore CH341 sono una buona combinazione per effettuare il dump della memoria e funziona il più delle volte. Sfortunatamente, non in questo caso poiché flashrom non include un supporto per la serie NAND 25MXXXX. Siamo quindi passati a FlashcatUSB, un altro noto programmatore SPI, I2C e JTAG che inoltre è proprio partner ufficiale di WINBOND.
Ulteriore dettaglio importantissimo, è che FlashcatUSB ha anche diversi adattatori, molto utili quando non si vuole avere a che fare con saldature, jumper e cose simili. Di seguito la nostra configurazione utilizzando FlashcatUSB e l’adattatore WSON8.
All’interno del WSON8 si vede la NAND, posizionata con il pin 1 in basso a sinistra.
Running FlashcatUSB software:
Con il dispositivo FlashcatUSB viene fornito anche un software per il dump della memoria. Nel nostro caso il metodo da utilizzare è SPI NAND Flash.
Il software ha identificato la serie Winbond W25M02GV ed è stato possibile leggere la memoria principale.
Il risultato è un’immagine UBI, che sta per “Unsorted Block Images”, un sistema di gestione del volume per dispositivi flash raw.
Successivamente, utilizzando il tool ubireader, è stato possibile estrarre immagini e file:
Le partizioni “slcore-a” e “slcore-b” sembravano essere le più interessanti, si trovavano infatti molti dei componenti principali.
Reverse con Ghidra
Il file binario chiamato slcore sembra essere il componente contenente il server web, abbiamo quindi iniziato a analizzarlo con Ghidra.
Ispezionando il codice sorgente del componente slcore , abbiamo notato che esiste un flusso diverso all’interno della funzione di login.
C’erano infatti due diversi percorsi per accedere all’applicazione web senza essere un “utente normale”. Chiamiamo i seguenti profili “utenti regolari”, sono i tre utenti in grado di gestire l’applicazione web con diversi privilegi:
- utente (senza privilegi)
- amministratore (con privilegi parziali)
- installer/PM (privilegiato – installer locale)
La funzione di login ha due diversi branch di codice per il processo di autenticazione, il primo che possiamo considerare “legittimo” (utilizzato dagli utenti regolari) e il secondo che solo il fornitore conosce (utilizzato per l’accesso come profilo di supporto o profilo embedded).
In accordo con Solar-Log e secondo la Coordinated Vulnerability Disclosure, non condivideremo il codice sorgente e i dettagli dell’algoritmo, descriveremo solo il processo di funzionamento della backdoor:
- L’utente accede tramite la pagina web Solar-Log.
- Nel caso in cui il nome utente corrisponda a un utente specifico tra quelli “regolari” genera due password pseudo-casuali, utilizzando il numero di serie del dispositivo e l’ora della data corrente come seed.
- Se la password inserita dall’utente corrisponde alla/alle password generate in precedenza, allora si accede come amministratore o super amministratore.
Riprodurre la generazione delle password
Analizzando il codice sorgente emerge che il numero di serie è scritto all’interno del processore IMX6 all’interno del registro OCOTP, e viene restituito dalla funzione getSerialnr(). Questo registro è mappato come file in sysfs, più specificamente in /sys/fsl_otp. Invece di eseguire il firmware e accedere a quella posizione, abbiamo fatto qualcosa di più semplice. Abbiamo esaminato l’output della funzione getSerialnr() nel codice sorgente, che restituisce proprio il numero di serie del dispositivo, leggendo dal registro OCOTP e scrivendo il risultato nel file di configurazione.
| … serialNumber <- getSerialnr() //read from OCOTP register write(configuratio, ‘XXX: %s’, serialNumber) … |
Abbiamo cercato il codice XXX (un ID) all’interno dei nostri file dumpati e abbiamo individuato il numero di serie nel file di configurazione. Nel nostro caso il numero di serie del nostro dispositivo era 547870007. Questo numero di serie, scritto nel registro OCOTP è lo stesso che è esposto nella pagina di accesso di ogni dispositivo Solar-Log.
Exploitation
Abbiamo confermato quindi che il numero di serie e l’ora della data sono noti a chiunque, perché sono visibili nella pagina di accesso di ogni dispositivo Solar-Log pubblico. Questo è il risultato del nostro Proof of Concept, che non pubblicheremo in accordo con il vendor, utilizzando il numero di serie del nostro dispositivo Solar-Log 50.
Abbiamo usato le password generate per accedere come amministratore e super amministratore al nostro dispositivo Solar-Log ed ha funzionato. Entrambi i profili hanno permesso infatti di accedere all’area riservata non disponibile agli “utenti regolari”, accedendo a diversi sottomenu e configurazioni quali: lingua, display, login, database, configurazione tabulare, driver, controllo dell’integrità, comunicazione di supporto e altro.
Riferimenti
Solar-Log GmbH Patch: https://www.solar-log.com/it/supporto/firmware/
CWE 912: Hidden Functionality https://cwe.mitre.org/data/definitions/912.html
CAPEC-190: Reverse Engineer an Executable to Expose Assumed Hidden Functionality https://capec.mitre.org/data/definitions/190.html
CVE-ID: Richiesto
Timeline
08/02/2022 vulnerabilità riportata al vendor
08/02/2022 il vendor risponde alla mail
09/02/2022 il vendor riconosce la vulnerabilità ed inizia a lavorare ad una remediation
11/02/2022 condivisione del security advisory con il vendor per la verifica dei contenut
22/03/2022 il vendor richiede alcune modifiche al security advisory e concdivide il piano di remediation
25/03/2022 accordo per la data di pubblicazione del security advisory
17/05/2022 il vendor richiede ulteriori giorni prima della pubblicazione
07/06/2022 pubblicazione del security advisory
25/01/2023 CVE assegnata CVE-2022-47767
