Over the past year, Wiz’s research team has discovered a range of new attack surfaces in the cloud. This week, we’re presenting two of them at Blackhat’s annual conference in Las Vegas. Because Wiz serves a broad base of enterprise customers, we have a unique perspective most researchers don’t -- we see whether the vulnerabilities we report to cloud providers result in effective fixes in customer environments.

How isolated are AWS accounts?

That feedback loop was critical to our research on a new class of “cross-account” vulnerabilities in Amazon Web Services (AWS). Customers use AWS (and other cloud providers) with the expectation that their cloud environments are completely isolated from other customers. We wanted to find out if this assumption was true.

So last November, our research team mapped all the services in AWS that allow access from other accounts to see if any of them might inadvertently expose customers. In just 10 days of research, we discovered three vulnerabilities in different AWS services that allow anyone to read or write into the accounts of other AWS customers.

Although it would be complex for malicious actors to exploit this vulnerability in the real world, the fact that it’s even possible to perform unauthorized operations on other customer accounts is a startling revelation. This is a new exposure vector that could allow an attacker to exfiltrate data from highly-secured environments without leaving a trace.

We reported the issues to Amazon in November 2020, and AWS moved quickly to address them. However, one of the vulnerabilities can’t be fixed by AWS alone -- every vulnerable user must update their existing policies. Our research indicates that over 90% of customers are still vulnerable to this day.

What’s more, we strongly suspect that many more services in AWS are vulnerable to this type of cross-account vulnerability.

How cross-account access works – and can be exploited

Simply put, resource policies allow different AWS services to access each other. Why is that important? These days, most cloud customers embrace a multi-account approach. Instead of managing all of their operations in one cloud account, they divide the activity into several cloud accounts, each of which has a specific environment for a specific purpose. It’s common for a company to have hundreds or thousands of accounts in AWS. To make this easier to manage, customers grant AWS services access to perform operations across their multiple accounts.

As an example, the popular CloudTrail service allows customers to collect logs from multiple accounts and centralize them in one bucket.

When customers grant access to an official AWS service, they trust it fully. Most of us wouldn’t think twice before giving AWS CloudTrail access to our S3 buckets and other cloud resources. So we were surprised to discover that in some cases, AWS services (CloudTrail, AWS Config and Serverless Repository) could be manipulated to give anyone access to the specific resources of other customers.

The vulnerabilities

In two of the vulnerable services, CloudTrail and AWS Config, the resource policy automatically set by AWS allowed anyone to write service logs into other customer accounts. Here is the breakdown of the vulnerable flow:

1. The attacker configures CloudTrail on their account to write logs into a target bucket. The chosen target bucket is located in the customer account.

2. CloudTrail collects the logs and writes into the customer bucket, unknowingly serving the attacker and acting on his behalf.

3. The bucket allows access since CloudTrail is trusted by the bucket.

The most severe vulnerability affected AWS’ Serverless Repository, a platform service that allows customers to store and deploy serverless applications. To work properly, the service needs to pull objects from customers’ S3 buckets – and customers don’t think twice before granting access to their buckets through a resource policy. We found a way to exploit the service to read from other customers’ private S3 buckets, which often contain sensitive information like source code, passwords, and other artifacts. This was even true for isolated accounts not connected to the internet.

Root cause

The root cause of the vulnerabilities is AWS services can be tricked into performing actions on an attacker’s behalf, and the target bucket trusts the service without conditions.

For example, as of last November, this was AWS’ default resource policy for an S3 bucket.

It allows an AWS service called Serverless Repository to access any object in the bucket. The problem is, it's very open-ended. Nowhere does this policy define or limit who can use the service to access information in any given customer’s S3 buckets.

In short, the default AWS policy was unsafe, and makes it effortless for malicious actors to move from one account to another, inflicting damage. Customers never had a chance to configure their resource policies securely – they were insecure by default.

Problem solved… or is it?

To their credit, Amazon acted quickly to fix the vulnerabilities by adding conditions to the underlying resource policies that better restrict access.

However, AWS can't fix this issue on its own. Only customers themselves can modify and update their resource policies. Resolving a vulnerability is always less effective when user-interaction is needed. In this case, Amazon sent alerts like the one below to vulnerable users via email and security notification in Amazon's Personal Health Dashboard.

Yet 5 months after the policies were fixed, a survey we conducted of AWS environments showed that over 90% of Serverless Repository buckets were still improperly configured and vulnerable. Our survey also found that over 25% of environments were still using the misconfigured CloudTrail policy.

Because these findings are based on one sample set, we can’t say whether they’re representative of AWS customer environments overall. But they do suggest a widespread lack of awareness that leaves many accounts exposed.

How do I protect my cloud environment?

Wiz has built-in controls that detect new cloud exposures, including these cross-account AWS vulnerabilities. Our customers can use this link to review any exposure in your account, or reach out to us to discuss.

If you’re not a Wiz customer, we’ll be publishing instructions on how AWS users should update their resource policies to prevent unauthorized access. AWS also plans to add these vulnerabilities to the AWS Access analyzer so all users can get out-of-the-box notifications for misconfigured service access.

Takeaways

Because this type of cross-account exposure is new, most customers are completely unaware they're at risk and many isolated environments are vulnerable to these data exfiltration vectors. What’s more, we believe the three vulnerabilities we found are the tip of the iceberg: Similar vulnerabilities likely exist in other AWS services.

This topic needs further investigation, and we hope our research will be the first of many. We're happy to work with any security team that wants to explore these issues further.

Cloud is the future, yet there hasn’t been enough exploration of the holes in the fabric of cloud infrastructure that our modern economy depends on.

There’s got to be a better way

The current process for reporting and tracking cloud vulnerabilities is broken. Cloud vendors quietly fix issues when they learn of them, but there is no central database of known cloud exposure risks. Users are responsible to fix these issues, but they have no way of knowing these gaps even exists.

That’s why we’re partnering with cloud vendors and other organizations to create a better process. Join our Slack group to help us start the revolution.