Azure AD & IAM (Part III) – Leveraging Managed Identities for Privilege Escalation

Published:

Jan 04, 2022

Reading time:

5 Minutes

Hopefully you’ve been following along with this mini blog series as we’ve explored Azure AD and IAM basics and my research on leveraging managed identities for privilege escalation. In this blog post, I  share my research on user-assigned managed identities.

Escalation using user-assigned managed identities

In this scenario, I wondered if I can abuse user-assigned managed identities to elevate privileges from the Resource Group level to the Subscription level. In which cases can privileged users in the Resource Group escape to other Resource Groups?

As I found out, user-assigned managed identity is a unique type of resource. It is created in the Resource Group scope but can be assigned to roles outside of this scope. Managed identities are built on top of Service Principals objects in Azure AD, so they can be assigned to a role in every subscription in a tenant.  

The legitimate usage is clear. It is a very convenient way to allow an application to access resources in another subscription such as storage or secrets. But can it be abused? In theory, it means that if I start with the right user I might be able to escalate to another Resource Groups and even to another Subscription.

To validate my theory, I created a user-assigned managed identity in Orca-Security Resource Group. I named it “orca-poc-uami” and assigned to it a contributor role in the subscription level. 

In addition, I created a user named Adam and assigned him a contributor role in Orca-Security Resource Group. Assuming Adam’s credentials have been leaked, can the attacker escape from the Orca-Security Resource Group?

First, let’s verify that Adam doesn’t have permissions to list storage accounts outside of Orca-Security Resource Group.

After validating the permissions, let’s see if we can use a managed identity to escalate.

When creating Role Assignment, which involves managed identity, the role is assigned to the Service Principal instead of the managed identity itself.

Detecting a usable Role Assignment consists of two stages. 

  1. Find a Role Assignment that contains a Service Principal with high privileges. It’s important to examine Role Assignment, which involves permissive roles such as owner and contributor, and to examine role assignment with permissive scope such as subscription scope.
  2. Connect between the Service Principal to the managed identity. Keep in mind that a Service Principal is not always linked to a managed identity.

There is a Role Assignment for “orca-poc-uami” at the Subscription level. 

To use it, we can create any resource that supports managed identities. I have chosen to use Logic Apps for convenience, due to the versatility of the http action.

Let’s create a Logic App and assign to it the “orca-poc-uami” identity. To add the user-assigned managed identity, we add the following authentication header to the workflow:

​​"authentication": {
"audience": "https://pocprivatesa.blob.core.windows.net",
"identity": "/subscriptions/aaaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeee/resourcegroups/orca-security/providers/microsoft.managedidentity/userassignedidentities/orca-poc-uami",
"type": "ManagedServiceIdentity"
}

And there it is, our new workflow.

Now, let’s see if we can enumerate the storage containers in “pocprivatesa” storage account, which is another Resource Group in the subscription.

And there it is, Adam, our test user can access resources outside the Orca-Security resource group. Actually, he has permissions to the entire subscription. This technique is very handy to attackers when trying to escalate privileges in an Azure environment.

After finding this, I reported my findings to MSRC who called it a by-design behavior. Their response:

The purpose of managed identity is to give code running on an Azure resource access to other resources, without developers needing to handle or put credentials directly into code to get that access. As you point out in your comment about Website Contributor, it’s important to be thoughtful when granting access that lets people install/upload/add code that can use the managed identity. It is also worth mentioning that it is just as important to be thoughtful when assigning a role to a managed identity to grant it access to resources. It is unlikely a managed identity needs a Contributor role assignment at subscription scope to get its job done. It should be granted the minimum amount of access necessary (e.g., read/write access to a specific Storage account) to accomplish its task.

Configure your permissions according to the least privileges principle is the best defense mechanism here. It is important, especially because we understand this attack vector is here to stay.

Managed-Identities open a very broad attack surface once they’re configured wrong.

Summary

My research on Azure AD and IAM demonstrated how three of the core services in Azure could be abused to escalate privileges from low-privileged roles to managed identities privileges. I also provided a useful technique to escape from a Resource Group boundary using user-assigned managed identities.

That brings us to the question: what should you do next? I’ve got you covered. I wrote ManagedIdentityExplorer, an open-source tool that you can download from GitHub to help you find these weaknesses in your environment.

ManagedIdentityExplorer detects User-Assigned Managed-Identity with extensive permissions in the subscription level and the techniques I presented in the second blog in the series.