Lead Image © zelfit, 123rf.com

Lead Image © zelfit, 123rf.com

Shadow admin permissions and your AWS account

Shadow Boxing

Article from ADMIN 63/2021
By
Malicious attackers are trying to conquer your AWS castle in the cloud. To mount a strong defense, you'll need a deeper understanding of privilege escalation and shadow admin permissions.

The year is 50 BC. Gaul is entirely occupied by the Romans. Well, not entirely … . One small village of indomitable Gauls still holds out against the invaders.

Like those indomitable Gauls, you face down legions of mysterious invaders who would love to conquer your Amazon Web Services (AWS) resources. In this article, I look at how many AWS attacks happen and what you can do about them, but before I get started, I'll take a moment to explain how permissions work on AWS.

AWS Permissions

A principal, which can be a human or a machine, makes a request for an action on any AWS resource. Principals must authenticate with their credentials to send a request to AWS, unless the resource permits anonymous access, which is not the case for most services. The principal can use the root user or an Identity and Access Management (IAM) user. Of course, being the root user is not security best practices.

Once you authenticate, you can only access resources on which you have some kind of authorization. During authorization, AWS checks for policies that apply to the request, which it then uses to determine whether to allow or deny the request.

This topic can get very complex, so I will not dive deep, but the concept is very similar to, for example, Microsoft authentication, where you need to have a user account and permissions to access any resource on the network. Cloud providers have an extensive selection of permissions or capabilities that makes it difficult for admins to use the principle of least privilege when configuring policies for users and roles.

The Israeli cybersecurity company CyberArk explains, "… there are many cases where Shadow Admins might be created. Despite the appearance of limited permissions, a Shadow Admin with just a single permission has the ability to gain the equivalent power of a full admin" [1].

I refer to the term shadow admin often in this article. Simply, a shadow admin is a user or role with some assigned capabilities, that, if not configured properly, can escalate privileges to full administrator. A shadow admin account is thus nearly as dangerous as the root account, and it receives far less attention from security staff.

CyberArk has stated that 10 shadow admin permissions exist, but as you will see later, there are even more than that. CyberArk has released an open source tool called SkyArk [2] with which you can scan Azure and AWS environments and identify shadow admin accounts. To scan your account, you just need to set up a user account with IAM read-only permissions, because it just needs to check for the assigned permissions of all users and roles, and create an access key for that account.

SkyArk is useful for identifying accounts that could be vulnerable to privilege escalation. The results of the scans can be used by defenders (blue team) and pentesters (red team) to test the security of their company and remove all shadow admins with unnecessary permissions. However, bad actors can also use the results to break into cloud accounts. As a security professional, you need to know all those permissions and how to protect and detect them. Table 1 shows the AWS permissions that CyberArk identifies as shadow admin permissions.

Table 1

CyberArk Shadow Admin Permissions

Action Result
CreateAccessKey Any user with this permission could abuse it to create a new access key to another IAM admin account.
CreateLoginProfile With this permission, an attacker can create another password-based login profile and use it to perform malicious activities on behalf of the user.
UpdateLoginProfile An attacker could reset user passwords.
AttachUserPolicy, AttachGroupPolicy, or AttachRolePolicy Any user could attach an existing admin policy to a user account.
PutUserPolicy, PutGroupPolicy, or PutRolePolicy A cybersecurity adversary could add policies to other users, granting additional privileges to compromised users.
CreatePolicy An attacker could add any policy to any compromised user.
AddUserToGroup A bad actor could add any non-privileged user to any privileged group.
UpdateAssumeRolePolicy A malicious attacker could change a privileged role to grant permissions to a non-privileged account.
CreatePolicyVersion or SetDefaultPolicyVersion Attackers with both permissions would be able to change customer-managed policies to convert non-privileged users to privileged users.
PassRole with CreateInstanceProfile orAddRoleToInstanceProfile Any hacker could create a new privileged instance profile and attach it to a compromised Amazon Elastic Compute Cloud (EC2) instance that the attacker owns.

Rhino Security Labs [3], the creators of the open source web penetration framework Pacu [4], takes a more expansive view of what permissions are dangerous enough to be shadow admin permissions. The Rhino team lists 21 shadow admin permissions. Table 2 shows the additional permissions that made the Rhino list.

Table 2

Rhino Shadow Admin Permissions

iam:CreatePolicyVersion iam:AttachRolePolicy
iam:SetDefaultPolicyVersion iam:PutUserPolicy
iam:PassRole and ec2:RunInstances iam:PutGroupPolicy
iam:CreateAccessKey iam:PutRolePolicy
iam:CreateLoginProfile iam:AddUserToGroup
iam:UpdateLoginProfile iam:UpdateAssumeRolePolicy and sts:AssumeRole
iam:AttachUserPolicy iam:PassRole, lambda:CreateFunction, and lambda:InvokeFunction
iam:AttachGroupPolicy iam:PassRole, lambda:CreateFunction, and lambda:CreateEventSourceMapping
lambda:UpdateFunctionCode iam:PassRole and glue:CreateDevEndpoint
glue:UpdateDevEndpoint iam:PassRole and cloudformation:CreateStack
iam:PassRole, datapipeline:CreatePipeline, and datapipeline:PutPipelineDefinition

The people at Rhino Security Labs have done a brilliant job creating a Python script, aws_escalate.py [5], to identify all 21 shadow admins.

Preparing the Invasion

Julius Caesar wanted to launch a big invasion into Gaul to defend Rome and earn glory for himself. However, nowadays, motivations are different, and they include espionage, spamming, disruption, fun, credibility, theft, abuse, financial interference, revenge, and so on.

To get the key to the castle, a bad actor needs to get a user's credentials first. The easiest way would be to ask the user, but perhaps that option will not succeed, so the attacker might need to take a unique approach.

As you know, developers, software engineers, DevOps folks, and others that usually interact with AWS resources sometimes keep credentials in clear text on their computers, unless they make the effort to deploy some sort of protection like password vaults, but I'll assume those are few. Employing a very common hacking method like phishing is a likely way the attacker will take the first step.

For instance, the attacker could browse to Gmail or any other email web provider and create an account with a name that is descriptive of an existing company. (I will not give you any specific ideas here.) Next, they could get a list of recipients for the email that might comprise a small team of developers or employees with similar roles, which can probably be found on LinkedIn. Other methods are suitable for finding credentials in the wild. For instance, intruders can use a tool called shhgit [6] to find secrets and sensitive files across GitHub code.

The attacker can now send a fake calendar appointment with a subject line that is likely to get the attention of the recipient (e.g., a salary increase or a free Christmas dinner). In the body of the message is a link to a URL that everybody would love to click. Malware could then be deployed, or the link could redirect the legitimate traffic to a fake AWS console login.

An attacker who succeeds in compromising one user can then navigate to the user profile .aws folder and get the credentials file that contains the AWS access key and secret. Yes, it is all in clear text.

Exploring the Castle

Once the attacker has slipped through the defenses, the next step is to use scanners to do some reconnaissance and collect information about the castle.

The two tools I described previously, SkyArk (PowerShell) and aws_escalate.py (Python) will scan for accounts that offer the best possibilities for privilege escalation. SkyArk provides a much more complete report, but it won't find some of the additional shadow admin permissions identified by aws_escalate.py. The two tools complement each other.

SkyArk will work for both AWS and Azure. If you are interested in exploring SkyArk, the instructions to install it are on its web page and are very straightforward. The user running the scan needs to have IAM read-only permissions, so the attacker needs those capabilities, and it is still possible to use the Pacu tool to see if the current user could be vulnerable.

In a PowerShell command prompt window (CMD), run the following command under the SkyArk folder:

PS C:\SkyArk> Scan -AWShadowAdmins -AccessKeyID AKIA5DWQIQ2MR6OXXXXX -SecretKey BYptvF+QF2kk8W4DJUiu5xQPffr34AFqYptXXXXX -DefaultRegion us-west-2

AWShadowAdmins is just a module of the program, but you might find other modules interesting, as well (e.g., AWStrace, which analyzes logs).

Figure 1 shows some very complete report output, but the attacker is most interested in the shadow admin line and needs to discover which user is associated with which permission. The golden ticket is to find a user with a vulnerable shadow permission.

Figure 1: SkyArk report output.

The next step might be to use Pacu. Installation is very straightforward by following the instructions on their website. Once installed, you should run it and configure the first session with the access key and secret. If you type whoami and hit Enter, the tool will give information about the access key being used, but it is not enough information to play around. To get more information, run the first module to enumerate permissions by typing

run iam__enum_permissions

Now you know the stolen credentials were from Cleopatra (Figure 2).

Figure 2: Permissions enumerated by Pacu.

If you run whoami again, you will get much more information, but the most important thing you could discover about Cleopatra is a shadow permission or capability (Listing 1).

Listing 1

Finding Shadow Permissions

01 "Policies": [
02     {
03       "PolicyName": "Shadow_CreateNewPolicyVersion",
04       "PolicyArn": "arn:aws:iam::901306156697:policy/Shadow_CreateNewPolicyVersion"
05     }
06 And:
07 "iam:SetDefaultPolicyVersion": {
08     "Resource": [
09       "*"

You could also run the aws_escalate.py tool with the access key and secret previously stolen from the user to generate a CSV output file that is very simple, but concise and directly to the point. As you can see in Figure 2, the tool scans all the users and lists all the associated permissions, but if some confirmed Shadow permissions exist, it will show them onscreen.

According to the creators, a blank means the associated account is not vulnerable). Confirmed means that the privilege escalation method works for that user, and Potential means that the privilege escalation method might work, but requires further investigation.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Exploiting, detecting, and correcting IAM security misconfigurations
    Three IAM security misconfiguration scenarios are rather common: allowing the creation of a new policy version, the modification of a role trust policy, and the creation of EC2 instances with role passing. We look at ways to avoid and detect IAM security holes.
  • Hands-on Exchange rights management
    Exchange Server 2013 provides a comprehensive, role-based rights management feature. Rights and roles can be managed in the Exchange console, with PowerShell, or with additional tools. We demonstrate all three options.
  • New administration options on Windows Server 2016
    Redmond is set to launch the next-generation Windows Server 2016. Microsoft promises to make administration more secure, which is a good enough reason to take a closer look at the new Privileged Access Management feature.
  • Protect privileged accounts in AD
    Granular protection for highly privileged accounts is granted by the Protected Users group in Active Directory and Kerberos authentication policies.
  • Privileged Identity Management in Azure AD
    Azure Active Directory privileged identity management provides just enough administration for admins to carry out their work, while minimizing the possibility of security breaches through privileged admin accounts.
comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs



Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>
	</a>

<hr>		    
			</div>
		    		</div>

		<div class=