Identity and access management (IAM) misconfigurations are one of the most common concerns in cloud security. Over the past few years, these security holes have put organizations at increased risk of experiencing serious attacks to their cloud accounts.

To some, cloud environments might look like a safe place, where security is set by default. However, the truth is that security follows a shared responsibility model. For example, you are in charge of securing AWS console access.

However, what if a misconfiguration over your users or roles is applied in your environment? Attackers can use them to gain the keys to the kingdom, accessing your environment and creating serious damage. In scenarios where attackers are already in, misconfigurations can help them perform cloud lateral movement [1], exfiltrate sensitive data, or use the account for their own purpose (e.g., crypto mining [2]).

In this article, I put security best practices aside and have some fun focusing attention on real-world scenarios of IAM security misconfigurations. I'll showcase how it would be possible for an attacker to use those IAM misconfigurations and create serious hassles.

Big Deal?

AWS IAM [3] lets you manage access to AWS services and resources securely. With IAM, you can create and granularly manage AWS users and groups and use permissions to allow and deny them access to AWS resources.

From this definition of IAM, you can easily agree that this piece of infrastructure needs your focus. If this service is misconfigured, users or groups might cause huge damage to your infrastructure.

The fine granularity of permissions available in cloud environments allows the application of the least privileges concept [4], so carefully giving exactly what a user needs to perform their actions is absolutely fundamental. Just one misconfigured privilege could lead to an attacker escalating the privileges inside the environment.

Also important to highlight is that it is often not just a single permission that could allow the user to perform unwanted actions, but the combination of this single misconfigured permission with all the others already owned by the user (Figure 1). Therefore, even a little misconfiguration might be a big deal for the entire account.

Figure 1: The cloud permissions gap can be a combination of a misconfiguration and all permissions already assigned to a user.

With that in mind, it's time to deep dive into real-world scenarios and take a closer look at three AWS misconfigurations to understand the huge effect they can have in your environment.

Scenario 1: Creating a New Policy Version

In this scenario, an attacker finds valid credentials on a pastebin data-sharing website and is able to access the cloud environment [5]. It turns out that the compromised user has the permission to create a new version of one of their IAM policies, which allows the attacker to define their own custom permissions and gain full administrator access to the AWS account (Figure 2).

Figure 2: Scenario 1: Creating a new policy version.

The following commands let the attacker check information regarding the compromised user. In this case the attacker was able to log in to the cloud environment through the compromised user mallory :

$ aws sts get-caller-identity
$ aws iam list-attached-user-policies --user-name mallory

The first command reveals the user obtained the compromised username, and the second command looks at the policies attached to that user. Notice in Figure 3 that IAM_policy is attached.

Figure 3: Discovering attached policies.

If you use the get-policy method,

$ aws iam get-policy --policy-arn arn:aws:iam::<ARN-TARGET>:policy/IAM_Policy

you can extract even more information. Checking the permissions granted by this policy with the command:

$ aws iam get-policy-version --policy-arn arn:aws:iam::<ARN-TARGET>:policy/IAM_Policy --version-id v1

you can see the attached iam:CreatePolicyVersion permissions (Figure 4). To update a managed policy by creating a new policy version the attacker can use the privilege, along with the following JSON file, to create a new policy version, updating the policy and adding the AdministratorAccess AWS managed role to get full access to the environment:

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

Figure 4: Discovering privileges.

When creating the new policy version, the attacker needs to set it as the default for it to take effect. To do so, they need to have the iam:SetDefaultPolicyVersion permission. However, when creating a new policy version, it is possible to use the --set-as-default flag that will automatically create it as the new default version without requiring the explicit permission.

Magic?!

To create a new policy and escalate the privilege [6] inside the environment to the administrator, the attacker can use the command:

$ aws iam create-policy-version --policy-arn arn:aws:iam::<ARN-TARGET>:policy/IAM_Policy --policy-document file://privesc.json --set-as-default
{
  "PolicyVersion": {
    "VersionId": "v2",
    "IsDefaultVersion": true,
    "CreateDate": "2021-10-14T09:52:55+00:00"
  }
}

By checking the policy with get-policy, as before, you will see that the value in defaultVersionId has changed from "v1" to "v2".

If you now check the permissions granted by the new policy version, you will see that the privileges were successfully escalated to the full access role, according to the JSON file listed earlier.

As you can see in this real-world scenario, a user with a misconfigured IAM privilege (iam:CreatePolicyVersion in this case) could lead an attacker to a total compromission of a cloud account, and potentially to other connected accounts.