Unit 42 researchers discovered a class of Amazon Web Services (AWS) APIs that can be abused to leak the AWS Identity and Access Management (IAM) users and roles in arbitrary accounts.
More than 20 application programming interfaces (APIs) associated with 16 Amazon Web Services products can be abused to give up basic information about users and their roles, according to Unit 42, the research arm of cybersecurity giant Palo Alto Networks. AWS services that can be potentially abused by attackers include Amazon Simple Storage Service (S3), Amazon Key Management Service (KMS) and Amazon Simple Queue Service (SQS).
A malicious actor may obtain the roster of an account, learn the organization’s internal structure and launch targeted attacks against individuals. In a recent Red Team exercise, Unit 42 researchers compromised a customer’s cloud account with thousands of workloads using a misconfigured IAM role identified by this technique.
"The root cause of the issue is that the AWS backend proactively validates all the resource-based policies attached to resources such as Amazon Simple Storage Service (S3) buckets and customer-managed keys. Resource-based policies usually include a Principal field that specifies the identities (users or roles) allowed to access the resource. If the policy contains a nonexistent identity, the API call that creates or updates the policy will fail with an error message. This convenient feature, however, can be abused to check whether an identity exists in an AWS account. Adversaries can repeatedly invoke these APIs with different principals to enumerate the users and roles in a targeted account," Palo Alto researchers write. "Furthermore, the targeted account can’t observe the enumeration because the API logs and error messages only appear in the attacker’s account where the resource policies are manipulated. The “stealthy” property of the technique makes detection and prevention difficult. Attackers can have unrestricted time to perform reconnaissance on random or targeted AWS accounts without worrying about being noticed."
Commenting on the news, Setu Kulkarni, Vice President, Strategy at WhiteHat Security, a San Jose, Calif.-based provider of application security, says, “APIs are fast becoming the vehicle for customer experience personalization. In the case of AWS, their APIs are critical for DevOps and TechOps teams to reduce their time to market. These APIs in question dramatically reduce the effort required by organizations to build cloud-based and cloud-native applications. However, APIs are a double-edged sword – when implemented poorly, they provide unprecedented access to core transactional business systems. In this case, a poor implementation of error & exception handling creates an inadvertent opportunity to exploit a combination of the APIs to get access to account information."
Often, adds Kulkarni, 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.”
Charles Ragland, security engineer at Digital Shadows, a San Francisco-based provider of digital risk protection solutions, explains that 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. The research performed by Unit 42 demonstrates what is possible when an IAM policy is misconfigured and leaking information. 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 in an ideal world,” he says.
