Treo Blog

  • Isabela Garcia Salazar

90 días, 16 errores y un desafío Azure Sphere


Cisco Talos informa 16 vulnerabilidades en el desafío de investigación patrocinado por Microsoft Azure Sphere.


El 15 de mayo de 2020, Microsoft lanzó el Desafío de investigación de seguridad de Azure Sphere , una iniciativa de tres meses destinada a encontrar errores en Azure Sphere . Entre los equipos y las personas seleccionadas, Cisco Talos llevó a cabo una investigación de tres meses en la plataforma e informó de 16 vulnerabilidades de diversa gravedad, incluida una cadena de errores de escalada de privilegios para adquirir Azure Sphere Capabilities, los permisos de Linux del mundo normal más valiosos en el mundo. Contexto de Azure Sphere. 


La plataforma Azure Sphere es una plataforma SoC personalizada y conectada a la nube diseñada específicamente para la seguridad de las aplicaciones de IoT. Internamente, el SoC se compone de un conjunto de varios núcleos ARM que tienen diferentes roles (por ejemplo, ejecutar diferentes tipos de aplicaciones, hacer cumplir la seguridad y administrar el cifrado). Externamente, la plataforma Azure Sphere es compatible con Azure Cloud de Microsoft, que maneja actualizaciones seguras, implementación de aplicaciones y verificación periódica de la integridad del dispositivo para determinar si se debe permitir o no el acceso a Azure Cloud. Sin embargo, tenga en cuenta que, si bien Azure Sphere se actualiza y se implementa a través de Azure Cloud, los clientes aún pueden interactuar con sus propios servidores de forma independiente.


Los clientes envían aplicaciones firmadas a sus dispositivos agrupados en un inquilino en la nube de Azure Sphere (o se descargan si están en modo de desarrollo) y se les otorgan permisos extremadamente limitados de forma predeterminada. Para utilizar funciones básicas como conectarse a una dirección IP o nombre de host, almacenar datos en el disco o incluso retrasar las actualizaciones de software, una aplicación determinada debe predefinir estas necesidades dentro de su app_manifest.json . Materialmente, estas definiciones hacen que el ID de usuario (UID) de la aplicación (que es diferente en cada instalación) reciba ID de grupo de Linux (GID) específicos y / o las capacidades de Linux necesarias para interactuar con la función solicitada. 


Al reducir el zoom, todas las aplicaciones del sistema ( networkd , azcore , azured , etc.) tienen capacidades específicas de Linux y / o Azure Sphere para limitar su acceso solo a lo que necesitan. Estas capacidades de Azure Sphere, almacenadas y tratadas de manera diferente a las capacidades normales de Linux, limitan el acceso a interfaces críticas específicas de Azure Sphere y, en su mayor parte, se utilizan para limitar el acceso específicamente a las ioctls de / dev / pluton y / dev / security-monitor . Es en estos dos dispositivos donde encontramos la funcionalidad más crítica, la ejecución en estos dos dispositivos se considera los permisos más altos que se pueden obtener en el dispositivo. 


Dado que la plataforma Azure Sphere está diseñada como un entorno de IoT seguro en el que los clientes pueden actualizar aplicaciones arbitrarias (de menos de ~ 600 KB de tamaño), la pregunta más relevante para el ASSRC fue: "Suponiendo que una aplicación del cliente se haya visto comprometida y se haya ganado la ejecución del código, ¿Qué se puede hacer desde allí? " Esto se refleja en el alcance oficial del desafío :


  • Capacidad para ejecutar código en Pluton.

  • Capacidad para ejecutar código en Secure World (monitor de seguridad).

  • Capacidad para ejecutar código en NetworkD a través de un ataque local (aplicación del cliente comprometida) o de forma remota (red externa).

  • Cualquier cosa que permita la ejecución de código sin firmar que no sea pura programación orientada al retorno (ROP) en Linux.

  • Cualquier cosa que permita la elevación de privilegios fuera de las capacidades descritas en el manifiesto de la aplicación (por ejemplo, cambiar el ID de usuario, agregar acceso a un binario).

  • Capacidad para modificar el software y las opciones de configuración (excepto el restablecimiento completo del dispositivo) en un dispositivo en el estado de fabricación DeviceComplete cuando se solicita a un inquilino en el que no ha iniciado sesión y no tiene capacidades guardadas.

  • Capacidad de alterar el firewall permitiendo la comunicación con otros dominios que no están en el manifiesto de la aplicación (nota: no envenenamiento de DNS).

Retrospectiva de los investigadores:


Azure Sphere fue un dispositivo interesante para trabajar debido a las restricciones impuestas al dispositivo, tanto en especificaciones como en seguridad. Mostramos un paquete de imágenes.de busybox para tener una idea decente de los componentes internos del dispositivo antes de configurar una instancia QEMU incompleta que se usó principalmente para pruebas más profundas del kernel. Para todo lo relacionado con otros núcleos o chips del dispositivo, nos basamos principalmente en la actualización de programas C y gdbserver para las pruebas; El uso de herramientas prefabricadas no parecía útil ni eficiente en el tiempo, tanto por la naturaleza compleja como por las especificaciones limitadas del chipset y el entorno. Incluso una tarea simple como ejecutar strace dentro de busybox no fue un esfuerzo trivial ya que no había espacio para caber ambos binarios, el espacio para aplicaciones de usuario está limitado a alrededor de 600KB. En el contexto de tiempo limitado de ASSRC, mantener nuestras herramientas simples ayudó significativamente a llegar a los errores rápidamente. Nuestra caja de herramientas era básicamente tmux, Vim, Binary Ninja, QEMU (eventualmente), Con respecto al ASSRC en sí, sentimos la doble faceta de las actualizaciones mensuales (pero a veces más rápidas) y tener alrededor de 70 personas mirando el producto simultáneamente terminó favoreciendo a aquellos que podían trabajar más rápido y con menos herramientas. Ir por los objetivos de valor extremadamente alto (pluton / monitor de seguridad) estrictamente no se puede hacer sin tener una configuración de emulación o una cadena de escalada de privilegios, los cuales son grandes pérdidas de tiempo en el contexto de una competencia de tres meses (concedido, también estaba disponible una tercera opción, con la esperanza de que Microsoft aceptara un error "Suponiendo que tenga capacidad XYZ ..."). Y así, cuando llegó 20.07, todas las cadenas de escalada de privilegios se rompieron y ya no hay forma de probar dinámicamente pluton o monitor de seguridad. Para ser justos, debemos afirmar que las actualizaciones mensuales son parte del modelo de seguridad de Azure Sphere que mantiene el dispositivo actualizado con los últimos parches de seguridad. En nuestra opinión, si bien esta táctica funciona muy bien para corregir los errores conocidos rápidamente, también da como resultado un examen mucho menos completo del dispositivo de lo que podría haber sido posible, debido a que los investigadores están discapacitados de una manera que un atacante nunca lo estaría. Los objetivos reportados de menor valor se arreglaban periódicamente, dejando a los investigadores en repetidas ocasiones para encontrar nuevas rutas hacia los problemas de nivel superior. Postulamos que este tipo de CTF daría como resultado que todos se volvieran aficionados a objetivos colgantes bajos, dejando las superficies de ataque de mayor nivel y más críticas sin examinar. Como pensamiento de despedida, nos gustaría agradecer a los organizadores del evento y también al personal técnico de Azure Sphere que fueron de gran ayuda en esta colaboración. Si bien hubo dificultades en este proceso con respecto a conceptos de nivel superior (por ejemplo, la coherencia de las respuestas de envío de errores, tanto en calidad como en prisa), consideramos que el ASSRC ha sido una experiencia positiva general y una bendición para la postura de seguridad de la plataforma Azure Sphere como un todo. 

Bibliografia: https://blog.talosintelligence.com/2020/10/Azure-Sphere-Challenge.html



4 vistas
D&S colores.png

Un Servidor en Quien Confiar

Servicio al cliente:

contactodirecto@datayservice.com

PBX + 57 6 8812277

Calle 54 # 26-60

ZIP 170004

Manizales, Colombia

Peticiones quejas y reclamos:

pqr.datayservice@datayservice.com

 

 © Data&Service, todos los derechos reservados.