Cisco Talos reports 16 vulnerabilities in Microsoft Azure

90 days, 16 bugs, and an Azure Sphere Challenge

Cisco Talos reports 16 vulnerabilities in Microsoft Azure Sphere's sponsored research challenge.
By Claudio Bozzato, Lilith [-_-]; and Dave McDaniel.
On May 15, 2020, Microsoft kicked off the Azure Sphere Security Research Challenge, a three-month initiative aimed at finding bugs in Azure Sphere. Among the teams and individuals selected, Cisco Talos conducted a three-month sprint of research into the platform and reported 16 vulnerabilities of various severity, including a privilege escalation bug chain to acquire Azure Sphere Capabilities, the most valuable Linux normal-world permissions in the Azure Sphere context. The Azure Sphere platform is a cloud-connected and custom SoC platform designed specifically for IoT application security. Internally, the SoC is made up of a set of several ARM cores that have different roles (e.g. running different types of applications, enforcing security, and managing encryption). Externally, the Azure Sphere platform is supported by Microsoft’s Azure Cloud, which handles secure updates, app deployment, and periodic verification of device integrity to determine if Azure Cloud access should be allowed or not. Note however, that while the Azure Sphere is updated and deploys through the Azure Cloud, customers can still interact with their own servers independently.Customers push signed applications to their devices grouped in an Azure Sphere Cloud Tenant (or sideload if in development mode), and are granted with extremely limited permissions by default. To use such basic features as connecting to an IP address or hostname, storing any data to disk, or even delaying software updates, a given application must pre-define these needs inside their app_manifest.json. Materially, these definitions cause the user ID (UID) of the application (which is different on every installation) to be granted specific Linux group IDs (GIDs) and/or the Linux capabilities needed to interact with the requested feature. Zooming out, all system applications (networkd, azcore, azured, etc.) have specific Linux and/or Azure Sphere capabilities to limit their access to only what they need. These Azure Sphere capabilities, stored and treated differently than normal Linux capabilities, limit access to critical Azure Sphere-specific interfaces and for the most part are used to limit access specifically to the ioctls of /dev/pluton and /dev/security-monitor. It's in these two devices that we find the most critical functionality, execution in these two devices is considered the highest permissions one can gain on the device. Here’s a simplified logical chart of the system:

Since the Azure Sphere platform is designed as a secure IoT environment in which customers can flash arbitrary applications (less than ~600KB in size), the most relevant question for the ASSRC was: "Assuming a customer application has been compromised and code execution gained, what can be done from there?" This is reflected in the official scope for the challenge:

Ability to execute code on Pluton.

Ability to execute code on Secure World (security-monitor).

Ability to execute code on NetworkD through local attack (compromised customer application) or remotely (external network).

Anything allowing execution of unsigned code that isn’t pure return oriented programming (ROP) under Linux.

Anything allowing elevation of privilege outside of the capabilities described in the application manifest (e.g. changing user ID, adding access to a binary).

Ability to modify software and configuration options (except full device reset) on a device in the manufacturing state DeviceComplete when claimed to a tenant you are not signed into and have no saved capabilities for.

Ability to alter the firewall allowing communication out to other domains not in the app manifest (note: not DNS poisoning).

For the purposes of this writeup, we will separate the 16 vulnerabilities by the above in-scope categories, and will also have a section for denial-of-service vulnerabilities which were not considered in scope (no matter the severity or if they were required for other bug chains or not). ConclusionDuring the course of the three-month Azure Sphere Security Research Challenge, Cisco Talos found and reported 16 vulnerabilities in the Azure Sphere platform, (TALOS-2020-1141 is not yet fixed so it remains unpublished). For an in-depth look into each of the vulnerabilities, please refer to the individual vulnerability writeups listed above for more information.Read the full report here: blog.talosintelligence.com