.png "NO_WILDCARD: How I discovered the Organization ID of any AWS Account")
NO_WILDCARD: How I discovered the Organization ID of any AWS Account
When I published how to find the AWS Account ID of any S3 bucket earlier in the year, I felt like I had just scratched the surface of a general technique which might yield even more interesting results with a bit more research. However, building Tracebit keeps me quite busy so I had to put security research on the back burner for a little while!
While preparing notes for my fwd:cloudsec talk though, it seemed like there were too many big questions that I wanted to answer for myself and for the audience so I decided to dig deeper. In the process, I made a new finding which led to AWS introducing significant changes to VPC Endpoint behavior.
For the full details, see the previous post - I won’t go over it all again here. Essentially, you could determine the aws:ResourceAccount condition key (i.e. the account ID) by iteratively testing wildcards in S3 VPC Endpoint Policies, while abusing the fact that S3 VPC Endpoint policy denials don’t get logged to CloudTrail.
VPC Endpoints are a crucial component when implementing a Data Perimeter within AWS. My understanding is that VPC Endpoint Policy denials are not logged to CloudTrail to prevent CloudTrail from being used as a data exfiltration mechanism.
