Organizations worldwide are moving to the cloud – and that migration is creating the threat of shadow admins. On-premises shadow admin accounts have sensitive privileges and are typically overlooked because they are not members of a privileged Active Directory (AD) group. Instead, they were granted privileges through the direct assignment of permissions (using ACLs on AD objects).
While the stealthy techniques that rogue admins and malicious actors can take to escalate privileges in on-premises networks are well documented, there’s still a level of uncertainly about cloud environments.
Last week at RSA Conference, CyberArk Labs unveiled new research exploring exactly the threat of shadow admins in cloud environments. The session was well attended and written about by ThreatPost.
This blog post takes a look at our findings and the tool we’ve developed to help detect and mitigate the increasing threat of cloud shadow admins. We researched 10 different types of permissions that potential attackers could abuse to escalate privileges and take hold of the entire environment.
As part of our research, we developed a free cloud security tool, SkyArk, to help detect and mitigate the increasing threat of Cloud Shadow Admins: https://github.com/cyberark/SkyArk
A Needed Paradigm Shift
It’s possible for attackers to find and abuse non-trivial and presumably “limited” permissions to escalate their privileges and become full cloud admins. They can also easily use these permissions to hide stealthy shadow entities that remain hidden until they are used as backdoor accounts allowing access to the network.
This is possible on any number of cloud platforms. For the purposes of our research, we’ll use Amazon Web Services (AWS) as just one example. The full and ultimate administrator privileges in AWS are provided by assigning the well-known “AdministratorAccess” permission policy to the chosen admin entities.
Figure 1: “AdministratorAccess” permission policy – allowing full admin rights
Any entity that has the “AdministratorAccess” policy has the permissions to perform any action (“Action”:“*”) on every target resource (“Resource”:“*”). However, during our research, we discovered 10 other kinds of permissions that grant the assigned entities the exact same full admin power.
These sensitive permissions look innocent, as though they are not privileged at first glance, which causes organizations to underestimate the sensitivity of these accounts. As a result, organizations will overlook placing the same security controls on these accounts that they would to standard full administrator access entities. This gap in awareness creates an opportunity for potential attackers.
Organizations can no longer consider the more well-known administrator access entities to be the only privileged entities. A paradigm shift is needed in what is considered privileged.
Stealthier Admins
Let’s take a look at the following permission policy:
Figure 2: A “limited” permission policy
At first glance, the policy in figure 2 looks like a limited and constrained policy because only eight actions are allowed by the policy, and six of the eight are read-only actions (Get+List).
However, it’s important to notice the other two permissions – CreatePolicyVersion and SetDefaultPolicyVersion. Those permissions are actually granting the assigned entities, and potential attackers through them, the ability to escalate their current “limited” permission to full admin rights – just like the other full privileged “AdministratorAccess” policy. This happens since every permission policy in AWS can have up to five policy versions at the same time, which is a good and useful feature, if for example, you updated a specific policy and encountered a few errors. In this case, you can easily flip back to the policy’s previous version.
An entity with the above permission policy can create a new policy version for its existing assigned policy, using the API calls CreatePolicyVersion and SetDefaultPolicyVersion. Then, after creating this new policy version, the entity can choose to apply it and grant itself administrator access rights. Therefore, a potential attacker who compromises this kind of entity will be able to execute all of its intended malicious actions in the target environment. In addition, after the execution of the malicious activity, the attacker could roll back the permission policy version to the original one, thereby making it look innocent.
Here is a quick video demonstrating the above scenario:
Entities in the environment that have permission to modify policy versions, like the above scenario, must be treated as privileged. The organization needs to ask itself if these entities really need this kind of sensitive permission. Defensive teams must make sure these privileged entities are well secured with strong, frequently rotated and safely stored credentials, enabled multi-factor authentication and close monitoring.
As a second example, let’s look at the below policy:
Figure 3: example for a “limited” DevOps users’ permission policy
At first glance, this might seem like a limited policy like ones often used by DevOps users. This policy permits only four API calls related to EC2 instances and as you can see the policy’s assigned entities cannot delete other EC2 instances.
However, a potential attacker that infiltrated the organization, but has not yet gained full admin rights over the AWS environment, could use the credentials of an entity with the above policy to create a new privileged instance profile. With the newly privileged instance profile, the attacker could create and attach a privileged role to one of the EC2 instances he might already have access to. From this instance, the attacker could assume the full admin role and take control over the whole AWS environment.
Here is a quick video for demonstrating this attack scenario:
10 Permissions to Find & Protect If Used
Our research uncovered 10 sensitive identity and access management (IAM) permissions that can lead to stealthy shadow admins. Here is the detailed list:
- CreateAccessKey
The permission to use the CreateAccessKey operation is a good example for understanding the notion of cloud shadow admins. An attacker with just CreateAccessKey IAM API permission could abuse it to create a new access key to another IAM admin account. In response to this API call, the attacker will be provided with the newly created access key.
Figure 4: Entities with this permission policy will be shadow admins
An entity (user/group/role) with the above policy is as powerful as other full admin users with the “AdministratorAccess” permissions. Compromising an account with the policy in Figure 4 alone will allow the attacker to gain a new privileged access key and continue to execute malicious actions in the environment on behalf of the target user he has just created a new access key for.
2. CreateLoginProfile
With this permission, an attacker can take a privileged entity that only has API access keys (like an IAM entity that’s not meant for humans but for an application’s APIs automatic usage). Then the attacker can add a new password-based login profile, set a new password for that entity, impersonate it and execute the intended malicious action on behalf of the compromised user.
3. UpdateLoginProfile
This permission provides potential attackers the permission to reset other IAM users’ login passwords.
4. AttachUserPolicy, AttachGroupPolicy or AttachRolePolicy
An attacker with a policy containing these permissions could attach existing admin policy to any other entity he currently possesses.
5. PutUserPolicy, PutGroupPolicy or PutRolePolicy
These permissions permit the attacker to add “inline” policies to other entities as opposed to “managed policies.” An inline policy is a policy that is embedded in a principal entity (a user, group or role). So when you delete an entity, its embedded inline policies are deleted as well. The newly added inline policy defined by the attacker will allow the attacker to grant additional privileges to previously compromised entities.
6. CreatePolicy
Using this permission, the attacker could add a stealthy admin policy and call it a “ReadOnly” policy, making it look harmless.
7. AddUserToGroup
With this permission, an attacker could add his currently possessed user directly into the admin group of the organization.
8. UpdateAssumeRolePolicy
Every role has a policy that defines who can assume this role. This is typically referred to as the “role trust policy.” Using this permission, an attacker can change the assuming permissions of a privileged role and then assume it with a non-privileged account.
9. CreatePolicyVersion, SetDefaultPolicyVersion
Like our first example, with the permissions to “CreatePolicyVersion” and “SetDefaultPolicyVersion,” attackers can change customer-managed policies and change a non-privileged entity to be a privileged one.
10. PassRole with CreateInstanceProfile/AddRoleToInstanceProfile
Like our second example, with those permissions to modify Instance Profiles, an attacker could create a new privileged instance profile and attach it to a compromised EC2 instance that he possesses.
SkyArk – A New, Free Tool for Mitigating Cloud Shadow Admins
Available now on GitHub, SkyArk is an open source, cloud-security tool that can be used to expose cloud shadow admins and protect cloud privileged entities.
It has two helpful sub-modules – AWStealth and AWStrace. AWStealth can be used to discover the most privileged entities in a scanned AWS environment, including cloud shadow admins. AWStrace analyzes AWS CloudTrail logs and prioritizes risky sensitive IAM actions that potential cloud shadow admin attackers might use.
We encourage organizations to use SkyArk to discover their most AWS-privileged entities and to make sure those entities are well secured. Remember that attacker are hunting for those kinds of privileged entities, so timing really matters.
For more information on the tool, visit the GitHub site: https://github.com/cyberark/SkyArk. For any questions, contact Asaf Hecht (@Hechtov) at [email protected].
