Un investigador descubrió una vulnerabilidad crítica en aspiradoras Shark que permite tomar control remoto de otros dispositivos en la misma región de AWS. Al extraer el certificado de un robot, un atacante puede acceder a la cámara, mapas y contraseñas de Wi-Fi de millones de usuarios. SharkNinja fue notificada en marzo, pero no ha implementado la solución del lado del servidor ni ha emitido un parche.





Si extraes el certificado de la memoria flash de un robot aspirador Shark RV2320EDUS, puedes ejecutar comandos de root en las aspiradoras Shark de otras personas dentro de la misma región de AWS: ver la cámara, conducir el robot, leer el mapa de la casa y obtener la contraseña del Wi-Fi en texto plano.

Un investigador que publica bajo el nombre de tokay0 puso el método en línea aquí el lunes, habiéndolo probado solo con aspiradoras que él mismo compró. El fallo no estaba parcheado entonces.

Afirma que SharkNinja, la empresa detrás de las marcas de electrodomésticos Shark y Ninja, ha tenido su informe desde marzo.

La política adjunta a ese certificado nunca estuvo limitada al dispositivo que lo posee. Presentalo al bróker de la nube de Shark y el bróker aceptará cualquier cosa que publiques, dirigida a cualquier dispositivo que sirva.

Sin corrupción de memoria, sin escalada de privilegios, sin contraseñas que adivinar. El comando que se ejecuta es un campo ordinario en la "sombra del dispositivo", el documento de estado por dispositivo que AWS mantiene en la nube.

Utilizando el certificado de un RV2320EDUS, el investigador se suscribió a $aws/things/# y observó el tráfico que cruzaba el bróker, recolectando números de serie sobre la marcha. Publicar funciona de la misma manera. La sombra contiene un campo Exec_Command que el demonio de gestión appd lee y entrega a una función llamada execute_command, que ejecuta cualquier cosa de menos de 1.000 bytes a través de popen.

Envía una actualización de la sombra que lleve ese campo al tópico de un dispositivo. Si ese dispositivo implementa el manejador, ejecutará el comando.

Demostró la ruta entre diferentes modelos, logrando una shell inversa en un AV1102ARUS que compró puramente como objetivo, y luego usó esa shell para obtener una transmisión en vivo de la cámara integrada del modelo mientras el robot se movía.

El certificado se extrae con un destornillador. La placa base expone pines UART, la consola de U-Boot no pide contraseña e init=/bin/sh en los argumentos de arranque te lleva a una shell de root, donde la clave y el certificado por dispositivo se encuentran en /mnt/res/vapp/certs/ como archivos ordinarios.

Los certificados están anclados a su región de AWS, que es lo más parecido a un límite: una clave extraída en una región solo llega a los dispositivos de esa región. Llegar a otra región requiere otro certificado, provisionado allí y que lleve la misma política defectuosa.

Amazon tiene un control de auditoría para este diseño exacto de política. Device Defender, el servicio de auditoría de flotas IoT de AWS, señala las políticas de dispositivos que conceden publicar o suscribirse en $aws/things/* en lugar de anclar el tópico al dispositivo de conexión con ${iot:Connection.Thing.ThingName}.

Aparece como IOT_POLICY_OVERLY_PERMISSIVE_CHECK, y AWS lo califica como crítico, advirtiendo en su documentación aquí que un certificado comprometido que lleve tal política permite a un atacante "leer o modificar sombras, trabajos o ejecuciones de trabajos para todos tus dispositivos".

No todos los certificados son una llave maestra. Una aspiradora cuyo certificado lleva la política rota es la llave de un atacante. Cualquier aspiradora que ejecute Exec_Command es un objetivo, independientemente de si su propio certificado está delimitado correctamente. El AV1102ARUS es un objetivo y no una llave: su certificado estaba delimitado correctamente y no podía suscribirse mediante comodines. Su firmware era varios años más nuevo.



Él interpreta esto como una corrección de aprovisionamiento que nunca llegó a los certificados de la flota más antigua. Es por eso que la shell entre modelos funcionó, y por qué su afirmación de que cada aspiradora Shark conectada a internet es vulnerable debe dividirse en dos.

El titular de su publicación dice millones. La cifra que verificó es más reducida. Observando una región de AWS durante 24 horas, tokay0 contó 1.517.605 números de serie únicos de Shark, de los cuales 673.816, o el 44%, emitieron un Exec_Response, que él trata como confirmación de que el dispositivo ejecuta el manejador de comandos. Esos son dispositivos observados respondiendo, no dispositivos probados o comprometidos, y afirma que la cifra real probablemente sea mayor.

Cuatro meses y contando

Según el relato de la correspondencia de tokay0, contactó a SharkNinja el 1 de marzo y envió los detalles el 11 de marzo. La empresa acusó recibo al día siguiente, le dijo el 27 de abril que el informe estaba bajo revisión y el 3 de julio dijo que enviaría una fecha de finalización confirmada para el viernes 10 de julio. No llegó ningún correo electrónico.

Publicó el 13 de julio. Dice que el proveedor minimizó la gravedad y cuestionó si "un CVE es apropiado".

En cuanto a los informes de IoT específicamente, la política de divulgación de vulnerabilidades publicada por SharkNinja aquí compromete a la empresa a "proporcionar actualizaciones regulares hasta que la vulnerabilidad reportada sea resuelta". La misma política pide a los investigadores que guarden silencio hasta que la empresa confirme una solución o autorice la divulgación por escrito.

SharkNinja no había publicado nada sobre el fallo hasta el jueves. The Hacker News se ha puesto en contacto con la empresa para comentar el estado del parche y el cronograma de divulgación, y actualizará esta historia con cualquier respuesta.

Tampoco hay ningún CVE. Solicitó un ID al CNA de último recurso de MITRE, el asignador que gestiona las vulnerabilidades que ningún CNA de proveedor cubre, el 11 de junio y no había oído nada en el momento de publicar. Sin identificador, sin CVSS, sin aviso: nada en lo que un programa de gestión de vulnerabilidades pueda basarse.

La solución está en el servidor

La solución no es algo que el propietario deba instalar. Reside en la cuenta de AWS de SharkNinja, no en el firmware del robot. Según la guía de remediación de AWS aquí, una política no conforme se reemplaza mediante el envío de una versión delimitada con CreatePolicyVersion y la bandera setAsDefault, que hace que esa versión sea operativa para cada certificado que use la política.

No se requiere el despliegue de firmware. Reemitir los certificados correctamente, que es lo que tokay0 recomendó en marzo, es la tarea más larga detrás de esto.

Hasta que SharkNinja haga una cosa o la otra, la única mitigación disponible para ti como propietario es desconectar la aspiradora del Wi-Fi. Eso elimina el control por aplicación, la programación y los mapas, y convierte el producto nuevamente en una aspiradora.

tokay0 retuvo sus scripts mientras el fallo esté activo. Consideró que sus otros hallazgos eran demasiado menores para escribirlos.

Tampoco examinó el resto de la línea de productos conectados de SharkNinja, como las parrillas inteligentes y las sondas de carne inalámbricas, que según él probablemente también sean vulnerables. Esos productos provienen de la misma empresa cuya política promete actualizaciones regulares hasta que se resuelva un fallo. Cuatro meses después, este sigue sin resolverse.

Fuente:
THN