Evaluating IAM Misconfiguration to Secure Cloud Deployments

Although S3 bucket misconfigurations grab most of the headlines today, we will be looking at improperly configured AWS Identity and Access Management (IAM) policies. AWS permissions allow users to interact and control various services within the AWS architecture. Enumerating the roles and policies within an AWS account allows us to find possible avenues of privilege escalation.

In order to understand how misconfigurations in IAM are exploited, we must first understand IAM and how it works. AWS IAM provides customers with granular control over the access given to users and roles for resources. This control allows admins to provide users with access to single commands or even single resources. Think of it as giving your neighbor access to your shed to borrow tools but not to the front door of your house. We will first break down the differences between users and roles before diving into the policies providing authorization for those users and roles.

Users: AWS IAM users provide entities, usually individuals, a set of credentials to authenticate to AWS. The credentials provide access to the AWS Console or programmatic access in the form of keys and secrets.

Roles: AWS IAM roles are like users because roles provide identification and authentication. However, roles are assumed and do not provide credentials to sign in to the AWS Console nor are they unique to a person or resource. Roles also do not receive permanent keys and secrets but instead can be used to generate temporary credentials.

Policies: While users and roles are used for identification and authentication, policies are used for authorizing access to AWS resources. Policies are attached to users and roles and

provide fine-grained control for permissions. There are AWS managed policies, customer policies, and inline policies. Multiple policies can be attached to users and roles.

Now that we have looked at the basics of IAM, we can focus on the permissions that often lead to privilege escalation. The permissions we are interested in are ones that allow us to modify/attach policy, create or update login profiles, add a user to a group, assume a role, or pass a role. For more details on IAM permissions and policies, please refer to the following AWS site.

Examining policies and permissions for possible privilege escalation requires some knowledge of how policy precedence is handled by AWS. Permissions are implicitly denied until an explicit allow is created in a policy. An explicit allow trumps an implicit deny and an explicit deny overrules everything. As admins try to limit permissions, it is easy to lose sight of some commands and become careless. Escalation relies on these misconfigurations in policies that permit unintentional access. While we can manually search for these poorly configured permissions from the AWS Console or CLI, there are also tools that make IAM enumeration much faster. Enumerating users, roles, and policies quickly is important when working in a large environment. Many tools exist for this purpose, but we will be focusing on a tool called PMapper. Principal Mapper (PMapper) is a tool that allows users to identify configuration issues in AWS IAM. PMapper provides a visualization to map users and roles in an account to display attack vectors for privilege escalation. In order to gather the information necessary to simulate the attack vectors, we first need to run the following command.

The command allows us to enumerate IAM permissions. The profile being used requires read access to AWS IAM in order to list all the users, groups, roles, and policies in our account. This enumeration of privileges will let us take advantage of another feature of PMapper which is the use of queries. This query mechanism helps us find what resources or actions a specific principle can access. The following preset query can be used to find privilege escalation within our account.

This query tells PMapper to search for any users or roles that can gain “admin privileges” or access to all commands on all resources. The output provided by the command can be seen below:

This informs us the role/user-config-1 can create access keys to authenticate as our user/admin-user. The power behind the queries is policy simulation that happens locally on your machine without calling the IAM simulation APIs. PMapper recently received an update providing support for AWS Organizations, Service Control Policies (SCPs), session policies, resource policies, and permission boundaries.

In addition to testing your IAM implementation for misconfigurations, there are also other mitigations like the previously mentioned permission boundaries. IAM Permissions Boundaries, launched in 2018, is an “advanced feature for using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity. An entity’s permissions boundary allows it to perform only the actions that are allowed by both its identity-based policies and its permissions boundaries,” per AWS documentation. Enforcement of an IAM Permissions Boundary is an excellent way to help prevent privilege escalation through

IAM. By defining the maximum permissions that an IAM entity can have, you can ensure that, despite credentials being compromised, an attacker would be bound to only what the administrator has allowed through the policy.

Understanding how AWS IAM policies, roles, users, and groups work helps us in building secure granular permissions for our users. Misconfigurations in IAM can prove to be just as costly as open S3 buckets. IAM is the focal point of AWS access control and therefore needs to be tightly controlled and monitored. It is essential for companies to test implementations and provide mitigations as part of a defense in depth strategy. We will cover more open-source tools for securing and assessing compliance in your cloud environment in future posts.

About the Author

As the CSO and Senior Cloud Security Assessor at E-INFOSOL, Chad Thomas brings over 20 years of experience in various areas of the information security field. He currently provides assessments to certify secure implementation of cloud services. Before working at E-INFOSOL, he served as a leader in network security, pentesting, and risk and compliance assessments for various customers. Chad holds several certifications including CISSP and CCSP.