Exploiting Public AWS Resources

Exploiting Public AWS Resources

Speakers: Eduard Agavriloae, Research and Development, Offensei

Conference: Cloud Village

YouTube: https://www.youtube.com/watch?v=uQ01K-WC6Yw

Overview

In the ever-expanding landscape of cloud computing, Amazon Web Services (AWS) stands as a dominant platform, offering a vast array of services. However, the flexibility and power of AWS also introduce significant security challenges, particularly concerning misconfigurations that lead to public exposure. Eduard Agavriloae's talk, "Exploiting Public AWS Resources," delivered at Cloud Village, delves into the critical implications of these misconfigurations, demonstrating how seemingly innocuous settings can create direct initial access points for attackers into an organization's cloud environment.

Agavriloae, an ethical hacker and cloud security researcher at Offensei, systematically dissects various AWS services, highlighting common pitfalls where resources are unintentionally made accessible to external entities or even the entire internet. The presentation provides a practical guide for identifying and exploiting these vulnerabilities, ranging from publicly listable S3 buckets and exposed EC2 AMIs/EBS snapshots to overly permissive IAM roles and misconfigured API Gateways. The core message underscores that public exposure is often the most critical initial access vector in cloud environments, with impacts varying widely based on the specific resource and its associated permissions.

This article summarizes the key technical insights from Agavriloae's comprehensive talk, offering an analytical deep dive into the types of misconfigurations, the methods for their discovery, and the techniques for their exploitation. It aims to equip security professionals and cloud engineers with a better understanding of these threats, enabling them to proactively identify and mitigate similar vulnerabilities within their own AWS infrastructures, thereby bolstering their overall cloud security posture.

Background

▶ Watch: Introduction, agenda, and defining public resources (0:00)

The problem of publicly exposed AWS resources stems primarily from the complex interplay of identity-based access policies (attached to IAM users, roles, or groups) and resource-based access policies (attached directly to resources like S3 buckets, SQS queues, or Lambda functions). While identity-based policies define what an identity can do, resource-based policies define who can access the resource itself, regardless of their identity-based permissions within the owner's account. This duality often leads to confusion and misconfigurations, particularly when resource policies grant broad access.

A key factor contributing to this problem is the use of the (asterisk) wildcard in policy documents, especially within the Principal element of a resource-based policy or the conditions of an IAM trust policy. When Principal: "" is used, it often means "any AWS account," including external ones, or even anonymous users for certain services. This is frequently misunderstood by developers and administrators who might assume it only applies to users within their own organization. Similarly, access control lists (ACLs) on services like S3 can be configured to allow "any AWS user," which extends far beyond the owner's account.

Prior work in cloud security has consistently highlighted the risks of misconfigurations, with numerous reports from security researchers and organizations documenting data breaches and unauthorized access attributed to publicly exposed cloud storage, databases, and compute resources. Tools like Shodan and specialized cloud scanners attempt to identify these exposures. Agavriloae introduces AWSI, described as a "Shodan for AWS," which helps identify public resources based on account IDs. Despite these tools and growing awareness, the prevalence of these vulnerabilities persists due to the sheer scale and complexity of cloud environments, rapid deployment cycles, and insufficient security training. The talk emphasizes that while some resources are discoverable via blackbox enumeration, many "hard-to-find" resources require some level of information disclosure or internal access to be identified, complicating defensive efforts.

Key Findings

▶ Watch: Understanding the dangerous 'any principle' (*) in policies (4:04)

Agavriloae's talk reveals several critical findings regarding the exploitation of public AWS resources:

1. Prevalence of Overly Permissive Policies: The most significant finding is the widespread use of overly permissive resource-based policies and ACLs, often incorporating the * wildcard for Principal or in conditions, which grants unintended public access. This is a recurring theme across multiple AWS services.
2. Diverse Attack Surface: Public exposure is not limited to common services like S3. A wide array of AWS resources—including AMIs, EBS Snapshots, IAM Roles, SSM Documents, API Gateways, Lambda Functions, and ECR repositories—can be misconfigured to allow external access, each presenting unique exploitation vectors and potential impacts.
3. Misunderstood Access Controls: Specific access control mechanisms, such as S3 ACLs allowing "any AWS account" or the distinction between S3 website mode and directory listing, are frequently misunderstood, leading to critical data exposures.
4. Initial Access Vector: Public exposure serves as a direct and often unauthenticated initial access point into an organization's cloud environment, making it a highly critical vulnerability type. The speaker explicitly states, "public exposure is I think is the most critical thing in cloud environments because they give you a direct initial access in your environment."
5. Hard-to-Find Resources: While some public resources are discoverable via blackbox enumeration (e.g., S3 buckets, AMIs), others like SNS, SQS, API Gateway, and Lambda functions are often "hard to find" without prior information disclosure or internal access, complicating discovery for external attackers but not negating their exploitability.
6. High-Impact Potential: The impact of these misconfigurations can range from sensitive data leakage (e.g., secrets in AMIs/EBS snapshots, source code in SSM documents, container images) to full environment compromise through assumption of high-privilege IAM roles or arbitrary code execution via Lambda functions.

These findings collectively paint a picture of a pervasive and high-risk security landscape in AWS, where seemingly minor misconfigurations can lead to significant security breaches.

Technical Deep Dive

▶ Watch: S3 public access via ACLs: 'Any AWS user' misconfiguration (4:48)

The technical deep dive presented by Eduard Agavriloae meticulously details various AWS services susceptible to public exposure and the specific methods for their identification and exploitation.

S3 Buckets

Amazon S3 (Simple Storage Service) buckets are a frequent target due to their common use for storing diverse data. Misconfigurations typically involve:

• Publicly Listable/Readable/Writable: A bucket can be configured to allow any user to list its contents, read files, or even upload/delete objects.
• Access Control Lists (ACLs): A common pitfall is setting an ACL to read for "any AWS user." This is often mistaken for "any user within my AWS account" but in fact grants read access to any authenticated AWS user globally. Agavriloae demonstrates this by showing a 403 Forbidden error for an anonymous request, but a successful download when the request originates from a different, authenticated AWS account.
• Website Hosting vs. Directory Listing: If an S3 bucket is configured for static website hosting, it typically serves an index.html file. However, if the website endpoint is removed from the URL, and the bucket is misconfigured to allow listing, an attacker can enumerate all files within the bucket.

Amazon Machine Images (AMIs)

AMIs are templates used to launch EC2 instances, essentially VM images. They can contain sensitive data such as secrets, application code, and configurations.

• Identification: AMIs need to be checked in every AWS region. The include-deprecated flag should be used to ensure all available AMIs, including older ones, are enumerated. Key identifiers for searching include image ID, owner ID (account ID), description, and name.
• Exploitation: Direct access to the underlying EBS snapshot of an AMI is usually not possible. The primary exploitation method involves:

1. Launching an EC2 instance: Start an EC2 instance in your own AWS account using the public AMI.
2. Connecting and Accessing: Connect to the newly launched instance to access its data.
3. Volume Detach/Reattach: For older or problematic AMIs, launch an EC2 instance, detach its root volume, and reattach it to another EC2 instance you control and can connect to. This allows mounting the volume and accessing its contents.

• Cloud Shovel: Agavriloae mentions his tool, cloud shovel, designed to extract sensitive files or files of interest from AMIs.

EBS Snapshots

Amazon EBS (Elastic Block Store) Snapshots are point-in-time backups of EBS volumes. They are closely related to AMIs, with AMIs often being abstractions over EBS volumes.

• Identification: Snapshots can be searched based on description (e.g., searching for "Bitcoin" can reveal interesting snapshots) or by account ID to find all public snapshots owned by a target.
• Exploitation:

1. Copy to Own Account: Copy the public EBS snapshot into your own AWS account.
2. Download/Attach: Once copied, the snapshot can be downloaded locally using AWS tools or attached to an EC2 instance you control to access its data.
3. Restore and Connect: A snapshot can be restored as a new EBS volume, then attached to an EC2 instance. If the original instance from which the snapshot was taken also had public access configured, an attacker could potentially restore the snapshot, change user passwords, and connect directly to the instance.

• Cold Snap: An official AWS Labs tool, cold snap, is specifically designed for downloading EBS snapshots locally.
• Identifying "Real" Snapshots: To differentiate between temporary "proof-of-concept" snapshots and potentially more valuable production snapshots, Agavriloae suggests checking the DB instance created time versus the snapshot's public exposure time. A significant delay might indicate a production snapshot made public later.

IAM Roles

IAM (Identity and Access Management) Roles define permissions for AWS entities. Misconfigurations often involve overly permissive trust policies.

• Assumable by Anyone: A critical misconfiguration occurs when an IAM role's trust policy allows Principal: { "AWS": "*" }. This permits any AWS account to assume the role, often leading to high-privilege permissions if the role itself is over-permissioned.
• Third-Party Technologies (OIDC): OpenID Connect (OIDC) providers like GitHub Actions or Terraform Cloud can be used to assume roles. Misconfigurations arise when the Condition in the trust policy uses wildcards (*) in repository or organization names.
• GitHub Actions: If a condition like github.com/hacktodef/* is used, any repository starting with hacktodef could assume the role.
• Terraform Cloud: Similarly, a wildcard in a Terraform Cloud organization pattern (e.g., app.terraform.io/org//run-id/) could allow any matching organization to assume a role, which are often configured with administrator-level access.
• Attack Specificity: Exploitation is specific to the provider, but the core vulnerability lies in the lack of stringent conditions or the use of wildcards in trust policies.

SSM Documents

SSM (Systems Manager) Documents are executable scripts or configuration definitions that can be run on EC2 instances.

• Public Exposure: SSM documents can be made public. While they might not directly contain secrets, they often hold source code or configuration details.
• Information Disclosure: Analyzing this source code can reveal internal technologies, application logic, and potential vulnerabilities within the company's infrastructure. An example shown is a bash script with comments, offering insights into operational practices.

Hard-to-Find Resources (SNS, SQS, API Gateway, CloudFront, Lambda, ECR)

These services are often not discoverable via blackbox enumeration and typically require some initial information disclosure or internal access to be identified.

• API Gateway:
• Private API Exposure: A "private" API Gateway, intended for internal AWS network access, can be misconfigured to be accessible from any AWS account if its resource policy uses Principal: "" or a VPC ID condition with .
• Exploitation: By routing internal traffic through the target private API Gateway from your own VPC, you can invoke connected Lambda functions, read from S3 buckets, or interact with other backend resources connected to the API Gateway.
• CloudFront Distributions:
• S3 ListBucket via Origin: If an Amazon CloudFront distribution's origin (e.g., an S3 bucket) is misconfigured with s3:ListBucket permission, and the distribution's cache policy or origin access control allows it, an attacker might be able to list the files behind the distribution URL. This is less common because direct access to the CloudFront URL usually quickly reveals such a misconfiguration.
• Lambda Functions:
• Public Invocation: Lambda functions can be configured to be invocable by anyone via the AWS CLI from an external AWS account or directly through a public function URL without authentication.
• Impact: This can lead to arbitrary code execution, sensitive data disclosure (e.g., printing credentials as shown in an example), or other actions depending on the function's code and permissions.
• Amazon ECR (Elastic Container Registry):
• Public Repositories: If a private ECR repository is mistakenly made public, anyone can pull the container images. These images might contain embedded secrets, API keys, or proprietary code.
• Private Repository Misconfiguration: Even private repositories can be misconfigured to allow external AWS accounts to pull or even upload new images. This is a severe vulnerability, as it could lead to compromise of entire clusters or environments by injecting malicious images. ECR registries can be identified and searched via ECR.AWS gallery.

Throughout the deep dive, Agavriloae stresses that the impact of these misconfigurations varies based on the specific permissions granted and the data/functionality exposed, but they consistently represent critical security risks.

Demo / Proof of Concept

▶ Watch: Exploiting public EBS Snapshots using the cold snap tool (8:00)

Eduard Agavriloae's talk was structured as a 30-minute high-level theory session followed by a 90-minute hands-on workshop, serving as the core demonstration and proof of concept. Participants were provided with access to a vulnerable environment and an attack playbook via a specified URL and credentials.

The playbook was designed to guide attendees through exploiting the various public AWS resources discussed in the theoretical part of the talk. Agavriloae described it as a "copy-paste attack framework" but encouraged participants to read the instructions for a better understanding. The workshop environment was kept live until 10 PM on the day of the conference, allowing attendees ample time to practice the attacks. The speaker was available to provide assistance, explain concepts, and troubleshoot any issues encountered during the exploitation attempts. This practical session allowed participants to experience firsthand how to identify and compromise misconfigured S3 buckets, AMIs, EBS snapshots, IAM roles, and other services, solidifying the theoretical knowledge presented earlier.

Defensive Implications

▶ Watch: Practical example: Searching EBS snapshots by description (8:20)

The implications of Agavriloae's findings for defenders are significant and highlight the critical need for proactive and comprehensive security measures in AWS environments.

1. Strict Policy Enforcement: The most crucial defensive measure is to avoid the use of the wildcard in resource-based policies (Principal: "") or in the conditions of IAM trust policies (e.g., for OIDC providers). Always specify the least privileged principals and conditions necessary.
2. Regular Audits of Resource-Based Policies and ACLs: Organizations must regularly audit all resource-based policies and ACLs across services like S3, SQS, SNS, API Gateway, and Lambda to ensure they do not grant unintended public or cross-account access. Pay particular attention to S3 bucket ACLs that grant access to "any AWS user."
3. Comprehensive Public Resource Discovery: Implement robust tools and processes for discovering all publicly exposed resources. While blackbox enumeration tools are useful, they don't provide the full picture. For a complete security assessment, read-only access to the AWS environment is essential to identify "hard-to-find" public resources (like private API Gateways with misconfigured policies). Tools like AWSI can aid in this discovery.
4. Review AMI and EBS Snapshot Sharing: Regularly review sharing settings for AMIs and EBS snapshots. Ensure they are only shared with trusted accounts or kept private. When sharing is necessary, use specific account IDs rather than broad public settings. For snapshots, be wary of those with a large DB instance created time vs. public exposure time, as these are more likely to contain sensitive production data.
5. Secure Third-Party Integrations: When configuring IAM roles for third-party OIDC providers (e.g., GitHub Actions, Terraform Cloud), ensure that the conditions in the trust policy are highly specific and do not use wildcards (*) that could allow unauthorized entities to assume roles.
6. SSM Document and ECR Security: Restrict the public sharing of SSM documents to prevent source code or configuration disclosure. For ECR, ensure container image repositories are private unless explicitly intended to be public, and even then, regularly scan public images for embedded secrets. For private repositories, ensure their resource policies are not misconfigured to allow external pull/push access.
7. Least Privilege Principle: Adhere strictly to the principle of least privilege for all AWS identities and resources. Grant only the permissions absolutely necessary for a task.
8. Security Training: Educate developers and cloud engineers on common AWS misconfigurations, the nuances of identity-based vs. resource-based policies, and the dangers of public exposure.
9. Continuous Monitoring: Implement continuous monitoring for changes to resource policies, ACLs, and sharing settings that could introduce public exposure.

Agavriloae emphasizes that "public exposure is the most critical thing in cloud environments" because it provides a direct initial access vector. By implementing these defensive strategies, organizations can significantly reduce their attack surface and mitigate the risk of unauthorized access and data breaches.

Key Takeaways

• Public Exposure is Critical Initial Access: Misconfigured public AWS resources are often the most direct and critical initial access points for attackers, bypassing traditional perimeter defenses.
• Wildcards are Dangerous: The use of * (asterisk) in Principal elements of resource-based policies or in conditions for IAM trust policies is a primary cause of unintended public or cross-account access across various AWS services.
• Diverse Attack Surface: Beyond S3 buckets, numerous AWS services like AMIs, EBS Snapshots, IAM Roles (especially with OIDC), SSM Documents, API Gateways, Lambda Functions, and ECR can be exploited due to public exposure.
• Misunderstood Access Controls: Common access control mechanisms, such as S3 ACLs allowing "any AWS account" or the distinction between S3 website and directory listing, are frequently misapplied, leading to critical data leakage.
• Comprehensive Auditing is Essential: Both blackbox and authenticated (read-only) assessments are required to identify the full scope of public resources, including those "hard to find" without prior information disclosure.
• Proactive Mitigation: Implement strict least-privilege policies, regularly audit resource configurations, secure third-party integrations, and educate teams on cloud security best practices to prevent and remediate public exposures.

About the Speaker(s)

Eduard Agavriloae is a dedicated professional in the field of cloud security, currently serving in Research and Development at Offensei. With a strong background as an ethical hacker and cloud security researcher, Eduard focuses on identifying and analyzing vulnerabilities within cloud environments. He is also an experienced speaker, sharing his insights and practical knowledge at security conferences like Cloud Village. Eduard previously maintained a blog at hacktodee.com, which he referenced in his talk, and now contributes articles to the offensi.com/blog. His work centers on helping organizations understand and defend against sophisticated cloud attacks, particularly those stemming from misconfigurations leading to public exposure.