AWS APIs abuse: Watch out for these vulnerable APIs

In December 2020, Unit 42 researchers at Palo Alto Networks discovered a class of AWS application programming interfaces (APIs) that can be abused to enumerate sensitive information about a target’s AWS organization. The information at risk includes AWS identity and access management (IAM) users and roles. The affected APIs can be exploited across all three AWS partitions (aws, aws-us-gov and aws-cn). 

We will discuss what AWS APIs are, AWS resource-based policies, vulnerable AWS APIs and how to mitigate the risks associated with AWS APIs.

Learn Vulnerability Management

Get hands-on experience with dozens of courses covering vulnerability assessments, tools, management and more.

Start Learning

What are AWS APIs?

An API is software that allows applications to interact with each other either internally or over the internet. AWS APIs act as an interface between applications/services and AWS services. All access requests to AWS services (i.e., via the AWS management console, AWS SDKs and command-line tools) are calls made to AWS APIs in the background.

Popular AWS APIs include:

• AWS Elastic Compute Cloud (EC2) API
• AWS Simple Storage Service (S3) API
• AWS Relational Database Service (RDS) API
• AWS DynamoDB API

AWS resource-based policies

According to the researchers, bad actors can abuse AWS APIs due to the validation process in resource-based policies. AWS resource-based policies are policies that are attached to AWS resources such as Amazon S3 buckets. They usually include a field (i.e., the principal field) that specifies the identities (users or roles) that are allowed to access resources.

Policies are objects in AWS that define permissions of users or roles to specific resources in AWS. There are two types of policies in AWS:

• Identity-based policies
• Resource-based policies

Resource-based policies are policies attached to AWS resources such as AWS S3 buckets, AWS SQS queues and AWS KMS encryption keys. As of December 2020, there are about two dozen AWS services that support resource-based policies. With resource-based policies, you can specify who has access to the resource (i.e., the principal) and what actions they can perform on the resource.

Principals may include accounts, IAM users, federated users, IAM roles, assumed-role sessions or AWS services.

Vulnerable AWS APIs

When executing policies on AWS, AWS validates the principal associated with the policy. If the policy contains a non-existent principal or an invalid username or role name, the validation process fails, resulting in an error message. The error message provided by AWS for an invalid username or role name differs from the error message for a non-existent principal. This vulnerability allows a bad actor to perform a brute force attack on the principal to enumerate identities that exist in the target’s AWS organization, based on the information provided in the error message.

These activities (the API calls, API logs and error messages) are not logged in the target’s AWS account. The activities are logged in the AWS CloudTrail logs of the bad actor. The target is unaware of the reconnaissance taking place making detection and prevention difficult.

The following AWS services are vulnerable and can be abused by attackers via AWS APIs:

• AWS Simple Storage Service (S3)
• AWS Key Management Service (KMS)
• AWS Simple Queue Service (SQS)

How to mitigate the risks associated with malicious AWS APIs

The following are AWS IAM best practices that can be deployed to mitigate the risk associated with AWS APIs:

• Restrict the use of the AWS root account (i.e., the initial account created when you first create an AWS account, which has complete access to all AWS services and resources)
• Enable multi-factor authentication (MFA) for all IAM users (including the root account). AWS Config can be used to generate reports on users and their MFA status
• Disable users and/or credentials that are inactive (i.e., have not been used for 60-90 days or more). This reduces the chance that compromised credentials can be exploited by bad actors
• Ensure that access keys (i.e., access key ID and secret access key) are rotated every 60-90 days
• Assign permissions and privileges on a group or role basis rather than on an individual IAM user basis
• Ensure AWS CloudTrail is enabled in all regions. AWS CloudTrail is a service that records AWS API calls for your account (i.e., the identity of the API caller, the time of the API call, the source IP address of the API caller etc.)
• Ensure AWS CloudTrail trails are integrated with AWS CloudWatch Logs
• Ensure a log metric filter and alarm exist for unauthorized API calls. Perform real-time monitoring of API calls by directing AWS CloudTrail logs to AWS CloudWatch Logs, and establishing corresponding metric filters and alarms

Learn Vulnerability Management

Get hands-on experience with dozens of courses covering vulnerability assessments, tools, management and more.

Start Learning

Conclusion

Detecting the reconnaissance process by bad actors can be difficult as the AWS CloudTrail logs and error messages do not appear in the target’s AWS account. However, the impact of the attack can be reduced by implementing the above-mentioned controls in your AWS organization.

Sources

1. Unit 42 - Palo Alto Networks, Information Leakage in AWS Resource-Based Policy APIs
2. Dark Reading, Nearly Two Dozen AWS APIs Are Vulnerable to Abuse
3. AWS, CIS AWS Foundations Benchmark Controls
4. AWS, Security best practices in IAM
5. Stratoscale, The 7 Most Popular AWS APIs
6. Dummies, APIs and How They Work in Amazon Web Services