Breaking the Isolation: Cross-Account AWS Vulnerabilities

The presentation discusses the need for a cloud CVE database to address cloud vulnerabilities and the challenges in managing service access as a new type of cloud exposure risk.

• Service access is a new type of cloud exposure risk that needs to be handled like cloud exposure.
• Cloud vulnerabilities are a bigger problem and the process is broken, even notifications are not enough.
• The CVE system can be used as a model to create a cloud CVE database to identify and create a central database for all vulnerabilities in the cloud.
• The cloud CVE database should have a shared naming system, a clear severity mechanism, and tracking systems/tools.
• The cloud security industry needs to become more mature and build a cross-cloud vulnerability database.
• Further research is needed to uncover more problematic cross-account functionality in cloud providers.

The speaker shared that they used to trust the GLS and web services and gave them access without much thought. However, they realized that service access can be manipulated by attackers to access resources, making it a new type of cloud exposure risk. They also found that vulnerabilities persisted because users kept using vulnerable code, and new services get new permissions every few weeks, making it impossible to track all notifications. The speaker believes that a cloud CVE database is needed to address cloud vulnerabilities and that the industry needs to become more mature to build a cross-cloud vulnerability database.

Multiple AWS services were found to be vulnerable to a new cross-account vulnerability class. An attacker could manipulate various services in AWS and cause them to perform actions on other clients' resources due to unsafe identity policies used by AWS services to access clients' resources. The vulnerabilities have been proven on three major AWS services (AWS Config, Cloudtrail, and Serverless Repository) and have allowed a potential attacker to write and read certain objects from private S3 buckets.In this presentation, we will review the discovered vulnerabilities and explain their root cause. We will show how an attacker can perform actions on any account in AWS using these services via the discovered cross-account vulnerability. We believe this is a new class of vulnerabilities that may affect many other services in AWS because the tenant scope is implicitly defined in AWS IAM policies, causing services that allow multi-tenant access to perform unintended actions.While reporting and working with the AWS security team on resolving these issues, we concluded that the process of updating IAM-related vulnerabilities is sub-optimal. Although AWS acted very quickly to fix the issues, the cloud provider relies on customers to perform the IAM policy updates, which often does not happen. IAM vulnerabilities are not tracked by NIST, do not have a CVE, and do not have scanning tools that provide IAM vulnerability scanning results. The result is that most customers are running with vulnerable IAM policies and have no process to fix them. Furthermore, we discovered that AWS issues hundreds of security updates to its IAM policies, but security teams lack tools to scan for them and prioritize fixing them. It is vital to raise the community awareness of the issue of IAM CVEs because identity-related vulnerabilities are a key attack surface in cloud environments.We will review the specific mitigations provided to the IAM vulnerabilities we found and discuss the current gaps in the way the vulnerability management process for IAM is handled today.