Caso práctico: root en un robot aspirador y las cámaras de otros
Probamos un robot aspirador con cámara: acceso root al dispositivo y fallos en la API cloud que abrían la cámara en directo de otros usuarios. Qué falló y por qué.
Zyberum Security Team · Publicado · 5 min de lectura
Un robot aspirador con cámara es una cámara que se mueve dentro de una vivienda. Probamos uno: el dispositivo, su app y la nube que hay detrás. El nombre del fabricante no importa aquí. El patrón sí, porque lo vemos una y otra vez.
Qué probamos
El producto completo, tal como lo vería un atacante:
- el propio dispositivo
- la app móvil
- la API cloud con la que habla la app
- el canal MQTT entre el dispositivo y la nube
- la conexión de vídeo WebRTC de la cámara en directo
Qué encontramos
Root en el dispositivo
Conseguimos acceso root completo al aspirador. Con root, un atacante controla todo lo que el dispositivo puede hacer: desplazarse, grabar, escuchar en la red a la que está conectado y leer todo lo que el fabricante haya guardado en él.
Los dispositivos de otras personas a través de la API
Los hallazgos más graves estaban en la nube. La API tenía los tres fallos clásicos de autorización:
| Fallo | Qué significaba aquí |
|---|---|
| IDOR / BOLA | Las peticiones sobre un dispositivo se respondían también para dispositivos que pertenecían a otros usuarios |
| BFLA | Funciones que debían estar restringidas se podían invocar desde una cuenta de usuario normal |
| Exposición excesiva de datos | Las respuestas de la API contenían mucha más información de la que la app llegaba a mostrar |
MQTT
El canal de mensajería entre los dispositivos y la nube tenía sus propias debilidades, que ampliaban lo que un único usuario autenticado podía ver y hacer.
El impacto: una cámara en directo en casa de un desconocido
Combinados, estos hallazgos nos dieron acceso al flujo de la cámara WebRTC de los aspiradores de otras personas. No de nuestro dispositivo de pruebas: de dispositivos de otros usuarios. Sin malware, sin acceso físico, sin adivinar contraseñas. Bastaron una cuenta normal y las peticiones adecuadas.
Por qué ocurrió
Nada de esto requirió técnicas de explotación avanzadas. La causa raíz era la misma en todos los hallazgos: el backend confiaba en lo que enviaba el cliente. Comprobaba que el usuario hubiera iniciado sesión, pero no que el dispositivo de la petición perteneciera a ese usuario.
Es el fallo grave más frecuente en los productos conectados, y es invisible para los escáneres automáticos, porque cada petición por separado parece legítima.
Qué deberían aprender los fabricantes
- Compruebe la propiedad en cada petición. En el servidor, para cada ID de dispositivo, siempre. No en la app.
- Trate MQTT como una API. Cada cliente solo debe poder publicar y suscribirse en sus propios topics.
- Devuelva solo lo necesario. Si la app no muestra un campo, la API no debería enviarlo.
- Dé por hecho que abrirán el dispositivo. Todo lo que se guarde en él, claves incluidas, acabará leyéndose.
- Pruebe el producto completo. Dispositivo, app y nube juntos. Los peores hallazgos salen de combinarlos.
Con el Cyber Resilience Act, un producto como este no puede comercializarse con vulnerabilidades explotables conocidas, y el fabricante tiene que gestionarlas y notificarlas. Una prueba antes del lanzamiento sale más barata que una retirada después.
¿Quiere saber qué revela su dispositivo? Consulte nuestras pruebas de seguridad IoT, los pentests web y de API o cuánto cuesta una prueba.
FAQ
Preguntas frecuentes
¿Qué son IDOR, BOLA y BFLA?
IDOR (insecure direct object reference) y BOLA (broken object level authorization) describen el mismo problema: el servidor devuelve o modifica un objeto, por ejemplo un dispositivo, porque la petición indica su ID, sin comprobar que pertenece a quien la envía. BFLA (broken function level authorization) significa que un usuario puede invocar funciones pensadas para otro rol, por ejemplo el de administrador.
¿Por qué son tan frecuentes estos fallos en los productos IoT?
Los backends IoT gestionan millones de dispositivos mediante un conjunto reducido de llamadas de API y topics MQTT. Si la comprobación «¿este dispositivo pertenece a este usuario?» falta en un solo punto, todos los dispositivos que hay detrás de esa llamada quedan expuestos. Los escáneres automáticos no lo detectan, porque cada petición es técnicamente válida.