Interview at Black Hat USA with Shir Tami and Ami Luttwak from Wiz.io
The notion that AWS accounts are isolated from AWS accounts belonging to other companies was undone during an August 4 demonstration by Wiz.io security researcher Shir Tamari and CTO/co-founder Ami Luttwak at Black Hat 2021 in Las Vegas.
The two of them sat down for a follow up interview after their demo on Wednesday and explained how insecure settings in AWS services can allow cross-account access that may expose data to other AWS accounts and allow anyone to read/write/run code to specific resources within them.
“These are complex security settings that developers need to be aware of when they are building to the cloud,” Luttwak explains. “AWS fixed the flaw in January, but developers still need to check each of these permissions and change the settings.”
For example, they demonstrated how to manipulate one of AWS’ most ‘trusted’ services, CloudTrail Logs (used for collecting cloud logs across multiple cloud accounts into a centralized bucket) and give anyone the ability to write into other customer’s cloudTrail buckets. In another example, they showed how the AWS Config service can be manipulated to create an AWS resource policy that allows anyone to write service logs into other customer accounts. Here’s how the exploit works:
- The attacker configures CloudTrail on their account to write logs into a target bucket. The chosen target bucket is located in the customer account.
- CloudTrail collects the logs and writes into the customer bucket, unknowingly serving the attacker and acting on their behalf.
- The bucket allows access since CloudTrail is trusted by the bucket.
“Amazon quickly fixed the vulnerabilities by adding conditions to the underlying resource policies, but developers themselves must modify and update their resource policies,” Tamari says. “We’ve identified 25 out of 260 AWS services that developers will need to manually modify like this.”
This is difficult for users and developers to manage during build and deploy processes. So now, five months after the bugs and fixes were announced, 90% of serverless repository buckets are still improperly configured, according to a Wiz.io survey; and over 25% are still using the misconfigured CloudTrail policy.
“The responsibility is currently on developers to do these restrictions manually in each of the 25 services we’ve identified,” Tami continues. “When they give access to the back end, they need to manually go in and restrict access to CloudTrail and other services like it.”
Ultimately, checks for these misconfigurations should also be included in static analysis engines for infrastructure-as-code. But because these bugs and resulting configuration requirements are so recent, Luttwak contends that most SAST tools don’t yet have visibility into these services.
For more information, he suggests visiting their blog on the subject, where they will soon release the 25 services that need their permissions to be manually configured. The Wiz.io cloud infrastructure security platform already has this covered, Luttwak adds.
The Wiz.io team is also trying to rally industry experts and developers to help build and maintain a centralized cloud vulnerability database, and they have started a Slack channel around it here: https://bit.ly/cloud-cve-db.
“We’re calling on DevOps experts, the National Institute of Standards and Technology (NIST), and others with a stake in cloud vulnerabilities to get involved in an international Cloud CVE database,” Luttwak adds. “Developer organizations like GitHub are also invited.”
