El hallazgo y su alcance
Un investigador que utiliza el alias tokay0 publicó el lunes un método para explotar una vulnerabilidad en aspiradoras robóticas Shark que permite a un atacante obtener control remoto de otros dispositivos de la misma marca en toda una región de AWS. El fallo, que aún no ha sido parcheado, fue reportado a SharkNinja, fabricante de las marcas Shark y Ninja, en marzo pasado.
La vulnerabilidad reside en la política de certificados utilizada por los dispositivos para autenticarse ante el broker de AWS IoT. El certificado extraído de una aspiradora Shark RV2320EDUS permite suscribirse y publicar en cualquier tema (topic) del broker, sin restricciones al dispositivo en cuestión. Esto permite al atacante ejecutar comandos remotos en cualquier otro dispositivo mediante el campo Exec_Command en el shadow (estado en la nube) del dispositivo objetivo.
tokay0 demostró la explotación cruzada de modelos: utilizando el certificado de una RV2320EDUS, obtuvo una shell inversa en una AV1102ARUS, y desde allí accedió a la cámara del robot en tiempo real mientras se desplazaba. El investigador indicó que durante 24 horas de monitoreo en una región de AWS, contabilizó 1.517.605 identificadores únicos de Shark, de los cuales 673.816 (44%) emitían un Exec_Response, lo que sugiere que ejecutan el manejador de comandos.
Extracción del certificado
Extraer el certificado es sencillo: basta con abrir el robot con un destornillador, acceder a la placa principal mediante pines UART y la consola U-Boot (que no solicita contraseña), y modificar los argumentos de arranque para obtener una shell root. Los archivos de clave y certificado se encuentran en /mnt/res/vapp/certs/ como archivos de texto plano.
Una vulnerabilidad de configuración en la nube
El fallo no es de firmware, sino de la política de IoT en AWS. AWS ofrece una comprobación automática denominada IOT_POLICY_OVERLY_PERMISSIVE_CHECK, que AWS clasifica como crítica y que señala exactamente este tipo de política. La corrección consiste en modificar la política en la nube para restringir el acceso al tema del dispositivo específico, sin necesidad de actualizar el firmware de los robots.
SharkNinja fue notificado el 1 de marzo y recibió los detalles completos el 11 de marzo. La empresa acusó recibo al día siguiente, el 27 de abril informó que el informe estaba en revisión, y el 3 de julio prometió una fecha de finalización para el 10 de julio. No hubo respuesta. El investigador publicó el fallo el 13 de julio. SharkNinja no se ha pronunciado públicamente sobre el parche ni el cronograma de divulgación.
El investigador afirmó que SharkNinja minimizó la gravedad del problema y cuestionó si era apropiado asignar un CVE.
Hasta el momento no se ha asignado un identificador CVE. tokay0 solicitó uno al CNA de último recurso de MITRE el 11 de junio, pero no recibió respuesta antes de su publicación. Esto impide que los programas de gestión de vulnerabilidades puedan hacer seguimiento del fallo.
Mitigación
La única mitigación disponible para los usuarios es desconectar la aspiradora de la red Wi-Fi, lo que desactiva el control por aplicación, la programación y los mapas, reduciendo el dispositivo a una aspiradora convencional. El investigador no ha publicado sus scripts mientras el fallo esté activo, y advierte que otros productos conectados de SharkNinja, como parrillas inteligentes y sondas de carne inalámbricas, probablemente también sean vulnerables.
Deja una respuesta