IAM Misconfiguration

Amritha S
4 min readDec 14, 2020

AWS Identity and Access Management (IAM) is used to manage access to AWS services and resources. Using IAM, we can create and manage its users as well as groups and use various permissions to allow or deny access to the AWS resources.

IAM misconfigurations are the common security weakness in AWS which makes it very important to address it as attackers can use them to access sensitive resources, with a malicious intent to steal information or damage one’s business as well as reputation.

Some of the most common IAM misconfigurations are listed below:

IAM Password Policy:

By implementing proper password strength, pattern, and rotation we can maintain the security of your AWS account. A strong password policy will significantly reduce the risk of password-guessing and brute-force attacks. The below password policy is configured properly.

Strongly configured IAM password policy

Lack of MFA:

In today’s world of rampant breaches, multifactor authentication (MFA) should be implemented for every authentication where possible.

MFA-protected root accounts will protect the AWS resources and services against attackers. An MFA device signature adds an extra layer of protection to our existing root credentials that make the AWS root account difficult to penetrate without the MFA generated passcode.

Overly Permissive IAM Resource:

IAM permissions that are given to the IAM resources are usually overly permissive and allow for an escalation of privileges within the AWS environment.

Overly permissive IAM Resource

In the above image, “iam:*” includes “iam:AttachUserPolicy”, “iam:PutUserPolicy” which allows the attacker (when the account is compromised) to create or modify the existing policy and gain administrative access to our AWS account.

Providing the right permissions for our IAM user (following the principle of least privilege) will significantly reduce the risk of unauthorized access to your AWS resources and services.

IAM policies are attached directly to a user:

When the IAM policies are attached to the user, it will be difficult to manage the user-based access to AWS resource when they receive different roles in the organization which leads to IAM policy misconfiguration. To check if the IAM users have any policies attached, the following command is used:

aws iam list-attached-user-policies — user-name $username

If the AttachedPolicies is empty, the user does not have any policies attached directly, and incase the AttachedPolicies is not empty, the selected user has policies attached. The below output shows an example if a policy is attached to the IAM user which is not a good practice.

Policy attached directly to IAM user

IAM Policies With Full Administrative Privileges:

Providing full administrative privileges instead of restricting to the minimum set of permissions can expose your AWS resources to potentially unwanted actions. Below is an example of an IAM policy that provides full administrative access.

IAM policy with full Administrative privilege

User access keys and SSH keys are not rotated every 90 days:

Rotating IAM credentials and access keys periodically will significantly reduce the chances of using a compromised set of access keys without your knowledge to access certain components within your AWS account.

AWS CLI command for list Access key information:

aws iam list-access-keys — user-name $username

AWS CLI command for list SSH key information:

aws iam list-ssh-public-keys — region $region — user-name $username

Below is an example to check the metadata for each access key of a particular user.

Access key metadata

Check the “CreateDate” value for each active key. If it is greater than 90 days then the key is outdated and it must be rotated to secure access to your AWS resources.

Reference:

--

--