Caso di studio: robot aspirapolvere, root e telecamere altrui
Abbiamo testato un robot aspirapolvere con telecamera: accesso root al dispositivo e falle nell’API cloud che aprivano la telecamera live di altri utenti.
Zyberum Security Team · Pubblicato il · 5 min di lettura
Un robot aspirapolvere con telecamera è una telecamera che si muove dentro casa di qualcuno. Ne abbiamo testato uno: il dispositivo, la sua app e il cloud che gli sta dietro. Il nome del produttore qui non conta. Conta lo schema, perché lo ritroviamo di continuo.
Che cosa abbiamo testato
Il prodotto completo, così come lo vede un attaccante:
- il dispositivo stesso
- l’app mobile
- l’API cloud con cui l’app comunica
- il canale MQTT tra dispositivo e cloud
- la connessione video WebRTC della telecamera live
Che cosa abbiamo trovato
Root sul dispositivo
Abbiamo ottenuto accesso root completo al robot. Con i privilegi di root un attaccante controlla tutto ciò che il dispositivo sa fare: muoversi, registrare, mettersi in ascolto sulla rete a cui è collegato e leggere tutto ciò che il produttore vi ha memorizzato.
I dispositivi altrui attraverso l’API
I risultati più gravi erano nel cloud. L’API presentava i tre classici difetti di autorizzazione:
| Difetto | Che cosa significava in questo caso |
|---|---|
| IDOR / BOLA | Le richieste relative a un dispositivo ricevevano risposta anche per dispositivi appartenenti ad altri utenti |
| BFLA | Funzioni che dovevano essere riservate potevano essere richiamate da un normale account utente |
| Esposizione eccessiva di dati | Le risposte dell’API contenevano molte più informazioni di quante l’app ne mostrasse |
MQTT
Il canale di messaggistica tra dispositivi e cloud aveva debolezze proprie, che ampliavano ciò che un singolo utente autenticato poteva vedere e fare.
L’impatto: una telecamera live in casa di uno sconosciuto
Combinati, questi risultati ci hanno dato accesso al flusso video WebRTC dei robot di altre persone. Non il nostro dispositivo di test: dispositivi di altri utenti. Nessun malware, nessun accesso fisico, nessuna password da indovinare. Sono bastati un account normale e le richieste giuste.
Perché è successo
Niente di tutto questo ha richiesto tecniche di exploitation avanzate. La causa di fondo era la stessa in ogni risultato: il backend si fidava di ciò che il client inviava. Verificava che l’utente fosse autenticato, ma non che il dispositivo indicato nella richiesta appartenesse a quell’utente.
È il difetto grave più diffuso nei prodotti connessi, ed è invisibile agli scanner automatici, perché ogni singola richiesta sembra legittima.
Che cosa dovrebbero trarne i produttori
- Verificate la proprietà a ogni richiesta. Sul server, per ogni ID dispositivo, ogni volta. Non nell’app.
- Trattate MQTT come un’API. Ogni client può pubblicare e sottoscrivere soltanto i propri topic.
- Restituite solo ciò che serve. Se l’app non mostra un campo, l’API non dovrebbe inviarlo.
- Date per scontato che il dispositivo verrà aperto. Tutto ciò che vi è memorizzato, chiavi comprese, verrà letto.
- Testate il prodotto intero. Dispositivo, app e cloud insieme. I risultati peggiori nascono dalla loro combinazione.
Con il Cyber Resilience Act un prodotto come questo non può essere immesso sul mercato con vulnerabilità sfruttabili note, e il produttore deve gestirle e segnalarle. Un test prima del lancio costa meno di un richiamo dopo.
Volete sapere che cosa rivela il vostro dispositivo? Scoprite i test di sicurezza IoT, i pentest web e API oppure quanto costa un test.
FAQ
Domande frequenti
Che cosa sono IDOR, BOLA e BFLA?
IDOR (insecure direct object reference) e BOLA (broken object level authorization) descrivono lo stesso problema: il server restituisce o modifica un oggetto, ad esempio un dispositivo, perché la richiesta ne indica l’ID, senza verificare che appartenga a chi la invia. BFLA (broken function level authorization) significa che un utente può richiamare funzioni destinate a un altro ruolo, ad esempio a un amministratore.
Perché queste falle sono così frequenti nei prodotti IoT?
I backend IoT gestiscono milioni di dispositivi attraverso un numero ridotto di chiamate API e topic MQTT. Se in un solo punto manca il controllo "questo dispositivo appartiene a questo utente?", ogni dispositivo dietro quella chiamata è esposto. Gli scanner automatici non se ne accorgono, perché ogni richiesta è tecnicamente valida.