Controlla il suo robot con un joystick: scopre una falla e può accedere a 7.000 case nel mondo

Un semplice progetto di sviluppo personale, nato per controllare un robot aspirapolvere con un controller da videogioco, ha portato alla scoperta di una vulnerabilità capace di esporre migliaia di dispositivi installate in abitazioni private di tutto il mondo. L’episodio riguarda Sammy Azdoufal, un ingegnere software che, tentando di integrare un controller PlayStation con i server cloud di DJI, ha individuato un difetto di sicurezza che permetteva l’accesso remoto a telecamere, microfoni e mappe domestiche di circa 7.000 robot aspirapolvere distribuiti in 24 Paesi.

La vicenda si inserisce in una fase storica in cui la diffusione dei dispositivi domestici connessi cresce rapidamente: milioni di famiglie italiane possiedono oggi almeno un dispositivo smart home e la quota continua ad aumentare con l’introduzione di robot sempre più sofisticati e autonomi.

Come funziona il DJI Romo

Il robot aspirapolvere DJI Romo, introdotto inizialmente nel mercato cinese e portato in seguito nei mercati internazionali, rappresenta una nuova generazione di dispositivi domestici autonomi.

Il sistema integra sensori ottici, telecamere, lidar e moduli di navigazione che consentono al robot di mappare gli ambienti in tempo reale. Per operare correttamente, il dispositivo deve acquisire immagini degli spazi, riconoscere oggetti e distinguere le diverse aree della casa, come cucina o camera da letto.

Parte di queste informazioni è memorizzata localmente, mentre una quota significativa di esse è sincronizzata con server remoti per consentire il controllo via app e l’aggiornamento delle funzionalità.

Il flusso dati tra robot e cloud avviene tramite token di autenticazione che certificano la proprietà del dispositivo. L’app ufficiale utilizza questi token per accedere alle informazioni del robot, inviare comandi e ricevere dati in tempo reale. In un contesto di progettazione sicura, tali credenziali dovrebbero essere strettamente limitate al singolo utente e al singolo dispositivo.

La vulnerabilità nel backend e l’accesso a migliaia di robot

Durante il tentativo di sviluppare un’applicazione personalizzata, l’ingegnere ha utilizzato un assistente di codifica basato su AI per analizzare il protocollo di comunicazione tra robot e cloud.

Il processo di reverse engineering ha evidenziato un errore nella gestione delle autorizzazioni lato server: invece di validare un singolo token associato al robot dell’utente, il backend restituiva privilegi estesi su una vasta quantità di dispositivi.

La falla consentiva quindi l’accesso a flussi video in diretta, attivazione dei microfoni integrati, consultazione dello stato operativo dei robot e generazione di mappe bidimensionali degli ambienti domestici. Inoltre, l’analisi degli indirizzi IP permetteva di dedurre la posizione geografica approssimativa dei dispositivi aspirapolvere.

Il problema non derivava da un attacco attivo ma da un difetto logico di autorizzazione, tipico delle vulnerabilità classificate come IDOR (Insecure Direct Object Reference) o da errori di gestione dei privilegi nel backend.

Dashboard fai-da-te che prima dell’applicazione delle patch permetteva di vedere e controllare i robot DJI Romo a livello mondiale (fonte: Gonzague)

Patch e gestione della vulnerabilità da parte del produttore

Dopo la segnalazione della vulnerabilità, avvenuta in privato, DJI ha dichiarato di aver individuato il problema durante una revisione interna e di aver avviato immediatamente la mitigazione.

Il processo di risoluzione si è articolato in due aggiornamenti: un primo fix distribuito l’8 febbraio 2026 e una seconda patch applicata a partire dal 10 febbraio. L’aggiornamento è stato distribuito automaticamente attraverso il sistema OTA dei dispositivi, senza necessità di intervento da parte degli utenti.

Non sono stati diffusi dettagli tecnici approfonditi sulla correzione, ma interventi tipici in questi casi includono la revisione del sistema di autenticazione, la segregazione dei tenant nel backend e la validazione dei token mediante controlli di contesto e proprietà.

L’adozione di meccanismi di access control più granulari e di audit log server-side rappresenta una misura standard per prevenire accessi non autorizzati.

Rischi sistemici dei robot domestici connessi

Il caso evidenzia un problema più ampio legato alla sicurezza dei dispositivi smart home. I robot domestici, a differenza di altri dispositivi IoT, operano in spazi estremamente sensibili e raccolgono dati ad alta risoluzione sulle abitudini quotidiane. La presenza simultanea di telecamere, microfoni e sensori ambientali trasforma questi dispositivi in potenziali strumenti di sorveglianza, se compromessi.

Un esempio di flusso video osservabile, senza autorizzazione, dal pannello di controllo (fonte: Gonzague, Reddit)

Eventi recenti hanno alimentato il dibattito sulla gestione dei dati domestici: funzionalità di condivisione video su telecamere di sicurezza, accesso a registrazioni da parte delle forze dell’ordine e dubbi sulla reale cancellazione dei dati da servizi cloud hanno aumentato l’attenzione pubblica.

Per ridurre l’esposizione a rischi simili, i produttori devono adottare un approccio basato su sicurezza by design. Tra le misure fondamentali rientrano la segregazione dei dati tra utenti, l’implementazione di autenticazione a più fattori per l’accesso alle API e l’utilizzo di crittografia end-to-end per i flussi audio e video. Audit di sicurezza indipendenti e programmi di bug bounty possono contribuire a individuare vulnerabilità prima che vengano sfruttate.

Il caso del DJI Romo dimostra come l’evoluzione dei robot domestici richieda un livello di sicurezza equivalente alla tipologia dei dati trattati. L’integrazione sempre più stretta tra intelligenza artificiale, cloud e automazione domestica impone una revisione continua delle architetture di sicurezza per prevenire accessi non autorizzati e proteggere la privacy degli utenti.

Analisi tecnica della falla: errore di isolamento logico e design del backend

Dal punto di vista ingegneristico, la vulnerabilità dei robot DJI Romo nasce da una combinazione di errori architetturali nel modello di autenticazione e nella gestione dei flussi MQTT.

Il reverse engineering pubblicato dal ricercatore mostra chiaramente che l’app DJI Home comunica con due componenti principali del backend: un’API di autenticazione cloud e un broker MQTT centralizzato, utilizzato sia dai robot sia dalle applicazioni client per lo scambio di messaggi in tempo reale.

Il problema non risiede nella cifratura del canale – che avviene correttamente tramite TLS – ma nell’assenza di isolamento logico tra i client autenticati. Prima della patch DJI, una volta ottenuto il token valido di un singolo dispositivo, il client MQTT poteva iscriversi a topic wildcard e ricevere traffico proveniente da altri robot, perché il broker non applicava ACL granulari per separare i namespace dei dispositivi. In altre parole, l’autenticazione è corretta ma l’autorizzazione era globalmente permissiva.

Il ricercatore ha dimostrato che l’architettura espone implicitamente un bus di messaggistica condiviso, nel quale tutti i dispositivi pubblicavano eventi (telemetria, stato, stream) senza un filtro lato server che limitasse l’accesso al solo proprietario.

Tale difetto consentiva non solo la lettura passiva dei dati, ma anche l’iniezione di comandi remoti, perché i topic di controllo utilizzano lo stesso schema di routing e non sono vincolati a identità specifiche.

Il ruolo dei modelli AI nel rilevamento dei problemi di sicurezza

La vicenda dimostra anche come strumenti di sviluppo assistiti da intelligenza artificiale possano accelerare l’analisi dei protocolli e l’individuazione di vulnerabilità.

Sebbene tali strumenti siano progettati per supportare la produttività degli sviluppatori, possono ridurre la barriera tecnica necessaria per eseguire operazioni di reverse engineering e test di sicurezza.

L’uso di strumenti di code generation AI può facilitare la creazione di script per interagire con API non documentate, analizzare traffico di rete e manipolare richieste HTTP. In assenza di adeguati controlli di sicurezza lato server, questo scenario aumenta il rischio che vulnerabilità latenti possano essere sfruttate da attori malevoli con competenze tecniche limitate.