8 mins to read
AWS and Azure privilege escalation attacks are one of the many dangers of managing identities in the cloud. Identity is the new stepping stone for bad actors to exploit and use to move throughout your environment. We’ve explained some tactics bad actors use to escalate their privileges and offer examples of AWS and Azure privilege attack paths, so you can recognize the pitfalls and get ahead of them.
Common Privilege Escalation Types
In the past, privilege escalation meant users receive privileges they were not entitled to, but this has changed. In the cloud. identities are the new perimeter, which means you must look beyond users to pieces of compute, code, services, service principals, and other machine identities. When a privilege escalation occurs, the identity can be used to delete files, view private information, or worse. It usually occurs when a system has a vulnerability or a misconfiguration that allows security to be bypassed or, alternatively, has flawed design assumptions about how it will be used. Privilege escalation occurs in two forms:
- Vertical privilege escalation, also known as privilege elevation, is where a lower privilege identity accesses functions or content reserved for higher privilege identities.
- Horizontal privilege escalation, where an identity accesses functions or content reserved for other identities.
5 Privilege Escalation Attack Paths
- Direct Self Escalation
This is when an identity can modify its own rights. It has all the permissions it needs to move throughout your environment e.g. make itself a global admin.
- Indirect Escalation
This is where one identity can modify another identity’s credentials to impersonate it. For example, an identity has the permission to modify roles in AWS. While this identity is unable to read sensitive data itself, it can modify other roles so that they can read that data, and then jump into those new roles and new role assignments to reach their goal.
- Unintended Inheritance
This is often the result of the complexity in your cloud, including a web of rules, policies, trust relationships, and permissions that give access at an unintended level. For example, in Azure, a security team using a VM may have that identity at least privilege, but then higher up in the RBAC model, at the management group level, all devs in the application group have permission to read across the tenant. The result is a VM that provides unintended inheritance to data across the environment.
- Confused Deputy
An identity with a low level of permission gets access to AWS or Azure resources or service principals with a higher level of permission and then uses that to perform actions on its behalf. For example, an EC2 instance has an instance profile with access to read sensitive data. The low level identity uses the EC2 to read all of the sensitive data on its behalf.
- Resource Permissions Escalations
An identity has the permission to change the configuration settings on a resource to allow the identity to perform unintended actions on that resource. For example, this identity is at least privileged, but it somehow has the permissions to change the configurations of a datastore that normally it only has read-access to, but now they want the ability to delete it all.
Now that we’ve reviewed the common patterns of privilege escalation, let’s review some examples from AWS and Azure that illustrate these escalation patterns.
Real-Life Examples of Privilege Escalation in AWS
Self-Assigning privileges with new IAM policies [Direct Escalation]
All a bad actor needs to execute this exploit is access to an identity (user account) with the permission iam:CreatePolicyVersion. They can then create a new version of an IAM policy and simply grant themselves the access privileges they need to execute their plan. This vulnerability allows a bad actor to wreak irreparable damage in your environment.
When you create a new version of an IAM Policy, you must set it as the default in order for it to take effect on the environment, and that’s where the fatal misconception comes into play. In reality, being able to set a policy as default does not require a user (non-person identity) to have the iam:SetDefaultPolicyVersion permission, although most assume that it does. Rather, when creating a new permission, a user must flag it with “set-as-default,” and AWS will automatically make the new default version.
Modify the policy on an AWS role and then use it [Indirect Escalation]
Often, an AWS user seems locked down to what they can do but looks can be deceiving. If that AWS user can assume a specific AWS Role and perform basic AWS IAM commands, such as list managed policies attached to the role or list the policy versions of the managed policies and then set the default policy to one with more privilege, then they can escalate the permissions of the role and use it for their own purposes. From there, the user is no longer acting under their identity but instead as the newly escalated AWS role and the role assignments.
Creating access keys for a privileged user [Confused Deputy]
Starting with a limited set of permissions, the attacker can use the instance-profile-attachment permissions to create a new EC2 instance with significantly greater privileges than their own. With access to this new EC2 instance, the attacker gains full administrative powers within the target AWS account and can accomplish their goal: deleting the super critical server and paving the way for further nefarious actions even with limit permissions.
Attaching new policies to roles, users, and groups [Resource Permissions Escalations]
By gaining the iam:AttachUserPolicy permission, a bad actor is able to escalate their privileges, attaching an IAM policy to any identity, they can access. This provides a direct pathway to administrator privileges, as the bad actor simply needs to attach the AdministratorAccess AWS managed policy to a user they can access, and they’ll have full access to your AWS environment.
Similar to the above, the iam:AttachGroupPolicy permission lets a bad actor escalate their privileges by giving a group that they’re a member of a new policy with escalated access to the environment. The bad actor could attach the AdministratorAccess AWS managed policy to their user group, which would give them full access to your environment.
The iam:AttachRolePolicy permission is another privilege that bad actors exploit to escalate their permissions — they attach a policy, including the AdministratorAccess AWS managed policy, to a role they are assigned to, then assume the role temporarily using sts:AssumeRole.
Real Life Examples of Privilege Escalation in Azure
Managed identities become a subscription owner [Indirect Escalation]
Another common and straightforward escalation tactic is gaining access through an Azure Subscription Owner. Typically, a bad actor will add a guest to their subscription, then elevate that role to an owner. If the managed identity contains role permissions (Contributor, Owner, etc.) or the privileges are higher than those granted to the guest, the bad actor will gain access to the virtual machine, escalating privileges beyond the VM.
Add a guest account to the subscription [Direct Self Escalation]
A bad actor can add a guest Azure account to an Azure Subscription to execute commands on other VMs via Azure CLI or APIs with escalated access to the environment. The bad actor could then pivot to other data sets and permission chain their way through the data looking for the data store that would give them full access to your environment.
Managed identities gain access to Key Vaults [Resource Permissions Escalations]
The bad actor will target an identity that has the most permissions. They will use these permissions to escalate their permissions to key vaults. Once they have acces to the keys and the keys are created, they’ll use them to further access your environment. The result is that the bad actor will have the same permissions levels as the managed identity. They will be able to create new keys, and overwrite or delete secrets, which could result in anything from privilege escalation to full administrative access.
Privilege Escalation via Cloud Shell [Resource Permissions Escalation]
By default, Azure Subscription Contributors have access to all storage Azure accounts in a subscription. These storage accounts can include Azure Cloud Shell storage files (Linux home directories) that can contain sensitive information. By modifying these Cloud Shell files, a bad actor can execute commands in the Cloud Shell sessions of other identities. This can lead to cross-account command execution and privilege escalation.
Secondary Access [Unintended Inheritance]
Subscriptions where an identity does not have contributor rights on a VM, but has Runbook creation and run rights on an Automation account means the automation account has subscription contributor rights. These rights allow the lesser privileged identity to run commands on the VM through the Runbook. While this in itself is a privilege inheritance and entitlement issue, bad actors can exploit this vulnerability to escalate privileges on an Azure subscription.
Privilege escalation via role assignment [Direct Self Escalation]
This escalation happens theough role assignment. this happens when attaching a role definition to a user, group, service principal, or managed identity at a particular level for the purpose of granting access. Microsoft.Authorization/roleAssignments/write can assign a selected role to one or more managed identities, with the possibility of escalating its privileges up to an owner role within a given resource group.
Preventing Privilege Escalation Tools: CIEM
Privilege escalation is a sinister tactic, and it often happens right under your nose. Sometimes, your security team may lock down a workload at least privilege, but not realize that non-person identity has a permission allowing it to manipulate another role. Suddenly, even though the workload at hand is at least privilege, it can actually still help execute a malicious act by manipulating another identity to work on its behalf.
If your security team has done all it can to make sure a workload is at least privilege and least access, yet bad actors can still find ways to accomplish their goals, how do you truly protect your environment? Cloud Infrastructure Entitlements Management (CIEM) is the answer to your privilege escalation troubles.
A strong CIEM solution can detect every single pathway between every identity and data, permissions, and roles, across different accounts and environments. This uncovers every covert way a bad actor could manipulate your configurations.
CIEM platforms will inventory every identity, person, and non-person, reveal their effective permissions, and show your team excessive permissions or possible dangers like toxic combinations or privilege escalation. A CIEM platform is a sure way to help your cloud reach least privilege and make sure you stay there.
Ready to eliminate privilege escalation and try a CIEM solution?
Read the latest news and insights
12.08.2022
There are four main identity risks that determine the...
12.08.2021
Bad actors can take advantage of any system if they...
