AWS APIs Can Be Abused to Leak User Information to Hackers

• API abuse possibilities in AWS enable actors to perform account enumeration.
• This is not as critical for AWS security as it is for the potentially exposed organization.
• The hacking attempts are stealthy, but there are ways to mitigate the risk effectively.

Researchers of the ‘Unit 42’ team have discovered a way to abuse 22 APIs from 16 different AWS (Amazon Web Services) services to leak IAM user and role information. The abuse method works on S3 (Simple Storage Service), KMS (Key Management Service), and the SQS (Simple Queue Service).

It allows a malicious third-party to access sensitive details about the accounts of a company, the organization’s internal structure, etc. This could then lead to BEC phishing, greatly increasing its chances for success.

Without further ado, the following appendix lays out the APIs that can be abused:

The main problem here is that the AWS backend puts convenience above security, allowing someone to check if an identity exists in an account by abusing a resource-based policy. To make matters worse, the targeted account wouldn’t realize this abuse, as there are no API logs or error messages delivered to them.

Only the attacker would get the error messages, which is an integral part of the abuse. Thus, attackers could keep on doing that without raising any alarms, targeting AWS accounts until they end up with something useful.

So, if you can’t realize the abuse, is there anything you can do to at least prevent it? Unit 42 team gives some advice on that part, so the answer is yes, you can mitigate the risks and prevent AWS account enumeration. Here are some key recommendations to help you with that:

• Remove inactive users and roles to reduce the attack surface.
• Add random strings to usernames and role names to make them more difficult to guess.
• Log in with identity provider and federation so that no additional users are created in the AWS account.
• Log and monitor all the identity authentication activities.
• Enable two-factor authentication (2FA) for every user and IAM role

Unit 42’s “red team” exercise may lead to API policy changes by Amazon, but there’s nothing concrete yet. We have reached out to a couple of experts for commentary on the AWS API abuse potential, so here’s what they had to say.

Charles Ragland of Digital Shadows told us: “The shift towards hosting workloads in the cloud rather than locally has presented many new attack vectors. Appropriately configuring identity and access management (IAM) policies can be complicated and time-consuming. Organizations should always strive to grant each user the least amount of privilege possible in case of a potential account compromise. An organization’s DevOps team could use one of the available IAM configuration auditing tools to look for potential weaknesses or misconfigurations and mitigate them before they become an issue.”

Setu Kulkarni of WhiteHat Security commented: “Often, API security is narrowly and wrongly defined to only include API management. API security should include API security testing to make sure that the APIs do not suffer from AppSec vulnerabilities. One may even argue that API security testing should also include “business logic assessments,” which provides organizations the visibility into how a poorly designed API can reveal information that can be used as input into another API to get unprecedented access into not just more customer data but also to executing functionality on behalf of the customer.”