Pwning AWS: Exploiting Cloud Misconfigurations

Pwning AWS: Exploiting Cloud Misconfigurations

Speakers: Bhagwan Bolina, Cloud Security Researcher; Deepak, Security Engineer

Conference: Cloud Village

YouTube: https://www.youtube.com/watch?v=pb81m1h4OEE

Overview

This talk, "Pwning AWS: Exploiting Cloud Misconfigurations," delivered by Bhagwan Bolina and Deepak at Cloud Village, provides an insightful introduction to the world of AWS penetration testing. Geared towards individuals with some AWS experience but limited pentesting exposure, the presentation systematically walks through common misconfigurations within Amazon Web Services (AWS) environments and demonstrates practical methods for their exploitation. The speakers, both passionate about security, showcase how seemingly minor oversights in cloud resource provisioning and identity management can lead to significant security breaches, including full administrative access.

The core of the talk revolves around two primary exploitation paths: a privilege escalation scenario leveraging misconfigured IAM policies and a multi-stage lateral movement attack chain involving Lambda functions, EC2 server-side request forgery (SSRF), and S3 bucket enumeration. By using the deliberately vulnerable CloudGoat lab environment, Bolina and Deepak provide a hands-on perspective, detailing the enumeration and exploitation steps. This article delves into the technical intricacies of these attacks, offering defenders crucial insights into mitigating similar vulnerabilities in their own AWS deployments.

The importance of this talk lies in its clear articulation of fundamental cloud security principles, specifically the principle of least privilege and the need for rigorous configuration management. As organizations increasingly migrate to the cloud, understanding these attack vectors becomes paramount for both security professionals and developers. The session serves as a foundational guide for anyone looking to understand the offensive security landscape within AWS, emphasizing that even well-intentioned configurations can harbor critical vulnerabilities if not meticulously reviewed.

Background

▶ Watch: Introduction to AWS pentesting and Cloud Nuke tool (0:00)

The rapid adoption of cloud computing, particularly AWS, has revolutionized how organizations deploy and manage their infrastructure. While AWS offers a robust and secure platform, the shared responsibility model places a significant burden on customers to secure their configurations, applications, and data within the cloud. A common pitfall in this model is the prevalence of misconfigurations, which often stem from a lack of understanding of AWS services, rushed deployments, or insufficient security oversight. These misconfigurations create fertile ground for attackers to gain initial access, escalate privileges, and move laterally across an organization's cloud environment.

At the heart of AWS security is Identity and Access Management (IAM), a service that enables you to securely control access to AWS resources. IAM consists of users, groups, roles, and policies. Users represent individuals or applications, groups organize users, and roles are identities that you can assume to gain temporary permissions. Policies, expressed as JSON documents, define what actions an entity (user, group, or role) can perform on which resources. A common and dangerous misconfiguration occurs when policies grant overly permissive access, often using wildcards like Action: "" and Resource: "" , effectively granting administrative privileges.

Prior work in cloud security has extensively documented these issues. Tools like Prowler, ScoutSuite, and CloudMapper are widely used for auditing AWS environments for misconfigurations. Offensive security frameworks like Pacu and CloudGoat (used in this talk) specifically demonstrate how these misconfigurations can be exploited. The problem persists because, despite awareness, the complexity of AWS services and the dynamic nature of cloud deployments make it challenging to maintain a perfectly secure posture. Developers, in an effort to get things working quickly, might grant broad permissions, leading to a "security debt" that attackers can later leverage. The talk highlights how even seemingly innocuous settings, such as multiple policy versions, can be weaponized if not properly managed, underscoring the continuous need for education and robust security practices in cloud environments.

Key Findings

▶ Watch: Demonstrating IAM admin user creation (common misconfiguration) (4:00)

The talk presents several key findings demonstrating common AWS misconfigurations and their exploitation paths. These findings highlight how attackers can chain vulnerabilities to achieve significant compromise within an AWS account.

1. Privilege Escalation via IAM Policy Rollback: The first major finding illustrates how a low-privileged IAM user can escalate their privileges to full administrator access by manipulating IAM policies. This occurs when an IAM policy has multiple versions, and one of the older versions contains overly permissive Action: "" and Resource: "" statements. An attacker, if granted the iam:SetDefaultPolicyVersion permission, can revert the policy to an older, more permissive version, thereby gaining elevated privileges. This vulnerability underscores the importance of reviewing all policy versions, not just the currently active one.

1. Lateral Movement through Lambda Environment Variables: The second key finding demonstrates how sensitive credentials can be exposed within AWS Lambda function environment variables. When Lambda functions need to interact with other AWS services, developers sometimes hardcode or store access keys directly in the function's environment configuration. An attacker with even limited access to list Lambda functions can enumerate these variables, extract new credentials, and use them to pivot to other services or accounts.

1. Exploiting EC2 Instance Metadata Service (IMDS) via SSRF: A critical finding for lateral movement within a network is the exploitation of the EC2 Instance Metadata Service (IMDS) through a Server-Side Request Forgery (SSRF) vulnerability. If a web application hosted on an EC2 instance is vulnerable to SSRF, an attacker can trick the application into making requests to the internal IMDS endpoint (169.254.169.254). This allows the attacker to retrieve temporary security credentials associated with the EC2 instance's IAM role, which can then be used to access other AWS resources. The talk also briefly touches upon the evolution from IMDSv1 to IMDSv2, noting that v2 adds a session token requirement, making direct exploitation via simple GET requests harder but still possible with HTTP PUT requests.

1. Chaining Vulnerabilities for Full Compromise: The overarching finding is the effectiveness of chaining these individual misconfigurations. The presentation shows how an initial compromise (e.g., leaked GitHub credentials) can lead to enumerating Lambda functions, finding new credentials, then using those to discover EC2 instances, exploiting SSRF to get instance role credentials, and finally using those credentials to access S3 buckets or invoke critical Lambda functions, ultimately leading to a "you win" scenario or full administrative control. This multi-stage attack path is a realistic representation of how sophisticated attackers navigate compromised cloud environments.

Technical Deep Dive

▶ Watch: Configuring AWS CLI credentials and attacker machine setup (6:00)

The talk provides a detailed walkthrough of exploiting specific AWS misconfigurations, primarily utilizing the AWS Command Line Interface (CLI) and the CloudGoat vulnerable lab environment. The technical deep dive focuses on two main scenarios: IAM privilege escalation and a multi-stage lateral movement attack.

IAM Policy Rollback for Privilege Escalation

The first scenario begins with the assumption that an attacker has obtained AWS credentials for a low-privileged IAM user, perhaps from a leaked GitHub repository. The goal is to escalate privileges.

1. Initial Enumeration: The attacker configures the AWS CLI with the compromised credentials. The first step is to verify the identity using aws sts get-caller-identity, which returns the Amazon Resource Name (ARN) of the current user. This provides a baseline understanding of the user's identity.

1. Policy Discovery: The attacker then enumerates the IAM policies attached to this user. This involves two primary commands:

• aws iam list-user-policies --user-name <username>: Lists inline policies embedded directly within the user.
• aws iam list-attached-user-policies --user-name <username>: Lists managed policies that are attached to the user.

In the demonstration, the user had an attached managed policy. The next step is to examine the versions of this policy.

1. Policy Version Enumeration: IAM policies can have multiple versions, and AWS keeps a history of these. An attacker can list these versions using:

The output reveals various policy versions (e.g., v1, v2, v3, v4, v5). The critical insight here is that while a policy's current default version might be restrictive, an older version could be highly permissive.

1. Policy Document Inspection: To identify a vulnerable policy version, each version's JSON document must be inspected:

The demonstration revealed that v3 of the policy contained a highly dangerous statement:

This policy statement grants full administrative access (Action: "") to all resources (Resource: "") within the AWS account.

1. Privilege Escalation: If the compromised user has the iam:SetDefaultPolicyVersion permission, they can set this vulnerable v3 as the default policy version:

Upon successful execution, the user's effective permissions immediately update to reflect the new default policy, granting them administrative control.

1. Verification: To confirm administrative access, the attacker attempts a high-privilege action, such as creating a new IAM user:

Successful creation of user "Bob" confirms the privilege escalation. This scenario highlights how easily overly permissive policies, even if not the active default, can be exploited if rollback permissions are granted.

Lateral Movement via Lambda, EC2 SSRF, and S3

The second scenario demonstrates a multi-stage attack chain, starting with initial access and moving laterally through different AWS services to achieve a broader compromise.

1. Initial Access and Lambda Enumeration: Similar to the first lab, the attacker starts with compromised AWS credentials. Instead of focusing on IAM policies, this scenario targets AWS Lambda functions. The attacker lists available Lambda functions:

Upon inspecting a specific Lambda function's configuration, the attacker discovers sensitive information within its environment variables. These variables often store credentials or API keys that the Lambda function uses to interact with other AWS services.

The environment variables might contain new AWS access keys and secret keys.

1. EC2 Instance Discovery: With the newly acquired credentials, the attacker configures the AWS CLI again and then enumerates EC2 instances to find potential targets.

This command provides details about running EC2 instances, including their public IP addresses and associated IAM instance profiles. An instance profile is a container for an IAM role that can be attached to an EC2 instance, allowing applications running on the instance to assume the role's permissions.

1. SSRF Exploitation on EC2: The attacker identifies an EC2 instance hosting a web application that is vulnerable to Server-Side Request Forgery (SSRF). The application accepts a URL parameter, making a request to the provided URL from the server's perspective.

The critical step is to point the SSRF vulnerability to the EC2 Instance Metadata Service (IMDS) endpoint, which is locally accessible only from the EC2 instance itself at 169.254.169.254.

• IMDSv1: In older configurations or intentionally vulnerable labs (like CloudGoat), a direct GET request to http://169.254.169.254/latest/meta-data/iam/security-credentials/ can list available roles. Subsequently, http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name> retrieves temporary credentials (AccessKeyId, SecretAccessKey, SessionToken) for that role.
• IMDSv2: Introduced for enhanced security, IMDSv2 requires an initial HTTP PUT request to obtain a session token, which must then be included in subsequent GET requests. While more secure, it's not foolproof against SSRF if the attacker can control both PUT and GET requests. The demo implicitly leverages a scenario behaving like IMDSv1 for simplicity or a specific IMDSv2 bypass.

The retrieved credentials are temporary security credentials associated with the EC2 instance's IAM role, granting permissions defined by that role.

1. Further Lateral Movement (S3 and Final Lambda Invocation): Using the temporary credentials from the EC2 instance profile, the attacker continues enumeration. In the demo, this leads to discovering and enumerating S3 buckets. S3 buckets can also be misconfigured to expose credentials or contain sensitive data. The attacker finds another set of credentials in an S3 bucket.

Finally, using this new set of credentials, the attacker identifies and invokes a specific Lambda function that signifies the "win" condition of the lab, demonstrating full control over a critical application component. This iterative process of finding credentials, enumerating services, and exploiting misconfigurations is a hallmark of real-world cloud attacks.

Demo / Proof of Concept

▶ Watch: Deploying the vulnerable AWS lab using Terraform (8:00)

The core of the presentation was a live demonstration, or rather a detailed walkthrough, of exploiting these misconfigurations within a controlled lab environment. The speakers utilized CloudGoat, an intentionally vulnerable AWS environment developed by Rhino Security Labs, specifically designed to teach cloud penetration testing.

The setup for the lab involved:

1. AWS Account Setup: Participants were encouraged to create an IAM admin user (a deliberate bad practice in a real environment, but necessary for provisioning the lab) and configure the AWS CLI with its access keys.
2. Attacker Machine: A "jumper machine" was set up, which acts as the attacker's workstation. This machine required Terraform to be installed. Terraform is an infrastructure-as-code tool used to define and provision cloud resources.
3. CloudGoat Deployment: The speakers provided a GitHub repository containing Terraform scripts for CloudGoat. Participants would clone this repository, initialize Terraform (terraform init), and then apply the configuration (terraform apply) to deploy the vulnerable AWS infrastructure into their own accounts. This creates the EC2 instances, Lambda functions, IAM users, and policies necessary for the exploitation scenarios.

The demonstration then proceeded through two main scenarios:

Scenario 1: IAM Policy Rollback

• The speakers assumed initial access to a low-privileged IAM user whose credentials were "found" on GitHub.
• They used AWS CLI commands (sts get-caller-identity, iam list-attached-user-policies, iam list-policy-versions, iam get-policy-version) to enumerate the user's policies and identify an older policy version (v3) with administrative privileges (Action: "", Resource: "").
• The crucial step was using aws iam set-default-policy-version to make this highly permissive v3 the active policy.
• The success was demonstrated by executing aws iam create-user --user-name Bob, confirming full administrative control by creating a new IAM user.

Scenario 2: Lateral Movement via SSRF

• This scenario began with a different set of compromised credentials.
• The first step involved enumerating Lambda functions (aws lambda list-functions) and inspecting their configurations (aws lambda get-function-configuration) to extract new credentials from environment variables.
• With these new credentials, the team enumerated EC2 instances (aws ec2 describe-instances) to identify a publicly accessible web server.
• They then demonstrated an SSRF vulnerability on this web server by manipulating a URL parameter to make the server request an internal resource.
• The target of the SSRF was the EC2 Instance Metadata Service (IMDS) at 169.254.169.254/latest/meta-data/iam/security-credentials/. This allowed them to retrieve temporary credentials associated with the EC2 instance's IAM role.
• Using these temporary credentials, they continued their lateral movement, enumerating S3 buckets to find yet another set of credentials.
• The final step involved invoking a specific Lambda function with the newly acquired credentials, which triggered a "you win" message, signifying a complete compromise path within the CloudGoat environment.

The entire demonstration, while guided, showcased the practical application of AWS CLI commands in an attack sequence, emphasizing the iterative nature of cloud pentesting. The speakers also highlighted Cloud Nuke, a tool designed to delete all resources in an AWS account, as a crucial utility for cleaning up the lab environment and preventing unexpected costs.

Defensive Implications

▶ Watch: Core Concepts: Introduction to AWS Identity and Access Management (IAM) (10:00)

The vulnerabilities demonstrated in this talk highlight several critical areas where defenders can strengthen their AWS security posture. Proactive measures and continuous monitoring are essential to prevent and detect these types of attacks.

1. Strict Adherence to the Principle of Least Privilege: This is the most fundamental defense. IAM policies should grant only the minimum necessary permissions for users, roles, and applications to perform their intended functions. Avoid using Action: "" and Resource: "" in IAM policies, as this effectively grants administrative access. Regularly review and refine IAM policies to ensure they are not overly permissive. Tools like AWS IAM Access Analyzer can help identify unintended access.

1. IAM Policy Version Management: The privilege escalation via policy rollback demonstrates the danger of retaining overly permissive older policy versions. Defenders should:

• Delete Obsolete Policy Versions: Regularly review and delete any IAM policy versions that are no longer needed or contain excessive permissions. AWS allows up to five non-default versions, but it's best to keep only what's necessary.
• Monitor iam:SetDefaultPolicyVersion: Restrict the iam:SetDefaultPolicyVersion permission to only highly trusted administrators. Monitor CloudTrail logs for calls to this API action, especially if a policy is changed to an older, less secure version.

1. Secure Credential Management and Hardcoding Prevention: Storing credentials in Lambda environment variables, S3 buckets, or source code is a major security risk. Defenders should:

• Use AWS Secrets Manager or AWS Systems Manager Parameter Store: These services are designed for securely storing and retrieving sensitive information like API keys, database credentials, and other secrets. Applications should retrieve credentials from these services at runtime, rather than having them hardcoded.
• Leverage IAM Roles for EC2 and Lambda: Instead of providing explicit access keys, assign appropriate IAM roles to EC2 instances and Lambda functions. These roles grant temporary, automatically rotated credentials, eliminating the need to manage long-lived keys.
• Code Review and Static Application Security Testing (SAST): Implement robust code review processes and integrate SAST tools into CI/CD pipelines to detect hardcoded credentials in application code, including JavaScript files and decompiled APKs.
• Monitor Public Repositories: Use tools and services to continuously scan public GitHub repositories for leaked AWS credentials.

1. Mitigating Server-Side Request Forgery (SSRF) and Securing EC2 Metadata Service:

• Input Validation: Implement strict input validation for any user-supplied URLs or parameters that an application might use to make server-side requests. Whitelist allowed domains or IP ranges, and block requests to internal IP addresses (e.g., 169.254.169.254).
• Web Application Firewalls (WAFs): Deploy AWS WAF or other WAF solutions to detect and block SSRF attempts.
• Enable and Enforce IMDSv2: Configure EC2 instances to use Instance Metadata Service Version 2 (IMDSv2). IMDSv2 requires a session token obtained via an HTTP PUT request before metadata can be retrieved, making it significantly harder for attackers to exploit SSRF vulnerabilities for credential harvesting. Ensure instances are configured to require IMDSv2.
• Restrict Instance Profile Permissions: IAM roles attached to EC2 instances should follow the principle of least privilege. If an EC2 instance is compromised, the impact is limited by its restricted IAM role.

1. Comprehensive Logging and Monitoring:

• AWS CloudTrail: Enable CloudTrail for all regions and centralize logs in an S3 bucket for long-term storage and analysis. CloudTrail records all API calls made to your AWS account, providing an audit trail for suspicious activities like SetDefaultPolicyVersion, CreateUser, PutFunctionConfiguration (for Lambda env vars), or attempts to access IMDS.
• AWS Config: Use AWS Config to continuously monitor and record AWS resource configurations and changes. This helps detect deviations from desired security baselines.
• Security Information and Event Management (SIEM): Integrate AWS logs with a SIEM solution to correlate events, detect anomalies, and generate alerts for potential security incidents in real-time.
• GuardDuty: Enable AWS GuardDuty for intelligent threat detection that monitors for malicious activity and unauthorized behavior.

1. Regular Security Audits and Penetration Testing: Conduct regular security audits, vulnerability assessments, and penetration tests against your AWS environment. This includes both automated scanning with tools like Prowler or ScoutSuite, and manual testing by experienced security professionals who can identify complex attack chains like those demonstrated.

By implementing these defensive measures, organizations can significantly reduce their attack surface and improve their resilience against cloud misconfiguration exploits.

Key Takeaways

• Principle of Least Privilege is Paramount: Always grant the minimum necessary permissions to IAM users, roles, and resources. Overly permissive policies (Action: "", Resource: "") are a primary vector for privilege escalation.
• Manage IAM Policy Versions Diligently: Older, highly permissive IAM policy versions can be exploited if users have iam:SetDefaultPolicyVersion permission. Regularly review and delete obsolete policy versions.
• Avoid Hardcoding Credentials: Never store AWS access keys or secrets directly in application code, Lambda environment variables, S3 buckets, or other accessible configurations. Utilize AWS Secrets Manager or IAM roles for secure credential management.
• Mitigate SSRF and Secure IMDS: Server-Side Request Forgery (SSRF) vulnerabilities can expose temporary credentials from the EC2 Instance Metadata Service (IMDS). Implement strict input validation, use WAFs, and enforce IMDSv2 to prevent this.
• Comprehensive Logging and Monitoring are Critical: AWS CloudTrail, Config, and GuardDuty, integrated with a SIEM, are essential for detecting and investigating suspicious activities related to IAM, Lambda, EC2, and S3.
• CloudGoat is an Excellent Learning Resource: For those looking to understand AWS attack vectors, CloudGoat provides a hands-on, deliberately vulnerable lab environment to practice exploitation techniques.

About the Speaker(s)

Bhagwan Bolina is introduced as a passionate cloud security researcher who enjoys both building and breaking things. His expertise lies in understanding the intricacies of cloud environments from both a defensive and offensive perspective, making him well-suited to demonstrate cloud misconfigurations and their exploitation.

Deepak is a security engineer with a strong background in web security. He also expresses a growing interest in AI and cybersecurity. His experience in web application security provides a valuable perspective on vulnerabilities like SSRF, which are often the initial entry points into cloud environments.