7 mins to read
2022 Every day we see new vulnerabilities being reported that could allow an attacker access to your data, which means it’s time for you to take action. This article looks at some of the privilege escalation types present today, providing examples of possible attack paths against identities and data. We hope you’ll gain a better understanding of what the privilege escalation types look like in your environment.
Attacker Manipulation Tactics
Privilege escalation is a type of attack used to gain unauthorized access and elevate identity privileges within your organization’s cloud environment. Escalating identities can be done by exploiting weaknesses, misconfigurations, or security vulnerabilities with the goal of assessing critical systems and sensitive data. Forrester estimates 80% percent of data breaches involve privileged credentials, the pot of gold at the end of this malicious act.
If you think your organization’s defenses are sufficient, then it might be time to rethink your strategy. It has been shown that even with configurations like S3 buckets disabled and no open ports on EC2 servers for external access, attackers can still find ways into them through misconfigured roles in cloud environments. Identity is the way into the cloud.
Attackers start by finding weak points in an organization’s defenses. Common areas of entry are misconfigured S3 buckets or EC2 instances open to the internet. Wise attackers might scour a list of predictable role names with reconnaissance and enumeration procedures. Cloud roles may occur in variations (e.g., prodApp-nat, prodApp-app2-nat) of previously breached information. As such, malicious parties may attempt role name permutations until they arrive at a match.
Upon successfully obtaining a misconfigured role, unauthorized users can enumerate permissions and hone in on their targeted resources. Subsequently, malicious users may acquire precious metadata within the cloud and decrypt the metadata with the capabilities of their misconfigured role. A compromised database enables outsiders to launch a series of attacks on the enterprise by implanting insidious backdoor codes for convenient and frequent access while staying undetected.
Outsiders can chain their permissions creating an identity chain attack path. For example, if you have the same owner on several objects in several databases, and you have some stored procedure that accesses these objects, you don’t need to grant access permission to every object that the procedure needs to access. If the procedure and the objects have the same owner, you can grant permission for the procedure, and the database will allow the procedure to access all other objects that share the same owner.
In many cases, the first point of penetration will not grant attackers the level of access or data they need. They will attempt privilege escalation to gain more permissions or obtain access to additional, more sensitive resources.
Now, we’ll take you through the five common privilege escalation types we’ve defined at Sonrai, sprinkling in examples for Azure, AWS, and GCP platforms. Finally, we’ll move on to prevention strategies so no one falls victim.
What are the types of privilege escalation?
Direct Self Escalation
When you allow an identity to modify its own rights, it’s called Direct Self Escalation. This means that the identity can move throughout your environment with all of the permissions needed for administration, such as being made into a system admin or having full control over data access.
Direct self escalation in AWS is easy. For example, it can occur when self-assigning privileges with new IAM policies. All an attacker needs to execute this exploit is access to an identity with the permission iam:CreatePolicyVersion. This permission enables the attacker to create a new version of an IAM policy that will allow them to simply grant themselves the access privileges they need to execute their plan. This vulnerability allows an attacker to create irreparable damage in your AWS environment by enabling them to define their own custom permissions.
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 system, and that’s where the fatal misconception comes into play. In reality, being able to set a policy as default does not require an identity to have the iam:SetDefaultPolicyVersion permission, although most assume that it does. Rather, when creating new permissions, a user simply needs to flag it with “set-as-default”. AWS will automatically make the new default version when it’s created.
Indirect Escalation
Indirect Escalation is where one identity can modify another identity’s credentials to impersonate it and complete their desired action. For example, an identity has the permission to modify roles. While this identity cannot read sensitive data itself, it can modify other roles so that it can read that data, and then jump into this new role and ultimately reach its goal.
An example of indirect escalation in Azure is a straightforward escalation tactic. The attacker gains access through an Azure ‘Subscription Owner’. The attacker will add a “guest” to the compromised subscription. Once the guest is added, it is elevated to an ‘Owner’. If the identity is given a role, like a contributor, owner, or the privileges are higher than those granted to the guest, the attacker will gain access to the virtual machine, escalating privileges beyond the VM.
Unintended Inheritance
Unintended Inheritance 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. Unintended Inheritance occurs when there are too many interconnected components within the environment you’re managing, like web of regulations, permission structures on top of each other coupled with sensitive data being stored everywhere.
In GCP, we find an unintended inheritance with Iam.roles.update. If your attacker accesses an identity that is assigned a custom IAM role, then iam.roles.update will allow an attacker to update “includedPermissons” on that role. Because it is assigned to the compromised identity, it will gain the desired privileges, including the permission iam.serviceAccounts.getAccessToken. This permission allows an identity to request an access token that belongs to a specified Service Account. By requesting an access token for a Service Account that has more privileges than the current identity, it can escalate privileges.
Another example in GCP of an unintended inheritance attack path is relying on access scopes when attaching a service account to a VM instance. When a service account has a VM instance attached to it, it can specify one or more access scopes. Access scopes let identities restrict which services the VM can access. The restrictions are applied in addition to allowing policies, but you can’t restrict access to specific buckets. Therefore, access scopes aren’t a suitable replacement for fine-grained allow policies.
Confused Deputy
Confused Deputy refers to an identity with a low set of permission that gets access to a resource or a service 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.
Another example in AWS happens when creating access keys for a privileged user. Starting with a very limited set of permissions, the attacker is able to leverage 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 account and is able to accomplish the scenario’s goal – deleting the server and paving the way for further nefarious actions.
Resource Permissions Escalations
This is when 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 privilege, but it has the permissions to change the configurations of a datastore that normally it only has read access to, giving it the ability to delete the datastore.
An AWS example of resource permissions escalations happens when an attacker gains access to the iam:AttachUserPolicy permission. An attacker is able to escalate their privileges by attaching an IAM policy to any identity they have access to in the environment. This method provides a direct pathway to administrator privileges, as the attacker simply needs to attach the AdministratorAccess managed policy to an identity they have access to. They’ll suddenly have full access to your AWS environment.
In GCP, Privesc on a resource leads to resource permissions escalations. Privesc will allow you to get more permissions over the specific resource, like the setIamPolicy permission over cloudfunctions to allow an attacker to trigger the function. Some resource permissions will allow an attacker to attach an arbitrary service account to the resource. This means that they will be able to launch a resource with a SA, get into the resource, and steal the SA token. Therefore, this will allow someone to escalate to a principal via a resource escalation.
How to Address the Many Privilege Escalation Types
The complexity in your cloud can have an adverse effect on security. Attackers attempting privilege escalation often find the “doors are wide open” due to inadequate security controls and monitoring. Others find a vulnerability in poorly designed applications allowing them access to other information. Once access is gained to another identity’s data or account via leveraging flaws, they may modify, copy, destroy, or use the data for their needs.
In the event you find your environment with this type of privilege escalation attack, it is important to isolate the incident first to reduce the blast radius. Privilege escalation is a sinister tactic as it often happens right under your nose and can cause massive chaos. Where manual and human efforts reach their threshold, solutions and tools can step in.
Cloud Infrastructure Entitlements Management solutions are increasingly adopted in the market to address a variety of identity and access concerns, privilege escalation included.
A strong CIEM solution can detect every single pathway between every single identity and data, permissions, roles and more, across different accounts and environments. This means every covert way a bad-actor could manipulate your configurations is revealed.
CIEM platforms will inventory every identity, person and non-person, reveal their effective permissions and allow your team to note the excessive permissions or possible dangers like toxic combinations or privilege escalation.
If you’re interested in learning more about how to defend against the many privilege escalation types, explore a solution.
Or, evaluate your risk of privilege escalation in our dedicated Ebook.
