Elevating Privileges Through Azure Policy

Introduction

During the past few months, I have had the opportunity to explore numerous Azure services, understanding their purposes, how they can be used, and the use cases they address.
Azure Policy frequently comes into play when assessing whether the deployed resources align with defined rules (compliance, security, data sovereignty, etc.). For instance, a company policy could require that the diagnostic settings need to be enabled for all SQL servers to send their logs to a designated log analytics workspace. Azure Policy may be used to efficiently check if this requirement is being met or to adjust the setting by adding or changing resources to the proper value.
I conducted independent experiments and uncovered an approach that involves using Azure Policy not as a defensive tool, but as a means to escalate privileges within the Azure environment.
Several effects can be applied when using Azure Policy (cfr. https://learn.microsoft.com/en-us/azure/governance/policy/concepts/effects). The “DeployIfNotExists” effect is the one that interests us in this case since it enables us to elevate our privileges by deploying a role assignment through an ARM template.

Setup, Requirements, Environment, Tools & Materials

Let’s sum up the prerequisites to perform this privilege escalation technique.

• A subscription, let’s call it “subscription 1”.
• A user, let’s name him “policyuser”, with the role of “Resource Policy Contributor”.
• Another user, let’s call him “owneruser”, with the role of “Owner” on the subscription.
• Two resource groups: “resource-group-1” & “resource-group-2”.
• A custom policy that will elevate the privileges of any identity in Azure.
  An initiative that has already been assigned to “subscription 1”.

For your information, the “Resource Policy Contributor” role has the following permissions:

He can perform various tasks related to policies:

• Write policy definitions.
• Create initiatives (collections of policies).
• Assign policies and initiatives to a scope (resource, resource group, subscription, etc.) for enforcement.

Now, when deploying a policy with a “DeployIfNotExists” effect, it is necessary to create a managed identity. The latter is responsible for performing the required modifications on the non the non-compliant resource and correct the configuration to be aligned with the policy definition. However, this managed identity cannot perform these changes without having the needed permissions. In other words, the managed identity must have the necessary permissions to perform these modifications. The roles needed for remediating the resource are specified in the policy definition. Let’s take the example of the policy “Configure Azure Defender to be enabled on SQL servers”. This policy requires the “SQL Security Manager” role to be assigned to the managed identity, as defined by the property “roleDefinitionIds”.

SQL Security Manager Role

Normally, the roles defined in these policy definitions follow the principle of least privilege. However, this is not always the case. By conducting a search in “Microsoft’s official GitHub repository for policies” on 8e3af657-a8ff-443c-a75c-2fe8c4bcb635 (Owner) and 18d7d88d-d35e-4fb5-a5c3–7773c20a72d9 (User Access Administrator), which are two roles that can assign permissions to other identities in Azure AD (user, service principal, group, etc.), I was able to find policies that use these privileged roles.

Among all these policies, some are more likely to be used than others. For my tests, I decided to use the policy “Configure Synapse workspaces to have auditing enabled to Log Analytics workspace” because sending logs to a log analytics workspace is a setting that is often configured by companies.

Let’s imagine that an initiative has been created with some policy definitions, including the policy “Configure Synapse workspaces to have auditing enabled to Log Analytics workspace”.
This initiative has been assigned by “owneruser” at the level of our “Subscription 1” to ensure that all Synapse Workspaces send their logs to the defined log analytics workspace.
What’s clever about this is that our “policyuser” could have assigned the initiative at the Subscription 1 level, but the roles wouldn’t have been assigned to the managed identity since “policyuser” doesn’t have the necessary permissions to assign roles to entities. To achieve this, a role such as “owner” or “user access administrator” is required.

However, since the assignment was made by someone with the rights to add roles, we can take advantage of this situation.
“Policyuser” can add policies to the initiative without the need for reassignment. Therefore, we can create a custom policy, name it “privescpolicy”, and add it to the initiative, leveraging the “owner” role on the managed identity to elevate our privileges. We will create a policy called “privescpolicy”, which we will craft to be always be non-compliant. This is carried out to guarantee that the policy will automatically trigger for new resources or that a remediation task can be manually performed on existing resources. In my case, I will check whether the auditing settings are enabled or not on the SQL servers. I know that SQL servers deployed through the portal do not have these auditing settings enabled by
default, so every SQL server deployed in Subscription 1 will be non-compliant by default according to our “privescpolicy” policy definition.

Non-compliant SQL Server

The policies that use the “DeployIfNotExists” effect deploy an ARM template to remediate non-compliant resources, and it is this functionality that we will leverage. Practically everything on Azure can be deployed using IaC and CaC, including role assignments.
Below, we are assigning the “Owner” role to our user “policyuser”.
As soon as an SQL server is deployed, the policy will be triggered, and our user “policyuser” will be added as the owner of the resource group where the SQL server is deployed.

We use a parameter for the name of the role assignment, which will be provided by newGuid(). This will create a new GUID for each assignment, ensuring that the role can be assigned multiple times at different scopes. In other words, if a non-compliant SQL server 1 is deployed in resource-group-1 and a non-compliant SQL server 2 is deployed in resource-group-2, our policy user will be an owner on both (resource-group-1 and resource-group-2).

Escalate Privileges

Prior to the policy execution the user didn’t have any role on this resource group.

After the policy execution, the user has the “owner” role assigned to him.

Conclusion

Although one might think that the role enabling policy creation (Resource Policy Contributor) lacks the ability to perform critical actions, as demonstrated earlier, and even though this role might appear harmless, we can observe that, in fact, it can pose a danger.
The “policyuser” is being added as an owner of the resource group where the SQL server is deployed. Granting ownership permissions at the resource group level could potentially lead to a privilege escalation scenario if the “policyuser” has limited permissions at the start but gains broader access through ownership.
Suppose the “policyuser” initially has restricted privileges but is added as an owner of the resource group where the SQL server is deployed. In that case, they could potentially gain control over all resources within that resource group, such as key vaults, other SQL Servers, Virtual machines, etc. If not managed carefully, this could lead to unauthorized access or misuse of sensitive data and services.
To mitigate the potential risk of privilege escalation, it is crucial to conduct a thorough examination of the permissions assigned to users and possibly treat the “Resource Policy Contributor” role as more susceptible to risks.
In summary, while the policy implementation might be useful for compliance purposes, it is crucial to be mindful of potential privilege escalation risks and implement adequate access controls to ensure the security and integrity of the deployed resources.

Thank you for reading!