Una vez que haya actualizado el certificado en su robot aspirador Shark RV2320EDUS, podrá ejecutar comandos raíz en los aspiradores Shark de otras personas en la misma región de AWS. Supervise cámaras, conduzca robots, lea mapas de su hogar y capture contraseñas de Wi-Fi en texto sin formato.
El investigador, que publica bajo el nombre de tokay0, probó el método sólo en aspiradoras que compró él mismo y publicó el método en línea el lunes. En ese momento el defecto no había sido solucionado.
Dijo que SharkNinja, la compañía detrás de las marcas de electrodomésticos Shark y Ninja, había estado presentando su informe desde marzo.
La política adjunta a ese certificado nunca tuvo como alcance el dispositivo que lo posee. Lo presenta al corredor en la nube de Shark y el corredor acepta cualquier cosa publicada que esté dirigida a los dispositivos a los que sirve.
Sin corrupción de memoria, escalada de privilegios ni adivinación de contraseñas. Los comandos que se ejecutan son campos regulares en la sombra del dispositivo, que es un documento de estado por dispositivo que AWS mantiene en la nube.
Los investigadores utilizaron el certificado de RV2320EDUS para suscribirse a $aws/things/# y monitorear el tráfico que pasa a través del corredor, recopilando números de serie a medida que avanzaban. La publicación funciona de manera similar. La sombra tiene un campo Exec_Command que el demonio de administración appd lee y pasa a una función llamada ejecutar_command que ejecuta cualquier cosa menor a 1000 bytes a través de popen.
Envíe una actualización paralela que contenga ese campo al tema del dispositivo. Si ese dispositivo implementa el controlador, se ejecuta el comando.
Demostró el paso entre los modelos colocando un proyectil inverso en un AV1102ARUS, que había comprado únicamente como objetivo, y usando ese proyectil para obtener una transmisión en vivo desde la cámara a bordo del modelo mientras el robot estaba en funcionamiento.
El certificado se puede quitar con un destornillador. La placa base expone los pines UART y la consola U-Boot no solicita una contraseña. El argumento de arranque init=/bin/sh muestra el shell raíz. El shell raíz almacena claves y certificados por dispositivo como archivos normales en /mnt/res/vapp/certs/.
El certificado está fijado a una región de AWS, pero es la más cercana al límite. Esto significa que las claves desbloqueadas en una región solo llegan a los dispositivos de esa región. Cuando llegue a otra región, se le proporcionará otro certificado allí y conservará la misma política incumplida.
Amazon tiene controles de auditoría para este estilo de política exacto. Device Defender, el servicio de auditoría de flotas de IoT de AWS, marca políticas de dispositivos que permiten publicar o suscribirse a $aws/things/* en lugar de fijar temas a dispositivos conectados mediante ${iot:Connection.Thing.ThingName}.
Esto aparece como IOT_POLICY_OVERLY_PERMISSIVE_CHECK, y AWS lo califica como crítico, advirtiendo en la documentación que un certificado comprometido que lleve dicha política permitiría a un atacante «leer o modificar sombras, trabajos o ejecución de trabajos en cualquier dispositivo».
No todos los certificados son claves maestras. Un vacío con una política incumplida en el certificado es la clave del atacante. Se seleccionará un vacío que ejecute Exec_Command independientemente de si su propio certificado tiene el alcance correcto. AV1102ARUS es un objetivo, no una clave. Ese certificado tenía el alcance correcto y no se podía suscribir comodín. El firmware era nuevo hace varios años.
Leyó que se trataba de una solución de aprovisionamiento que no alcanzaba los certificados para flotas más antiguas. Es por eso que el modelo cruzado funcionó, y por qué su afirmación de que todas las aspiradoras Shark conectadas a Internet son vulnerables debe dividirse en dos.
El encabezado de su publicación dice millones. Los números que probó son aún más reducidos. tokay0 supervisó una región de AWS durante 24 horas y contó 1.517.605 números de serie únicos de Shark. De ellos, 673.816, o el 44%, emitieron una Exec_Response. Trata esto como una confirmación de que el dispositivo está ejecutando el controlador de comandos. Estos son dispositivos que se observaron respondiendo, no dispositivos que fueron probados o comprometidos, y el número real probablemente sea mayor, dijo.
A partir del 4to mes
Según los registros de comunicaciones de tokay0, se comunicó con SharkNinja el 1 de marzo y envió los detalles el 11 de marzo. La empresa acusó recibo al día siguiente, le informó el 27 de abril que el informe estaba bajo revisión y anunció el 3 de julio que enviaría una fecha de finalización de confirmación antes del viernes 10 de julio. El correo electrónico no llegó.
Publicó este artículo el 13 de julio. El proveedor restó importancia a la gravedad y dijo que cuestionaba «si CVE es apropiado».
Específicamente con respecto a los informes de IoT, la política de divulgación de vulnerabilidades publicada por SharkNinja promete que la compañía «proporcionará actualizaciones periódicas hasta que se resuelvan las vulnerabilidades reportadas». La política exige que los investigadores guarden silencio hasta que la empresa confirme la enmienda o autorice la divulgación por escrito.
SharkNinja no había revelado nada sobre la falla hasta el jueves. Hacker News se comunicó con la compañía para comentar sobre el estado del parche y el calendario de divulgación y actualizará este artículo si recibimos una respuesta.
Tampoco hay CVE. El 11 de junio, solicitó la identificación al CNA de último recurso de MITRE, un cedente que maneja vulnerabilidades no cubiertas por el proveedor CNA, pero no había recibido respuesta al momento de su revelación. No hay identificadores, CVSS ni recomendaciones. Nada importante para un programa de gestión de vulnerabilidades.
Las modificaciones se realizan en el lado del servidor.
Las correcciones no las instala el propietario. Esto no está en el firmware del robot; reside en la cuenta de AWS de SharkNinja. Según la guía de corrección de AWS, las políticas que no cumplen con las normas se reemplazan mediante la implementación de una versión con alcance utilizando los indicadores CreatePolicyVersion y setAsDefault. Esto garantiza que la versión funcione con todos los certificados que utilizan la política.
No se requiere implementación de firmware. La correcta reemisión de los certificados, que tokay0 recomendó en marzo, es una tarea más larga.
Hasta que SharkNinja haga algo, la única mitigación disponible para los propietarios es desconectar la aspiradora del Wi-Fi. La aplicación ya no está controlada, programada ni asignada y el producto vuelve al vacío.
tokay0 ha suspendido el script mientras existe el defecto. Decidió que otros descubrimientos eran demasiado ligeros para escribir sobre ellos.
No ha examinado el resto de la línea conectada de SharkNinja, incluida la parrilla inteligente y la sonda inalámbrica para carne, que, según él, probablemente también sean vulnerables. Estos productos proceden de la misma empresa, cuya política es actualizarlos periódicamente hasta solucionar los defectos. Han pasado 4 meses y esta vez no es así.
Source link
