Researchers at Palo Alto’s Unit 42 have confirmed that they have compromised a customer’s AWS cloud account with thousands of workloads using a misconfigured identity and access management (IAM) role.
The researchers found that 22 application programming interfaces (APIs) across 16 different AWS services could be abused in the same way by attackers.
The discovery was important, Unit 42 said in a blog post, because malicious actors could obtain the roster of an account, learn the organization’s internal structure and potentially launch targeted attacks against individuals.
AWS services that can be potentially hit by attackers include Amazon Simple Storage Service (S3), Amazon Key Management Service (KMS) and Amazon Simple Queue Service (SQS).
According to Unit 42, the crux of the issue was that AWS’s backend proactively validates all the resource-based policies attached to Amazon S3 buckets and customer-managed identity keys. Resource-based policies usually include a principal field that specifies the identities (users or roles) allowed to access a resource. If the policy does not contain an identity, the API call that creates or updates the policy will fail with an error message. This convenient feature can be abused to check whether an identity exists in an AWS account. Bad threat actors can repeatedly invoke these APIs with different principals to enumerate the users and roles in a targeted account.
In addition, the account targeted can’t observe the enumeration because the API logs and error messages only appear in the attacker’s account where the resource policies are being manipulated. The “stealthy” aspect to this technique makes detection and prevention difficult for security teams. The result: Attackers can have unrestricted time to perform reconnaissance on random or targeted AWS accounts without worrying about being detected.
Charles Ragland, security engineer at Digital Shadows, said the shift towards hosting workloads in the cloud rather than locally has presented many new security issues. Security teams often find configuring IAM policies complicated and time-consuming, but it has to get done. That’s why Ragland said 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’s possible when an IAM policy is misconfigured and leaks information,” Ragland said. “In an ideal world, 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, vice president, strategy at WhiteHat Security, added that APIs are fast-becoming the vehicle for customer experience personalization. In the case of AWS, Kulkarni said their APIs are critical for DevOps and TechOps teams to reduce their time to market.
“APIs are a double-edged sword – when implemented poorly, they provide unprecedented access to core transactional business systems,” Kulkarni said. “In this case, a poor implementation of error and exception handling created an inadvertent opportunity to exploit a combination of the APIs to get access to account information.”
Unit 42 offers the following remedies to bolster IAM security:
- 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 AWS 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 for every user and IAM role
