Una falla en la aspiradora Shark sin parches podría permitir a los atacantes controlar otras aspiradoras en toda la región – CYBERDEFENSA.MX
Retire el certificado del flash de un robot aspirador Shark RV2320EDUS y podrá ejecutar comandos raíz en los aspiradores Shark de otras personas en la misma región de AWS: mire la cámara, conduzca el robot, lea el mapa de la casa y tome la contraseña de Wi-Fi en texto plano.
Un investigador que publica bajo el nombre tokay0 poner el método en línea el lunes, después de haberlo probado sólo con aspiradoras que compró él mismo. El defecto no se solucionó entonces.
Dice que SharkNinja, la compañía detrás de las marcas de electrodomésticos Shark y Ninja, ha recibido su informe desde marzo.
La política adjunta a ese certificado nunca tuvo como alcance el dispositivo que lo posee. Preséntelo al corredor en la nube de Shark y el corredor aceptará todo lo que publique, dirigido a cualquier dispositivo al que sirva.
Sin corrupción de memoria, sin escalada de privilegios, sin contraseña que adivinar. El comando que se ejecuta es un campo normal 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 corredor, recopilando números de serie a medida que avanzaba. La publicación funciona de la misma manera. La sombra lleva un campo Exec_Command que el demonio de administración appd lee y entrega a una función llamada ejecutar_command, que ejecuta cualquier cosa de menos de 1000 bytes a través de popen.
Envíe una actualización paralela que lleve ese campo al tema de un dispositivo. Si ese dispositivo implementa el controlador, ejecuta el comando.
Probó el camino entre modelos, colocando un proyectil inverso en un AV1102ARUS que compró simplemente como objetivo, y luego usó ese proyectil para obtener una transmisión en vivo de la cámara integrada del modelo mientras el robot conducía.
El certificado se quita con un destornillador. La placa base expone los pines UART, la consola U-Boot no solicita contraseña e init=/bin/sh en los argumentos de arranque lo lleva a un shell raíz, donde la clave por dispositivo y el certificado se encuentran en /mnt/res/vapp/certs/ como archivos normales.
Los certificados están fijados a su región de AWS, lo más parecido aquí a un límite: una clave levantada en una región solo llega a los dispositivos de esa región. Para llegar a otra región se necesita otro certificado, aprovisionado allí, y que lleva la misma política rota.
Amazon tiene una verificación de auditoría para esta forma de política exacta. Device Defender, el servicio de auditoría de flotas de IoT de AWS, marca políticas de dispositivos que permiten publicar o suscribirse en $aws/things/* en lugar de fijar el tema al dispositivo que se conecta con ${iot:Connection.Thing.ThingName}.
Aparece como IOT_POLICY_OVERLY_PERMISSIVE_CHECK y AWS lo califica como crítico, advirtiendo en su documentacion que un certificado comprometido que lleva dicha política permite a un atacante «leer o modificar sombras, trabajos o ejecuciones de trabajos para todos sus dispositivos».
No todos los certificados son una clave maestra. Un vacío cuyo certificado lleva la política rota es la clave de un atacante. Cualquier vacío que ejecute Exec_Command es un objetivo, independientemente de si su propio certificado tiene el alcance correcto o no. El AV1102ARUS es un destino y no una clave: su certificado tenía el alcance correcto y no se pudo realizar una suscripción comodín. Su firmware era varios años más nuevo.
Él lo interpreta como una solución de aprovisionamiento que nunca alcanzó los certificados de la flota más antigua. Es por eso que el modelo cruzado 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 estrecha. Al observar 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 considera como una confirmación de que el dispositivo ejecuta el controlador de comandos. Se trata de dispositivos observados respondiendo, no dispositivos probados o comprometidos, y dice que el número real probablemente sea mayor.
Cuatro meses y contando
Según el relato de la correspondencia de tokay0, se comunicó con SharkNinja el 1 de marzo y envió detalles el 11 de marzo. La compañía 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.
Lo publicó el 13 de julio. Dice que el proveedor minimizó la gravedad y cuestionó si «un CVE es apropiado».
En lo que respecta específicamente a los informes de IoT, SharkNinja publicó política de divulgación de vulnerabilidades compromete a la empresa a «proporcionar actualizaciones periódicas hasta que se resuelva la vulnerabilidad informada». La misma política pide a los investigadores que permanezcan en silencio hasta que la empresa confirme una solución o autorice la divulgación por escrito.
SharkNinja no había publicado nada sobre el defecto hasta el jueves. The Hacker News se comunicó con la compañía para comentar sobre el estado del parche y el cronograma de divulgación, y actualizará esta historia con cualquier respuesta.
Tampoco hay CVE. Le pidió una identificación al CNA de último recurso de MITRE, el asignador que maneja las vulnerabilidades que ningún proveedor cubre, el 11 de junio y no había escuchado nada cuando publicó. Sin identificador, sin CVSS, sin aviso: nada que un programa de gestión de vulnerabilidades pueda ingresar.
La solución está en el lado del servidor
La solución no la debe instalar el propietario. Vive en la cuenta AWS de SharkNinja, no en el firmware del robot. Según AWS guía de remediaciónuna política que no cumple se reemplaza al enviar una versión con alcance con CreatePolicyVersion y el indicador setAsDefault, lo que hace que esa versión sea operativa para todos los certificados que usan la política.
No se requiere implementación de firmware. Reemitir los certificados correctamente, algo que tokay0 recomendó en marzo, es el trabajo más largo que hay detrás.
Hasta que SharkNinja haga una u otra cosa, la única mitigación disponible para el propietario es desconectar la aspiradora del Wi-Fi. Esto pone fin al control de aplicaciones, la programación y los mapas, y convierte el producto nuevamente en un vacío.
tokay0 retuvo sus guiones mientras la falla esté activa. Consideró que sus otros hallazgos eran demasiado menores para escribirlos.
Tampoco examinó el resto de la línea conectada de SharkNinja, las parrillas inteligentes y las sondas inalámbricas para carne, que, según él, probablemente también sean vulnerables. Esos productos provienen de la misma empresa cuya política promete actualizaciones periódicas hasta que se resuelva una falla. Cuatro meses después, éste no lo es.
