Nearly Two Dozen AWS APIs Are Vulnerable to AbuseNearly Two Dozen AWS APIs Are Vulnerable to Abuse
Attackers can conduct identity reconnaissance against an organization at leisure without being detected, Palo Alto Networks says.
November 17, 2020
Nearly two dozen application programming interfaces (APIs) across 16 different Amazon Web Services offerings can be abused to allow attackers to obtain the roster and internal structure of an organization's cloud account in order to launch targeted attacks against individuals.
All that a threat actor would require in order to carry out the attack is the target organization's 12-digit AWS ID — something that is used and shared publicly — Palo Alto Networks said this week.
In a report, the security vendor said that all of the affected APIs could be abused in the same way across all three of AWS's partitions or regions (aws, aws-us-gov, and aws-cn). The Amazon services that are vulnerable include Amazon Simple Storage Service (S3), Amazon Key Management Service (KMS), and Amazon Simple Queue Service (SQS).
Jay Chen, senior cloud researcher for Unit 42 at Palo Alto Networks, says the problem has to do with an AWS design feature that is meant to help users avoid typos and mistakes when writing a policy. "The error messages inadvertently give out too much information, so that an attacker can find out if a particular user or role exists in another AWS account."
Specifically, the cause of the issue lies with how AWS's identity and access management function handles a specific type of policy — known as resource-based policy — that is associated with AWS resources such as an S3 bucket or an Amazon EC2 instance. In total, 26 AWS services support resource-based policies.
According to Palo Alto Networks, AWS resource-based policies include a field that specifies the users or roles that are allowed to access specific resources. If a policy contains an identity that isn't included in the field, the API call associated with the policy will return an error message. While the feature is useful, attackers can easily abuse it to try and enumerate or discover all of the users and roles associated with an organization's AWS account.
"For example, if an attacker knows a company's AWS account ID, the attacker could use this information to ask in a resource-based policy 'does user X exist in this account?'," explains Chen.
By specifying different user or role names in a resource-based policy, the attacker can quickly learn from the error message if a particular role or user exists in the target account. "The attacker can keep asking this question with different names and eventually map out all the users/roles in this account," Chen says.
This would enable the attacker to launch other attacks, like searching for misconfigured roles that could be exploited or sending highly targeted spear-phishing emails to individuals in an organization. Significantly, AWS doesn't currently log such activity, so the target organization would not be aware of the identity reconnaissance being conducted against its account, Chen says.
Easy to Abuse
"Basically, the APIs need user information to be invoked," says Setu Kulkarni, vice president of strategy at WhiteHat Security. "When the user information is not valid, the API invocation results in an error message — explicitly to the hacker stating that the said user does not have access." A hacker with a list of Amazon accounts could cycle through users lists to invoke a specific API and performance reconnaissance, Kulkarni says.
With enough time, an attacker could brute-force a list of users and role policies and look for misconfigurations that would enable account takeover, says Charles Ragland, security engineer at Digital Shadows. "The major issue with the vulnerability is that the error messages are logged in the attacker's account; therefore, the victim will be unaware of this attack."
AWS did not respond immediately to a Dark Reading request for comment on Palo Alto Network's research.
The issue that Palo Alto Networks discovered with Amazon's APIs is the latest example of what many security experts say is the growing threat to enterprise security from insecure APIs. A Forrester Research report earlier this month described API-related breaches as becoming increasingly common and presenting the next big attack vector for threat actors. According the analyst firm, APIs that open enterprise data and services to the Internet present the same risk to enterprise security as vulnerable web applications. However, many organizations are not addressing them with the same rigor or focus, Forrester said.
Chen says organizations can mitigate the potential impact of the AWS threat that Palo Alto Networks discovered by practicing identity and access management best practices. Measures that can help include removing inactive usernames and roles, adding random strings to user and role names to make them harder to guess, and implementing controls for ensuring additional users aren't created in the AWS account without proper authorization. Enabling two-factor authentication and logging and monitoring of all identity authentication activities are also essential, Chen says.
About the Author(s)
You May Also Like
Hacking Your Digital Identity: How Cybercriminals Can and Will Get Around Your Authentication MethodsOct 26, 2023
Modern Supply Chain Security: Integrated, Interconnected, and Context-DrivenNov 06, 2023
How to Combat the Latest Cloud Security ThreatsNov 06, 2023
Reducing Cyber Risk in Enterprise Email Systems: It's Not Just Spam and PhishingNov 01, 2023
SecOps & DevSecOps in the CloudNov 06, 2023
Passwords Are Passe: Next Gen Authentication Addresses Today's Threats
How to Deploy Zero Trust for Remote Workforce Security
What Ransomware Groups Look for in Enterprise Victims
How to Use Threat Intelligence to Mitigate Third-Party Risk
Securing the Remote Worker: How to Mitigate Off-Site Cyberattacks