Abusing Azure Managed Identity tokens is surprisingly easy when your environment isn’t configured correctly. But what does ‘correct configuration’ entail? What risks are you exposed to, and what can these tokens achieve? Most importantly, how can you safeguard your data against such threats? Please find all the answers in my comprehensive article!
Abusing Azure Managed Identity tokens – generation
Utilizing Azure Managed Identity offers significant advantages: no need for managing credentials, the ability to assign roles easily, and seamless integration. However, there’s an important aspect to consider: as a user, you can access the Managed Identity token if you have the necessary permissions. But what exactly are these permissions? Let’s delve into the details:
- For built-in roles, you need to be a member of one of the following: Website Contributor, Contributor, or Owner.
- For custom roles, the required permission is the resource provider operation:
Microsoft.Web/sites/publish/Action.
The token generation process itself is straightforward. It involves opening SSH for Azure App Service and executing specific commands, which we will explore next.
tokenUriApi="$IDENTITY_ENDPOINT?resource=#RESOURCE_ID#&api-version=2019-08-01"
curl $tokenUriApi -H "X-IDENTITY-HEADER:$IDENTITY_HEADER"
Locating the RESOURCE_ID is a crucial step in managing Azure Managed Identity tokens. To find this, navigate to Entra ID, then proceed to Enterprise Applications. Here, you will find the specific resource for which you need a token. For detailed instructions, refer to the image provided below.
Upon executing the appropriate CURL command, you will receive an access_token for Azure Managed Identity. This token is vital for authorization purposes, particularly when interacting with Azure services via REST API calls. For instance, you can utilize this token to list all containers within an Azure Storage account.
curl --location 'https://#STORAGE_ACCOUNT_NAME#.blob.core.windows.net/?comp=list' \
--header 'x-ms-version: 2020-04-08' \
--header 'Authorization: Bearer #ACCESS_TOKEN#'Replace STORAGE_ACCOUNT_NAME and ACCESS_TOKEN with proper values.
Abusing Azure Managed Identity tokens – uses cases
The misuse of Azure Managed Identity tokens can pose significant security risks. Consider the following scenarios:
- Unauthorized Permission Elevation: Imagine a developer who lacks access to Azure Key Vault or other specific resources. If they hold a ‘Contributor’ role, they could potentially obtain a token for Managed Identity. This token might grant them access to resources beyond their authorized scope, effectively elevating their permissions inappropriately.
- Exploitation of Compromised Services: Consider an Azure App Service that has been compromised. If the Managed Identity is set with ‘Owner’ permissions, and the service is accessed by someone with ‘Contributor’ rights, they could use the token to perform unrestricted actions on your resources. This scenario illustrates how elevated permissions in Managed Identity can be exploited if your service is hacked.
These examples underscore the importance of carefully managing permissions and roles within Azure to prevent unauthorized access and potential security breaches.
How to secure?
Prioritizing security in Azure Managed Identity begins with adhering to the principle of least privilege. This fundamental approach ensures that identities are granted only the permissions they need to perform their tasks, reducing the risk of unauthorized access and potential security breaches.
In addition to this, securing SCM (Source Control Management) is vital. Restricting access to SSH is a key step in this process. How can this be achieved? There are primarily two methods:
- Creation of a Custom Role: This involves designing a role that specifically denies access to SCM (Advanced Tools/Kudu). Below, you’ll find a detailed definition for a custom role named ‘Contributor_no_scm’, which restricts access to SCM, providing an added layer of security.
{
"id": "/subscriptions/#SUBSCRIPTION_ID#",
"properties": {
"roleName": "Contributor_no_scm",
"description": "",
"assignableScopes": [
"/subscriptions/#SUBSCRIPTION_ID#"
],
"permissions": [
{
"actions": [
"*"
],
"notActions": [
"Microsoft.Authorization/*/Delete",
"Microsoft.Authorization/*/Write",
"Microsoft.Authorization/elevateAccess/Action",
"Microsoft.Blueprint/blueprintAssignments/write",
"Microsoft.Blueprint/blueprintAssignments/delete",
"Microsoft.Compute/galleries/share/action",
"Microsoft.Purview/consents/write",
"Microsoft.Purview/consents/delete",
"Microsoft.Web/sites/publish/Action"
],
"dataActions": [],
"notDataActions": []
}
]
}
}Please replace #SUBSCRIPTION_ID# with your actual subscription ID value. This step is essential to customize the settings according to your specific Azure environment.
Once you’ve updated this information, users assigned to the role mentioned above will receive the following response:
- Access Restrictions for SCM/Kudu: Protect your SCM/Kudu with network rules. You need to navigate to the App Service -> Networking -> Inbound traffic configuration. Then you need to set network rules as presented below:
Summary
In this article, I examined the potential for abuse of Azure Managed Identity tokens. I demonstrated how easily these tokens can be acquired and misused for unauthorized access to data, highlighting a significant security loophole in Azure environments. My findings underscore the importance of robust security measures, particularly in managing token access and control, to safeguard against such vulnerabilities.
I truly hope you found it enjoyable, and if that’s the case, I would be grateful for a Like or a Comment on my LinkedIn profile.