Why Some Cloud Services Vulnerabilities Are So Hard to Fix

It’s a familiar story: A feature designed for convenience is used to sidestep security measures. In this presentation from Black Hat USA 2021, a pair of researchers show how they found three separate ways to hop between accounts on AWS. Even though fixes for those vulnerabilities were released quickly, the holes reveal that cloud services do not offer the level of isolation expected. The long-term solution may mean changing how the cybersecurity sector handles CVEs.

For the first two isolation breaches, Wiz.io CTO Ami Luttwak and head of research Shir Tamari altered the path prefixes on AWS CloudTrail and Config to allow a user to write to another user’s S3 bucket. The third method used the AWS command line to download files from another user’s account via the serverless repository.

Sending the logs from several S3 buckets to one is intended for the convenience of an admin who runs several instances, Luttwak and Tamari said in their presentation, “Breaking the Isolation: Cross-Account AWS Vulnerabilities.”

“I learned from this behavior that CloudTrail can write to resources that are owned and managed in other accounts,” Tamari added. “And for me, a security researcher, there is a concern.”

Customers Notified, So What Happened?

While Amazon did not have the power to fix the configurations for customers itself — because the fixes involved setting the source account you want, which only the user can decide — it contacted all affected customers to explain the potential problem and how to fix it. Yet when Wiz.io went back after five months, it found that 90% of accounts had not applied the fixes.

Luttwak pointed out that the security team AWS messaged often didn’t get the warnings because of the sheer number of accounts they run.

“How do you know this is an important fix to do?” he asked. “And the more we thought about it, the more we understood, this is a big, big problem.”

Right now, the system of CVEs allows organizations to check on the latest vulnerabilities, complete with a numerical system of classifying severity and links to vendors’ fixes. That works pretty well in most areas of IT. However, cloud vulnerabilities may not get assigned CVE numbers.

“This is because cloud services, as we currently understand them, are not customer controlled,” wrote Cloud Security Alliance IT director Kurt Seifried and research analyst Victor Chin. “As a result, vulnerabilities in cloud services are generally not assigned CVE IDs.”

The Amazon Exception

CVEs take pains to point out that cloud services vulns can indeed receive a CVE ID, as long as the owner of the software is the CVE numbering authority (CNA) reporting them. Rule 7.4.4 says the CNA “may” assign a CVE number if it owns the product or service, even if it is not customer controlled and the fix requires customers to take action.

But here’s the sticky wicket: Rule 7.4.5 states, “CNAs MUST NOT assign a CVE ID to a vulnerability if the affected product(s) or service(s) are not owned by the CNA, and are not customer controlled.”

In short, the real reason why these AWS vulnerabilities were not issued CVEs is that Amazon is not a CNA partner. Microsoft can issue CVEs for its own products and services, as can Google. Whether the appropriate fix is changing the rules to allow any CNA to assign IDs to vulns whose fixes are out of customers’ hands or to sign up Amazon as a CNA depends on your perspective. In June 2022, Wiz.io took matters into its own hands by establishing a community database of cloud vulnerabilities to fill the gap.

As Luttwak said, “There’s hundreds of services in AWS, and many of them are getting more and more cross account capabilities, because cross account is the main strategy today for organizations using AWS. So the attack surface is just growing.”