AWS IAM Exploitation Techniques

Amazon Web Services(AWS) provides many types of security services, Identity and Access Management(IAM) is one of most widely used.

IAM is a feature of your AWS account and is offered at no additional charge to set users, groups, policies and roles. When you signed up as a root user, you gain the complete access to all resources for all IAW services. With the help of IAM, under the root user or account, you can set up multiple user accounts, each with its own credentials. IAM is used to govern authentication and authorization of these AWS user identities. Unfortunately, there is ample opportunity of IAM misconfigurations that lead to security vulnerabilities. According to State of Cloud Security 2021 report, IAM is the most commonly cited cloud misconfiguration. You might feel the pain when you face some issue like the confused deputy problem to which luckily AWS already gives the solution, but as your use cases expand and get complex, the security issues associated with IAM will become a challenge for both AWS administrators and security auditors.

This post will give three IAM related exploitation techniques, hopefully they can draw your attention to similar risks which might be lurking in your cloud environment.

Privilege Escalation Via Passing Roles To Services

The most fundamental component of IAM is the policy. Policy is an object that, when associated with users, user groups or roles, defines their permissions. When it comes to security best practices in IAM, you must hear of the least privilege principle, and you know you shouldn’t use overly permissive policies.

For example, if you have solid knowledge of passRole and Resource: "*" in the below policy example, you might be vigilant and never attach such an IAM policy to IAM users.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "*"
        }
    ]
}

But as things grow complex, there is an AWS account containing a role with iam:AttachUserPolicy permission and a user group which has the iam:PassRole, lambda:CreateFunction, and lambda:InvokeFunction permissions:

{
     "Version": "2012-10-17",
     "Statement": [
     {
         "Sid": "VisualEditor0",
         "Effect": "Allow",
         "Action": [
               "lambda:CreateFunction",
              "iam:PassRole"
         ],
          "Resource": [
             "arn:aws:iam::*:role/*",
             "arn:aws:lambda:*:*:function:*"
         ]
     },
     {
         "Sid": "VisualEditor1",
         "Effect": "Allow",
         "Action": "lambda:CreateEventSourceMapping",
         "Resource": "*"
     }
  ]
}

Is it easy for you to identify the risk that users in the aforementioned group can get full admin permission to the AWS environment?

There are much more methods across various AWS services to be leveraged to perform privilege escalation attacks:

01 — iam:CreatePolicyVersion
02 — iam:SetDefaultPolicyVersion2
03 — iam:PassRole and ec2:RunInstances
04 — iam:CreateAccessKey
05 — iam:CreateLoginProfile
06 — iam:UpdateLoginProfile
07 — iam:AttachUserPolicy
08 — iam:AttachGroupPolicy
09 — iam:AttachRolePolicy
10 — iam:PutUserPolicy
11 — iam:PutGroupPolicy
12 — iam:PutRolePolicy
13 — iam:AddUserToGroup
14 — iam:UpdateAssumeRolePolicy
15 — iam:PassRole, lambda:CreateFunction, and lambda:InvokeFunction
16 — iam:PassRole, lambda:CreateFunction,and lambda:CreateEventSourceMapping
17 — lambda:UpdateFunctionCode
18 — iam:PassRole, glue:CreateDevEndpoint, and glue:GetDevEndpoint(s)
19 — glue:UpdateDevEndpoint and glue:GetDevEndpoint(s)
20 — iam:PassRole, cloudformation:CreateStack,and cloudformation:DescribeStacks
21 — iam:PassRole, datapipeline:CreatePipeline,datapipeline:PutPipelineDefinition, and datapipeline:ActivatePipeline

You can find more about it on https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/.

Backdoor Implantation Using Sneaky Resource Injection in CloudFormation

AWS CloudFormation helps you set up and manage a collection of AWS resources which is called stack. You can construct and configure your stack using templates. The template is uploaded into an S3 bucket before deployment itself. One issue with this design is that when terraform executes the template hosted in the S3 URL, it might not be the one uploaded beforehand given that there is some delay between the template upload and the subsequent deploy step. The lack the guarantee of integrity of template file opens a chance for attackers to implant backdoor for them to assume cross-account IAM role by modifying the original CloudFormation template right before deployment.

To carry out this attack, assume a vulnerable AWS environment:

1. The CloudFormation deploy step uses an S3 Template URL
2. There is a delay between the template upload and deployment
3. The attacker has the access to an IAM user in the target account who has the following permissions on the S3 bucket: s3:PutBucketNotification, s3:PutObject, and s3:GetObject

The whole attack process is illustrated in the diagram as below:

The Lambda will be invoked whenever a template is uploaded to the bucket as the attacker has the s3:PutBucketNotification permission to configure the S3 bucket to publish notification to the attacker controlled Lambda. Once the Lambda receives the notification, it will retrieve the template from the S3 bucket, modify it by adding an IAM policy to grant the attacker with *:* permission in the target account.

Deployment artifact modification is not a new technique, and it is not specific to CloudFormation either. This vector is still scary as it allows for the possibility of a direct privilege escalation to an administrator role in the victim account.

The original post is here: https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/

The Dark Side of the Temporary Tokens

AWS STS is an AWS service that allows you to request temporary security credentials to operate with time-limited and restricted privileges.

Temporary security tokens are recommended over access keys, long-term credentials. They are used when users or applications perform some actions, as well as in automated actions done by AWS itself in the background.

But STS has its own dark side. Once a privileged access key is leaked, attackers tend to utilize STS to generate temporary tokens to hide their trails instead of using the access key directly. After detection of leakage, even if the leaked access key has been revoked, these temporary tokens remain valid in the wild. When a temporary token is leaked or created, it can be converted to “permanent” tokens. This conversion can be achieved by using AssumeRole to generate a bundle of temporary tokens with one temporary token, then using the newly created temporary tokens to create more tokens, eventually evolving into a “tree branch” structure.

Another technique coined “role chain juggling” can be taken advantage of to help attackers gain access to AWS resources indefinitely if a circular trust exists among two or more roles and assume-role calls can be chained an arbitrary number of times.

Summary

When it comes to security attacks, you shouldn’t underestimate the creativity of the attackers. IAM is notoriously complex. To combat common IAM threats and mitigate the risks, we should be aware of various exploitations, tools and resources used by malicious actors.