Real-world examples of privilege escalation in AWS and Azure

Privilege escalation attacks are one of the many dangers of identity management in the cloud. Identity is the new springboard that bad actors can exploit and use to move through your environment. We’ve explained some tactics bad actors use to elevate their privileges in AWS and Azure so you can recognize the pitfalls and get ahead of them.

The 5 Types of Privilege Escalation

Through our research, we have identified five privilege escalation patterns in the public cloud. Let’s review them below:

  1. Direct self-climbing

It is at this time that an Identity can modify its own rights. He has all the permissions he needs to move around your environment, such as making himself an administrator.

  1. Indirect climbing

This is where an identity can alter the credentials of another identity to impersonate it. For example, an identity has permission to modify roles in AWS. Although this identity is not able to read sensitive data itself, it can modify other roles so that they can read this data and then jump into this new role and achieve their goal in the end.

  1. Involuntary inheritance

This is often the result of the complexity of your cloud, including a web of rules, policies, trust relationships, and permissions that grant access at an unforeseen level. For example, in Azure, a security team using a virtual machine might have at least this identity, but earlier in the RBAC model, at the management group level, it was defined that all developers in the application group have permission to read through the tenant. The result is a virtual machine with unintended inheritance to read data from the environment.

  1. Confused Deputy

An identity with a low permission set gains access to a resource or service with a higher permission level and then uses it 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 sensitive data on its behalf.

  1. Resource Permission Escalations

An identity has permissions to change configuration settings on a resource to allow the identity to perform unintended actions on that resource. For example, this identity is at least privileged itself, but somehow it has the permissions to modify the configurations of a data store that it normally only has read access to, but now they want the ability to delete everything.

Now that we’ve reviewed common privilege escalation patterns, let’s look at some examples from AWS and Azure that demonstrate these patterns.

Real-World Examples of Privilege Escalation in AWS

Self-Assign Privileges with New IAM Policies [Direct Escalation]

All a malicious actor needs to execute this exploit is access to an identity (user account) with the iam:CreatePolicyVersion permission. This allows them to create a new version of an IAM policy, allowing them to simply grant themselves the access privileges they need to execute their plan. By allowing them to set their own custom permissions, this vulnerability allows a malicious actor to cause irreparable damage to your environment.

When you create a new version of an IAM policy, you must set it as default for it to take effect on the system, and this is where the fatal misconception comes in. In reality, the ability to set a default policy does not require a user (non-personal identity) to have the iam:SetDefaultPolicyVersion permission, although most assume that it does. Instead, when creating a new permission, a user simply has to mark it with “set-as-default” and AWS will automatically create the new default version when created.

Edit the policy on an AWS role and then use it [Indirect Escalation]

Often an AWS user looks pretty stuck on what they can do, but looks can be deceiving. If this AWS user has the ability to assume a specific AWS role and run some basic AWS IAM commands, such as listing the managed policies that are attached to the role, listing the policy versions of the managed policies, and then setting the default policy to whichever is more privileged, they can then increase the role’s permissions and then use it for their own purposes. From there, the user no longer acts as their identity, but rather as a newly escalated AWS role.

Create Access Keys for a Privileged User [Confused Deputy]

From a very limited set of permissions, the attacker is able to exploit instance profile attach permissions to create a new EC2 instance with significantly higher privileges than their own. With access to this new EC2 instance, the attacker obtains full administrative powers within the target account and is able to accomplish the scenario objective – remove the cg-super-critical-security-server and open the lead to other harmful actions.

Attaching new policies to roles, users, and groups [Resource Permissions Escalations]

By obtaining the iam:AttachUserPolicy permission, a malicious actor can elevate their privileges by attaching an IAM policy to any identity they have access to. What is most concerning about this method and similar examples to follow is that it provides a direct path to administrator privileges, as the bad actor simply has to attach the AWS AdministratorAccess managed policy to a user it has access to, and it will suddenly have full access to your AWS environment. Similar to the above, the iam:AttachGroupPolicy permission allows a malicious actor to escalate their privileges by indicating to a group that they are a member of a new policy with increased access to the environment. Similar to the method above, the malicious actor could attach the AWS AdministratorAccess managed policy to their user pool, giving them full access to your environment. The iam:AttachRolePolicy permission is another commonly exploited privilege that allows a malicious actor to increase their permissions by attaching a policy, including the AWS AdministratorAccess managed policy, to a role they are assigned to. The user can temporarily assume the role using sts:AssumeRole.

Real-world examples of privilege escalation in Azure

Managed identities become owners of a subscription [Indirect Escalation]

Another common and simple escalation tactic is for a bad actor to gain access through an Azure “subscription owner”. Typically, a bad actor will add a “guest” to their subscription. Once the guest is added, it is elevated to the rank of “owner”. If the identity is assigned a role (Contributor, Owner, etc.) or if the privileges are higher than those granted to the guest, it will have access to the increasing privileges of the virtual machine beyond the VM.

Add guest account to subscription [Direct Self Escalation]

Similar to the above, adding a guest account to a “subscription” allows a malicious actor to elevate their privileges by running commands on other VMs via Azure CLI or APIs with escalated access to the environment. Like the method above, the bad actor could pivot to other datasets and evaluate permissions that would give them full access to your environment.

Managed identities access key vaults [Resource Permissions Escalations]

The bad actor will target a managed identity that has the most permissions. Once the keys are created, they will use them to access your environment. The result is that the malicious actor will have the same permission levels as the managed identity. They will be able to create keys, overwrite or delete stored secrets, which could result in anything from no privilege escalation to full administrative access.

Privilege elevation through Cloud Shell [Resource Permissions Escalation]

By default, Azure subscription contributors have access to all storage accounts in a subscription. These storage accounts may contain Azure Cloud Shell storage files (Linux home directories) which may contain sensitive information. By modifying these Cloud Shell files, a malicious actor can execute commands in 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 VM contributor rights, but has runbook creation and execution rights on an Automation account means the Automation account has subscription contributor rights. These rights allow the least privileged identity to execute commands on the virtual machine through the runbook. While this is itself a privilege and rights inheritance issue, the process described earlier can abuse this to elevate privileges on an Azure subscription.

Solutions to prevent privilege escalation: CIEM

Privilege escalation is a sinister tactic because it often happens right under your nose. Sometimes your security team may have locked down a workload with at least one privilege, but didn’t realize that the non-personal identity actually has permission to manipulate another role. Suddenly, even if the workload at hand is at least a privilege, it can actually help perform a malicious act by manipulating another identity to work on its behalf. If your security team has gone out of its way to ensure that a workload is at least privileged, but malicious actors can still find ways to achieve their goals, how are you really protecting your environment?

Where manual and human efforts reach their threshold, solutions and tools can step in. Cloud Infrastructure Entitlements Management (CIEM) is the answer to your privilege escalation issues. A powerful CIEM solution can detect every unique path between every identity and every data, every permission, every role, etc., across different accounts and environments. This means all the secret ways a bad actor could manipulate your setups are revealed.

CIEM platforms will inventory every identity, person and non-person, reveal their effective permissions, and allow your team to note excessive permissions or possible dangers like toxic combinations or privilege escalation. A CIEM platform is a surefire way to help your cloud achieve least privilege and ensure you stay there.

Sonrai CIEM Abilities

Sonrai Dig leverages graphics technologies that provide all the benefits of a CIEM solution, but offers even more. Dig can separate groups and environments into different “lanes”, allowing your organization to define unique security objectives and security maturity assessment scores. When security issues are detected, our smart workflows ensure the right team is notified to reduce alert overload and fatigue and fix the problem – if a bot hasn’t already done it for you.

To see Dig in action, request a demo.

The post Practical Examples of Privilege Escalation in AWS and Azure appeared first on Sonrai Security.

*** This is a Security Bloggers Network syndicated blog from Blog – Sonrai Security written by Eric Kedrosky. Read the original post at: https://sonraisecurity.com/blog/real-life-examples-of-privilege-escalation-in-aws-and-azure/

About Shirley L. Kreger

Check Also

Examples of Good Retail Customer Service

It’s a known fact that retail businesses must provide excellent customer service to be successful. …