Full Report
Last November, Wiz Research mapped all the services in AWS that allow access from other accounts to see if any of them might inadvertently expose customers and discovered 3 vulnerabilities in different AWS services that allowed anyone to read or write into the accounts of other AWS customers.
Analysis Summary
# Vulnerability: Cross-Account Data Exposure via Default AWS Service Resource Policies
## CVE Details
* **CVE ID:** Not explicitly provided in the summary, but the research uncovered multiple vulnerabilities (three specific findings mentioned).
* **CVSS Score:** Not specified.
* **CWE:** Likely related to CWE-284 (Improper Access Control) or CWE-73 (External Control of File Name or Path) depending on the specific service exploitation vector.
## Affected Systems
* **Products:** Amazon Web Services (AWS) services, specifically:
* AWS CloudTrail
* AWS Config
* AWS Serverless Repository
* **Versions:** Affects any configuration using the default resource policies distributed by the above services before vendor remediation. The primary issue is the customer's existing, un-updated resource policies.
* **Configurations:** Any environment utilizing these AWS services where customers granted access via default, overly permissive resource policies that trust the related services without sufficient conditions on *who* can utilize that trust relationship (i.e., configurations where policies trust the service principal without checking the calling account).
## Vulnerability Description
Wiz research identified a class of cross-account vulnerability where default or inherited resource policies in certain AWS services allowed unauthorized principals (any external actor) to write logs into a target customer's S3 buckets (CloudTrail/Config) or read sensitive data from S3 buckets (Serverless Repository).
The root cause is that by default, resource policies associated with services like Serverless Repository trusted the AWS service principal to access customer resources (like S3 objects) without defining or limiting *which* principal initiated the action, effectively allowing an attacker to manipulate the trusted service to act on their behalf against other customer environments.
## Exploitation
* **Status:** PoC available (research demonstrated the exploitability). The article strongly implies the risk is active as 90%+ of users were still vulnerable post-patch release.
* **Complexity:** Described as "complex for malicious actors to exploit in the real world," suggesting **Medium** technical complexity to achieve the initial setup, but the resulting impact is high.
* **Attack Vector:** Network (Cloud-based manipulation).
## Impact
* **Confidentiality:** High (Attacker could read sensitive data, including source code and passwords, from private S3 buckets via Serverless Repository exploitation).
* **Integrity:** Medium (Attacker could write service logs into other customer accounts via CloudTrail/Config exploitation).
* **Availability:** Low (Primary impact is data exposure, not service disruption).
## Remediation
### Patches
* AWS vendors implemented fixes by adding conditions to the underlying resource policies to better restrict access specifically for the services mentioned. *Note: Vendor patches alone are insufficient; customer action is required.*
### Workarounds
* **Mandatory Customer Action:** Customers **must** manually update their existing resource policies to reflect the vendor's hardened defaults.
* AWS Access Analyzer is stated as a tool that will be updated to provide out-of-the-box notifications for misconfigured service access.
## Detection
* **Indicators of Compromise (IoCs):** Unauthorized log entries appearing in customer buckets from unexpected CloudTrail executions, or unexpected object access/download activity on S3 buckets governed by misconfigured policies.
* **Detection Methods and Tools:** Cloud security platforms (like Wiz) were used to build controls to detect these specific misconfigurations post-disclosure. AWS Access Analyzer is planned to assist with detection.
## References
* [Vendor Advisories on S3/CloudTrail/Config policy changes] (Specific links not documented in source text)
* [Wiz Research Blog Post on Cross-Account Vulnerabilities] (Defanged: `https://www[dot]wiz[dot]io/blog/cross-account-vulnerabilities-in-aws`)
* [Slack Group for Cloud CVE Discussion] (Defanged: `https://join[dot]slack[dot]com/t/cloud-cve-db/shared_invite/zt-y38smqmo-V~d4hEr_stQErVCNx1OkMA`)