Home AWS IAM Exploitation
Post
Cancel

AWS IAM Exploitation

What is IAM?

In AWS Identity and Access Management (IAM) is a web service that helps you securely control access to AWS resources. You use IAM to control who is authenticated (signed in) and authorized (has permissions) to use resources. It helps you set up users and groups, and shows you how to protect your resources with access control policies. It also shows how to connect to other identity services to grant external users access to your AWS resources.

So, a simple misconfiguration in IAM can lead to privilege escalation, which then can lead to furthur exploitations.

Policies

The IAM uses policies (JSON format) for assigning actions for the users and roles which are attached to ceratin groups. Services like S3 bucket for example have policy attached to them which allow users to do certain actions like listing bucket files or uploading files to the bucket etc. Some services can have policies attached to them in the form of roles, that can be in the form of either a service-linked roles, where the service is granted to the role or having a role attached to a component in the service.

Policy is attached to a resource, such as a user account, EC2 instance, or internal AWS function, allowing that resource to make API calls to execute actions within the account. A policy that allows a user to retrieve objects from an S3 bucket may look like this:

1
2
3
4
5
6
7
8
9
{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject"
  ],
  "Resource": [
    "arn:aws:s3:::my-bucket/*"
  ]
}

Types of IAM policies

1
2
3
4
5
6
Identity-based policies
Resource-based policies
Permission boundaries
Organizations service control policies (SCPs)
Access control lists (ACLs)
Session policies

Overly-permissive IAM policies

If policies assigned in IAM permissions to a user, an attacker could use IAM API calls to elevate his privileges. Example: Consider a AWS user Alice only has privileges to access IAM API calls, IAM:* for short Alice uses those privileges to create a new user: Bob Alice creates a new role with permissions to access all AWS services Alice assigns the newly created role to Bob Alice creates access keys for the user Bob

The permission set assigned to the user Bob would look like:

1
2
3
4
5
6
7
8
9
10
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

To run this attack Alice requires at least these IAM permissions:

1
2
3
  CreateUser
  CreateAccessKey
  PutUserPolicy

It is important to notice that it would be also possible to achieve the same goal using other calls to the IAM service, for example it is possible to create a group, assign the policy to that group and then make the newly created user part of the group; or even make Alice part of the new group with high privileges.

Dangerous permissions for users:

Policy attachment: The attacker can directly escalate their privileges by attaching a policy containing permissions higher than their own to their user, role, or a group of which their user is a member. Related permissions:

1
2
3
4
5
6
  > iam:PutGroupPolicy
  > iam:PutRolePolicy
  > iam:PutUserPolicy
  > iam:AttachGroupPolicy
  > iam:AttachRolePolicy
  > iam:AttachUserPolicy

Policy versioning: The attacker can create a new version of a policy attached to their user entity that has higher permission or they can revert their existing policy to an older version with more permissive/different grants. Related permissions:

1
2
  > iam:CreatePolicyVersion
  > iam:SetDefaultPolicyVersion

Group management: The attacker can move their user to a group that grants greater privileges. Related permissions:

1
  > iam:AddUserToGroup

User Management: The attacker can create or change the console access credentials for another user then log into the console as that user or generate a new access key for another user then call the APIs directly. Related permissions:

1
2
3
  > iam:CreateLoginProfile
  > iam:UpdateLoginProfile
  > iam:CreateAccessKey

Service roles: The attacker can pass a privileged role to an AWS service then access its temporary credentials in order to perform privileged actions. Related permissions:

1
  > iam:PassRole

For services like EC2 require additional permissions, such ec2:AssociateIamInstanceProfile. This permission is an extremely dangerous one to grant as it can be used to escalate privileges via a confused deputy attack.

A confused deputy attack is when a entity with a set of permissions is induced to act in a manner specified by another entity. The malicious entity is then able to perform some privileged action it otherwise could not by abusing the victim entity.

Methods and Tools to Enumerate IAM:

During Pentesting if you get your hands on a set of AWS credentials and have no idea which permissions it might have then you can use the following set of tools:

Principal Mapper: PMaapper

Principal Mapper (PMapper) is a script and library for identifying risks in the configuration of AWS Identity and Access Management (IAM) for an AWS account or an AWS organization. It models the different IAM Users and Roles in an account as a directed graph, which enables checks for privilege escalation and for alternate paths an attacker could take to gain access to a resource or action in AWS.

PMapper includes a querying mechanism that uses a local simulation of AWS’s authorization behavior. When running a query to determine if a principal has access to a certain action/resource, PMapper also checks if the user or role could access other users or roles that have access to that action/resource. This catches scenarios such as when a user doesn’t have permission to read an S3 object, but could launch an EC2 instance that can read the S3 object.

Pacu:

Pacu is an open-source AWS exploitation framework, designed for offensive security testing against cloud environments. Created and maintained by Rhino Security Labs, Pacu allows penetration testers to exploit configuration flaws within an AWS account, using modules to easily expand its functionality. This tool currently supports a range of attacks, including user privilege escalation, backdooring of IAM users, attacking vulnerable Lambda functions, and much more.

Remediation:

Do not allow any IAM entity to Add, Update, Modify, Delete Policies within the AWS account.

This post is licensed under CC BY 4.0 by the author.