IAM users are challenging to securely manage at scale
AWS Identity and Access Management (IAM) users can be used to authenticate humans, either by setting up a password that allows access to the AWS Console or a long-lived access key that allows authentication to the AWS API. Access keys are also frequently used to authenticate workloads.
Because access keys are static credentials that do not expire, they are widely regarded as highly sensitive and a major cause of AWS security breaches. A 2022 GitGuardian study found that, on average, every 10,000 Git commits leak 84 AWS access keys. Access keys are frequently leaked (e.g., in logs, build outputs, stack traces) and targeted by attacker groups such as TeamTNT.
In particular, we found that:
- 40 percent of IAM users have not used their credentials in the past 90 days (access key or console password), affecting 70 percent of organizations.
- 40 percent of organizations have at least one IAM user that has AWS Console access and does not have multi-factor authentication (MFA) enabled, accounting for a 10 percent of all IAM users. Without the additional protection of MFA, these users are particularly vulnerable to credential stuffing and brute force attacks.
Furthermore, among IAM users with active access keys:
- 25 percent of IAM users have an active access key that’s both older than one year and hasn’t been used in the past 30 days. This combination of characteristics typically corresponds to IAM users that are unused and should be removed.
- 75 percent of IAM users have an active access key that’s older than 90 days. Rotating IAM access keys is highly challenging, especially at scale.
This data highlights the difficulty of properly managing IAM credentials when, for instance, an employee leaves the company or an application is decommissioned. Furthermore, it reinforces the importance of not using IAM users to authenticate humans and workloads when other, safer alternatives are available, such as AWS IAM Identity Center (formerly AWS SSO) for humans and EC2 instance roles or Lambda execution roles for applications.
IAM root user credential usage is low, but still represents a risk
The root user is automatically provisioned when an AWS account is created. This user has unlimited administrative permissions. In particular, it can download any sensitive data and even completely delete the whole AWS account. To reduce risk, it is a best practice to avoid creating any access keys for the root user in the first place.
However, we identified that:
- Roughly 10 percent of organizations have an active root user access key. This represents 3 percent of all AWS accounts. Some of these keys are up to 13 years old.
- 25 percent of organizations had used root user credentials in the 30-day period preceding the making of this research.
Usage of root user credentials does not always automatically signal a red flag. These credentials are required in highly specific situations, such as changing AWS account settings. However, the overhead of maintaining active root user access keys represents a significant risk, as long-lived static credentials often end up being leaked in source code, configuration files, logs, or stack traces and are responsible for many documented AWS customer security breaches. Compromised root user credentials can be particularly problematic because they grant unrestricted access to the entire account.
The complexity of AWS IAM leads to publicly exposed resources
When using services such as Amazon Simple Queue Service (SQS), Amazon Simple Notification Service (SNS), or Amazon S3, organizations commonly configure cross-account access by using a resource-based IAM policy attached to the resource itself.
We identified that:
- 18 percent of organizations that use SQS have at least one publicly exposed queue, allowing anyone to receive or publish messages to those queues.
- 15 percent of organizations that use SNS have at least one publicly exposed topic, allowing anyone to perform sensitive actions against those topics (e.g., retrieving or publishing notifications).
- 36 percent of organizations that use S3 have at least one publicly exposed bucket, representing 2 percent of all S3 buckets.
We assess that this can be attributed to the complexity of creating AWS IAM policies that grant only required permissions. Creating secure IAM policies that grant least-privilege, granular permissions can be difficult in complex environments that involve many teams, applications, and ephemeral resources. After encountering one too many “access denied” errors, teams may find it more convenient to create less restrictive IAM policies in order to avoid bottlenecking their workflows.
This problem is so prevalent that members of the community have developed tools like Repokid and Policy Sentry to address various IAM-related pain points. Although these tools can help, they also highlight the ongoing challenges of crafting IAM policies that grant necessary permissions—and keeping them up to date as those requirements change—without blocking workflows.
The Instance Metadata Service V2 (IMDSv2) is not enforced by default, leaving EC2 instances at risk
Server-side request forgery (SSRF) is an application-level vulnerability that has been consistently and frequently exploited by attackers for years. In AWS, this type of vulnerability allows an attacker to trick an application into calling the EC2 Instance Metadata Service (IMDS) in order to successfully obtain credentials bound to an instance role. An attacker can then use these credentials to authenticate against the AWS API or access the AWS Console ).
This technique has been used in several high-profile incidents, such as the Capital One breach, and was even called out by name by U.S. Senator Ron Wyden in a letter to AWS: “A number of cybersecurity experts have publicly speculated that the Capital One hacker exploited a Server-Side Request Forgery (SSRF) vulnerability, a flaw about which experts have been warning for years. To the best of Amazon’s knowledge, was a SSRF attack used to gain access to Capital One’s customer data?”
In 2019, AWS released version 2 of the EC2 IMDS (IMDSv2) to help mitigate this vulnerability. However, we identified that the vast majority of EC2 instances (93 percent) are not enforcing the usage of IMDSv2. Overall, 95 percent of organizations that use EC2 have at least one vulnerable instance.
We believe that this can be attributed to a lack of secure defaults. Unless explicitly configured to enforce version 2, newly created EC2 instances still allow the use of version 1 of the IMDS, leaving them vulnerable to SSRF attacks.
At least 40 percent of organizations use multiple AWS accounts
Adopting a multi-account strategy in AWS is essential for limiting the blast radius of a compromised application or user account, among other benefits. However, some early stage organizations may opt to use a single AWS account in order to reduce the overhead of creating and managing multiple accounts. Services such as AWS Organizations are designed to help address this concern by centralizing account governance and automating the creation of new AWS accounts (e.g., by using infrastructure as code).
Our data shows that at least 41 percent of organizations have adopted a multi-account strategy in AWS.
Six percent of organizations heavily implement a multi-account strategy by using more than 10 AWS accounts. Furthermore, a long tail of 0.6 percent use more than 100 AWS accounts—and some of these organizations have several thousands of AWS accounts.
These figures should be interpreted as lower bounds, because organizations using Datadog may not monitor all of their AWS accounts, such as those used for testing or development purposes.
