El caso del DJI Romo es un ejemplo reciente de cómo un fallo de diseño en la capa de seguridad puede convertir un electrodoméstico doméstico en una puerta trasera para acceder a mapas de casas, cámaras y micrófonos remotos. Todo empezó cuando un usuario, Sammy Azdoufal, intentó controlar su robot aspiradora con una app personalizada y terminó recibiendo respuestas de aproximadamente 7.000 unidades distintas en al menos 24 países.
Qué fue lo que se descubrió
DJI Romo usa el protocolo MQTT para comunicarse con los servidores y la app móvil; cada dispositivo tiene un token privado de autenticación. El problema se produjo porque ese token no estaba correctamente aislado por dispositivo: una vez autenticado, el broker permitía a un cliente suscribirse a temas (“topics”) de prácticamente todos los robots, no solo del propio.
Con esto, Azdoufal pudo:
- Ver mapas de las casas mientras el robot se desplazaba.
- Acceder a cámaras y flujos de video en tiempo real sin necesidad del PIN de seguridad.
- Controlar el movimiento de algunos robots y recibir datos de estado continuos (ubicación en la casa, obstáculos, distancia recorrida, etc.).
En resumen, el fallo no era (solo) que los datos viajaran sin cifrar, sino que la lógica de permisos en el servidor MQTT permitía que un token de autenticación válido actuara como “llave maestra” para múltiples dispositivos.
Entonces DJI decidió responder
DJI afirma haber descubierto un “problema de validación de permisos en el backend” en enero de 2026 y haber iniciado un parche en febrero con actualizaciones automáticas sin intervención del usuario. Sin embargo, tras la demostración pública de Azdoufal, se confirmó que el primer parche no había arreglado completamente la vulnerabilidad, y el fabricante tuvo que deshabilitar temporalmente el acceso a través de ese servidor.
La empresa también señaló que:
- La comunicación entre el robot y el servidor siempre usó TLS (no iba en texto plano).
- La mayoría de los accesos observados fueron de investigadores de seguridad, no de supuestos atacantes maliciosos.
- Los datos de los robots se almacenan en infraestructura cloud de AWS, con políticas de seguridad y un programa de recompensas por vulnerabilidades.
Aun así, el investigador sostiene que aún quedan abiertas vulnerabilidades, como la posibilidad de ver el flujo de video de tu propio Romo sin introducir el PIN de seguridad, y otra falla más grave que prefiere no detallar hasta que DJI la cierre.
Esto nos deja una gran enseñanzas para la ciberseguridad IoT
El caso del DJI Romo no es un “hack” sofisticado, sino un fallo clásico de arquitectura y control de acceso, donde nos refleja autenticación, pero una autorización débil.
Desde el punto de vista de un negocio hiperconectado, esto refuerza cinco ideas clave:
- Autenticación ≠ autorización: Que un token sea válido no significa que pueda acceder a cualquier dispositivo o tópico.
- Zero‑trust en el broker: Los servidores MQTT (y similares) deben aplicar listas finas de controles (ACLs por tópico) para evitar suscripciones wildcard que expongan todos los dispositivos.it4sec.
- Pruebas de límites reales: No basta con que el sistema funcione “según especificación”; hay que diseñar casos de prueba donde un token de dispositivo A intente acceder a los datos de dispositivo B.
- Transparencia en la respuesta: La percepción de seguridad también depende de cómo se comunica el incidente: aquí, el desfase entre la comunicación inicial de DJI y la realidad observada generó desconfianza.
- Cámaras domésticas no son “inofensivas”: Cualquier dispositivo con cámara y conexión a internet puede convertirse en un punto de exposición si no se diseña pensando primero en la confidencialidad del entorno donde se instala.
Estas ideas claves —desde el modelo Zero-Trust y la autorización granular hasta la transparencia ante incidentes— además de ser una buena práctica, son más bien un imperativo ético y comercial. Ignorar la diferencia entre un token válido y un acceso autorizado convierte cualquier innovación en una «puerta trasera» para la privacidad de los usuarios.
¿Es tu arquitectura de software realmente segura?
No esperes a que un fallo de arquitectura comprometa tu reputación o la privacidad de tus usuarios. Una auditoría a tiempo es la mejor defensa.
Fuente: https://www.theverge.com/tech/879088/dji-romo-hack-vulnerability-remote-control-camera-access-mqtt
