6 big AWS IAM vulnerabilities – and how to avoid them

What’s a cloud vulnerability? In the simplest terms, it’s an exploitable weakness in a cloud environment. Vulnerabilities are commonly caused by cloud resource misconfigurations and can lead to breaches and security failures — especially when the vulnerability is related to Identity and Access Management (IAM).

IAM is notoriously complex, and the ramifications of getting it wrong can be severe. According to our  State of Cloud Security 2021 report, IAM is the most commonly cited cloud misconfiguration (cited by 41% of respondents). And Verizon’s 2021 Data Breach Investigations Report states that 61% of analyzed breaches involved credentials.

In this blog post, we’ll present several AWS IAM-related vulnerabilities, along with tips for preventing them.

Vulnerabilities Involving AWS Credentials

Not rotating access keys

The vulnerability: Unrotated IAM access keys

Why it’s dangerous:  Access keys are long-term credentials that IAM users use to programmatically access the CLI or API. Access keys consist of an access key ID and secret access key. The longer access keys are active, the more opportunity there is for a bad actor to compromise them. Compromised access keys are just as dangerous as a compromised username and password.

How to fix it: CIS AWS Foundations Benchmark v1.4.0 recommends rotating access keys every 90 days or less. This can be done with the AWS Management Console, CLI, or API. The general steps are:

1. Create a new access key

2. Update applications to use the new key

3. Make the old key inactive

4. After ensuring applications are working, delete the old key

Find remediation steps here.

Reusing passwords

The vulnerability: Reusing a previously used password

Why it’s dangerous: As with access keys, the longer a password is active, the more opportunity there is for it to be compromised – and using the same password repeatedly doesn’t help. Additionally, there’s the possibility for credential stuffing attacks, which is where an attacker attempts to break into an account by trying many stolen usernames and passwords.

How to fix it: CIS AWS Foundations Benchmark v1.4.0 recommends setting a password policy where “Prevent password reuse” is enabled and “Number of passwords to remember” is set to 24.  Find remediation steps here.

Not using MFA

The vulnerability: Not using MFA

Why it’s dangerous:  Multi-factor authentication (MFA) is an additional layer of protection for IAM users, and without it, only a username and password are required to log into AWS. Therefore, an attacker with a compromised set of credentials has the keys to the kingdom. When MFA is enabled for an account, however, a user must provide an additional piece of information in order to log in, such as a one-time code from a virtual or hardware MFA device. Without this information, the login will not succeed, and the attacker will be thwarted.

How to fix it: CIS AWS Foundations Benchmark v1.4.0 recommends that all IAM users with console access have MFA enabled.  Find remediation steps here.

Vulnerabilities Involving IAM Policies

Allowing broad list actions on S3 buckets

The vulnerability: IAM role policies allow broad list actions on S3 buckets

Why it’s dangerous: If an IAM role has a policy that allows broad list actions on S3 buckets, and a bad actor gets access to the role, they can enumerate all your buckets to figure out where you keep your data. Because s3 sync also requires list permissions, the bad actor can then potentially steal sensitive data from your buckets. The actions s3:ListAllMyBuckets, s3:List*, and s3:* are ones you’ll want to leave out of IAM policies if they’re not strictly needed. This vulnerability may have led to the Capital One breach of 2019; learn more at A Technical Analysis of the Capital One Cloud Misconfiguration Breach.

How to fix it: Remove the overly broad list permissions from the IAM policy. Find remediation steps here.

Allowing all principals to assume a role

The vulnerability: IAM role trust policies allow all principals to assume the role

Why it’s dangerous: Allowing any IAM user from any AWS account to assume a role in your account effectively grants them access to all of the permissions in that IAM role, which could be catastrophic and lead to privilege escalation, data exfiltration, and more. Make sure role trust policies don’t contain all of the following elements:

• Effect: “Allow”

• Principal: “*”

• Action: “sts:AssumeRole”

How to fix it: Replace the wildcard with a specific principal. Find remediation steps here.

Allowing full administrative privileges

The vulnerability: IAM policies allow full "*:*" administrative privileges

Why it’s dangerous: Having an IAM policy that allows all possible permissions for all possible services is a direct violation of the security principle of  least privilege. If a malicious actor were to gain access to a user or role with such a policy, they would have unlimited access to everything in your AWS account, and then it’s game over. It’s a better practice to assign only the permissions necessary, and nothing more.

How to fix it: Remove the wildcards from Allow policies where Action and Resource are both set to *.  Find remediation steps here.

IAM Tips and Best Practices

Here are a few best practices for working with IAM:

• Practice the security principle of least privilege. Only grant the permissions necessary to accomplish a task. It’s better to start with a minimally permissioned role and add permissions as needed than to start with administrative access and remove permissions.

• Exercise good password hygiene. You can create a password policy for users so they must fulfill a set of requirements when creating a password, such as a minimum length (CIS recommends at least 14 characters); a mix of letters, numbers, and symbols; and not reusing a previously used password. You can also set an expiration date so users are required to update their passwords every so often – say, every 90 days.

• Store credentials responsibly. Don’t save access keys or passwords in code repositories, even private ones; that’s how  Uber was hacked in 2016. Don’t share credentials between users, either.

• Monitor your IAM configuration so, whenever a policy is changed or an access key is activated or deactivated, you're aware of it. You should also write custom rules to enforce enterprise-specific needs. Does your organization require users to change their AWS password every 45 days? Have a solution in place that checks each AWS account for a password policy enforcing that requirement.

Want to keep learning? Check out our series on the top 5 most common AWS misconfigurations.