Fallo en DJI ROMO permitió acceso a 6.700 robots aspirador conectados

febrero 26, 2026

Fallo en DJI ROMO permitió acceso a 6.700 robots aspirador conectados

Qué pasó

Un investigador aficionado descubrió que, al replicar la comunicación de su propia DJI ROMO con los servidores del fabricante, pudo suscribirse y recibir datos de miles de dispositivos en todo el mundo. Sammy Azdoufal, directivo de estrategia de IA en una empresa de alquiler vacacional, desarrolló una app casera para controlar su ROMO con un mando de PS5 “porque era divertido”. Al extraer el token asociado a su dispositivo y autenticarse como cliente válido, su herramienta comenzó a registrar otros aparatos que lo reconocían como propietario.

Durante una demostración en directo, Azdoufal mostró que en nueve minutos su herramienta había identificado 6.700 robots en 24 países y recopilado más de 100.000 mensajes enviados por ellos. Cada dispositivo reportaba, mediante mensajes periódicos, datos como número de serie, la estancia que estaban limpiando, recorrido y el retorno a la base de carga.

Cómo ocurrió técnicamente

La comunicación entre los dispositivos y la infraestructura de DJI se realizaba mediante MQTT, un protocolo de publicar/suscribirse muy habitual en Internet de las cosas (IoT). Azdoufal no necesitó “hackear” servidores en el sentido clásico: analizó el tráfico de su propio aparato, extrajo un token privado de autenticación y lo usó para conectar al backend como si fuera un cliente legítimo.

“No necesité hackear los servidores; lo que hice fue extraer el token privado asociado a mi dispositivo”, explicó Azdoufal.

El problema, según su relato y la confirmación posterior de DJI, fue una validación insuficiente de permisos en el backend: una vez autenticado, el sistema no limitó correctamente a qué topics o mensajes podía suscribirse ese cliente, permitiendo así la observación masiva de estados y telemetría de otros robots. DJI comunicó que detectó la vulnerabilidad a finales de enero y desplegó parches el 8 y el 10 de febrero para corregir nodos pendientes. La compañía afirmó además que la transmisión estaba cifrada con TLS y que el acceso no autorizado fue “extremadamente raro”. DJI también señaló que los datos de dispositivos europeos se almacenan en infraestructura de AWS ubicada en Estados Unidos.

Contexto y antecedentes: por qué importa

Este incidente no es aislado dentro del ecosistema del IoT. Protocolos y servicios diseñados para facilitar la gestión remota (MQTT, CoAP, HTTP/REST) pueden convertirse en vectores de exposición si la autenticación y la autorización no se implementan con rigor. Casos históricos que ilustran los riesgos incluyen el botnet Mirai (2016), que aprovechó credenciales por defecto para tomar control de grandes flotas de dispositivos conectados, y diversos incidentes documentados en cámaras y aspiradores inteligentes que han expuesto vídeo, imágenes o telemetría por errores de configuración o fallos de seguridad en backend.

Los robots aspirador modernos combinan sensores, cámaras, LiDAR y conectividad permanente para mapear hogares y optimizar rutas. Esa capacidad proporciona una gran utilidad, pero también convierte a estos productos en repositorios de metadatos sensibles (planos, hábitos, horarios) y, en algunos modelos, en cámaras y micrófonos dentro de espacios privados.

Implicaciones y riesgos

  • Privacidad: la telemetría y los mapas domésticos pueden revelar patrones de presencia, estancias frecuentadas y, potencialmente, imágenes o audio si el dispositivo dispone de cámaras o micrófonos. El hecho de que datos europeos se almacenen en servidores fuera de la UE añade riesgos legales y de cumplimiento (por ejemplo, GDPR), así como de jurisdicción y acceso por terceros.
  • Seguridad operacional: exposición de número de serie y estados podría facilitar ataques dirigidos, suplantación de dispositivos o instrucciones maliciosas si no se controlan las autorizaciones de comandos.
  • Confianza en el proveedor: la gestión centralizada y la opacidad sobre qué controles backend se aplican hacen que la confianza del usuario sea más frágil; la divulgación tardía o la minimización del alcance agravan la percepción de riesgo.
  • Supervisión y auditoría insuficientes: que un investigador pueda descubrir este nivel de exposición casi por accidente plantea dudas sobre las pruebas internas, análisis de amenazas y auditorías de seguridad previas al despliegue.

Análisis técnico y recomendaciones para profesionales

Para equipos de desarrollo y operaciones que diseñan plataformas IoT con comunicación MQTT o arquitecturas de pub/sub, este caso aporta varias lecciones prácticas:

  • Autenticación fuerte y por dispositivo: emplear credenciales únicas por dispositivo, con rotación periódica y mecanismos que permitan revocar tokens comprometidos. Evitar tokens long-lived sin control.
  • Autorización a nivel de tópico (ACL): implementar listas de control de acceso que limiten estrictamente qué topics puede suscribir o publicar cada identidad. El principio de menor privilegio debe aplicarse a la telemetría y a los comandos.
  • Mutual TLS y certificados gestionados: cuando sea viable, usar mTLS en lugar de solo TLS con tokens, para verificar tanto cliente como servidor con identidad criptográfica gestionada.
  • Seguridad del backend y validación de permisos: los brokers MQTT y los microservicios deben validar cada request contra una política de autorización centralizada. No confiar en la autenticación como único control.
  • Monitorización y detección de anomalías: alertas por suscripciones inusuales, acceso desde ubicaciones inesperadas o picos de lectura de mensajes; registros inmutables y trazabilidad de acciones administrativas.
  • Reducción de la superficie de exposición: no exponer brokers MQTT directamente a Internet sin gateway/autenticación adicional; segmentar redes y usar VPNs o proxies seguros.
  • Pruebas de seguridad continuas: incluir pruebas de penetración específicas de IoT, revisión de arquitecturas pub/sub y ejercicios de bug bounty para encontrar escenarios de abuse case.

Consejos prácticos para usuarios

  • Aplicar de inmediato las actualizaciones que publique el fabricante.
  • Colocar dispositivos IoT en una VLAN o red separada del resto de equipos (segmentación doméstica). Muchos routers permiten crear una red de invitados para electrodomésticos conectados.
  • Revisar permisos de la app y desactivar funciones no necesarias: micrófono, cámara o almacenamiento de mapas, si es posible.
  • Usar contraseñas fuertes para la cuenta de fabricante y activar autenticación de dos factores si la plataforma lo soporta.
  • Consultar la política de privacidad del proveedor y la ubicación de almacenamiento de datos; si tiene inquietudes, valorar alternativas con mejor historial de seguridad o menor dependencia de la nube.
  • Apoyar y participar en programas de divulgación responsable: notificar al fabricante o a comunidades de seguridad cuando se encuentren problemas.

Comparables y tendencias

En la última década ha habido múltiples incidentes que recuerdan la fragilidad del ecosistema IoT frente a errores de configuración o diseño: el botnet Mirai (2016) por credenciales por defecto, exposiciones de cámaras conectadas por APIs inseguras y casos documentados en aspiradores y otros electrodomésticos donde se han filtrado imágenes o telemetría. La tendencia es doble: los dispositivos han ganado funcionalidades avanzadas (visión, mapeo, aprendizaje) que aumentan su valor y su riesgo; y, al mismo tiempo, la superficie de ataque se expande cuando los mecanismos de control central no están bien segmentados.

Conclusion

El incidente con DJI ROMO ilustra un fallo clásico de diseño en plataformas conectadas: autenticación sin una autorización granular y controles backend insuficientes. Aunque DJI corrigió el problema tras ser notificado, el evento subraya la necesidad de aplicar principios de seguridad por diseño en dispositivos que operan dentro del hogar. Para las empresas, la lección es clara: auditar permisos, limitar el alcance de las identidades y desplegar monitorización proactiva. Para los usuarios, las medidas prácticas —actualizaciones, segmentación de red y revisión de permisos— reducen significativamente el riesgo hasta que los fabricantes refuercen sus infraestructuras.

Source: www.xataka.com