Breaking the Cloud: Finding and Exploiting Misconfigurations in AWS

Breaking the Cloud: Finding and Exploiting Misconfigurations in AWS

Speakers: Victoria Shutenko (Security engineer/ Penetration Tester, Techmagic)

Conference: DefCamp

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

Overview

In this insightful DefCamp presentation, Victoria Shutenko, a seasoned security engineer and penetration tester at Techmagic, delves into the pervasive and critical issue of misconfigurations in Amazon Web Services (AWS) environments. Titled "Breaking the Cloud: Finding and Exploiting Misconfigurations in AWS," her talk serves as a comprehensive guide for both defenders and aspiring penetration testers seeking to understand, identify, and mitigate common security pitfalls in cloud infrastructure. As an AWS Community Builder, Shutenko brings a practical, hands-on perspective to the challenges of securing complex cloud deployments, emphasizing that while AWS provides a robust security framework, its effective implementation ultimately rests with the user.

The core message of the talk revolves around the idea that despite the advanced security features offered by AWS, human error, the inherent complexity of cloud services, and a lack of security awareness frequently lead to vulnerabilities. Shutenko highlights how seemingly minor misconfigurations, such as overly permissive IAM roles, publicly exposed S3 buckets, or unsecured EC2 instances, can be leveraged by threat actors to achieve significant data breaches, privilege escalation, and even full cloud environment takeovers. The presentation not only dissects the root causes and real-world impacts of these misconfigurations but also provides a structured methodology for AWS penetration testing, complete with open-source tools and actionable defensive strategies.

This talk is particularly relevant in today's cloud-centric landscape, where organizations are rapidly migrating their critical assets to AWS. The rapid pace of development, coupled with the sheer volume of AWS services (over 200), often means that security can be an afterthought or incorrectly implemented. Shutenko's expertise as a penetration tester offers invaluable insights into the attacker's mindset, demonstrating how vulnerabilities are discovered and exploited. By sharing practical tools, methodologies, and real-world examples, she empowers security professionals and developers to proactively identify and address misconfigurations, thereby bolstering the overall security posture of their AWS environments and preventing costly breaches.

Background

▶ Watch: Introduction and AWS security agenda (0:00)

The proliferation of cloud computing has revolutionized how businesses operate, offering unparalleled scalability, flexibility, and cost efficiency. However, this rapid adoption has also introduced a new frontier of security challenges, with misconfigurations emerging as one of the most significant and frequently exploited vulnerabilities in cloud environments, particularly in AWS. Victoria Shutenko underscores that the problem isn't necessarily with AWS's inherent security, but rather with the intricate interplay of human factors and the vast complexity of the platform.

Shutenko identifies several key reasons why misconfigurations are so prevalent:

• Human Error: This is the primary culprit, often stemming from manual configuration mistakes, a lack of understanding of security best practices, or the temporary granting of excessive permissions to complete a task quickly, which are then forgotten. Developers or DevOps engineers, focused on functionality and rapid deployment, may inadvertently overlook security implications.
• Complexity of Cloud Services: AWS offers over 200 services, each with its own set of configurations, permissions, and interdependencies. Managing and securing these services, especially in large, complex infrastructures, is a daunting task. The rapid evolution of AWS services means that configurations can change quickly, opening new avenues for potential misconfigurations.
• Lack of Security Awareness: Many teams prioritize speed and functionality over security, and organizations may lack clear security policies or dedicated "security champions" within development teams. This often leads to security being addressed only after a breach has occurred, rather than proactively.

The talk provides several common types of AWS misconfigurations:

• Overly Permissive IAM Roles and Policies: This is a fundamental issue, where users or services are granted more permissions than necessary, often through the use of wildcards or broad access (e.g., full S3 access when only GetObject is needed).
• Misconfigured S3 Buckets: Publicly accessible S3 buckets are a classic example, often exposing sensitive data due to forgotten settings or incorrect access policies. Shutenko recalls a scenario where S3 buckets were hidden behind a VPN, but when the VPN changed, the public access was inadvertently restored.
• Publicly Facing Resources: Unsecured EC2 instances, RDS databases, or Lambda functions with open ports or known IPs can become targets for DoS attacks or exploitation. An example cited involved an EC2 instance with a known IP running a site under a DoS attack, where applying Cloudflare was ineffective because the IP was already public.
• Security Group Mistakes: Wide-open rules for SSH or RDP access expose instances to brute-force attacks or unauthorized access.
• Insecure Serverless Architecture: Mismanaged API Gateways or overly permissive Lambda permissions can create exploitable pathways within serverless applications.

Shutenko reinforces the real-world impact with recent examples from 2024, including:

• An attacker exploiting a website misconfiguration to extract two terabytes of sensitive data, including AWS credentials, affecting thousands of organizations.
• Web servers exposing environment variables containing AWS credentials, leading to overwrite access even with non-administrator privileges due to misconfigured IAM roles.
• Publicly accessible S3 buckets exposing sensitive customer data.
• Application Load Balancer misconfigurations leading to unauthorized access to thousands of web applications due to improper authentication implementation.

These examples underscore that AWS misconfigurations are not theoretical risks but active, exploited vulnerabilities leading to significant business, compliance, and reputational damage. The problem persists because the human element is often the weakest link, struggling to keep pace with the complexity and dynamism of cloud environments.

Key Findings

▶ Watch: Preventing misconfigurations: Best practices and tools (9:55)

The talk "Breaking the Cloud: Finding and Exploiting Misconfigurations in AWS" by Victoria Shutenko presents several key findings that are critical for understanding and addressing cloud security:

1. Misconfigurations are the Primary Attack Vector: Shutenko firmly establishes that misconfigurations, rather than inherent flaws in AWS services, are the leading cause of security breaches in the cloud. She attributes this to human error, the overwhelming complexity of AWS's 200+ services, and a general lack of security awareness among development and operations teams. This highlights a crucial shift in focus for cloud security from infrastructure vulnerabilities to configuration management.

1. Over-Permissive IAM is a Consistent Threat: A recurring theme and a significant finding is the prevalence and impact of overly permissive IAM roles and policies. Shutenko demonstrates how granting excessive permissions, often through wildcards or broad access, provides attackers with the necessary leverage for privilege escalation and lateral movement, even when initial compromised credentials are not administrative. This underscores the critical importance of the principle of least privilege.

1. Real-World Breaches are Driven by Common Errors: Shutenko provides recent (2024) examples of major breaches, including a two-terabyte data compromise and widespread unauthorized access, all stemming from basic misconfigurations like exposed environment variables, publicly accessible S3 buckets, and flawed authentication implementations. These examples serve as concrete evidence that these theoretical risks translate into tangible, high-impact security incidents.

1. A Structured Pentesting Methodology is Essential for AWS: The talk emphasizes that effective AWS security requires a dedicated penetration testing methodology tailored to the cloud. This includes distinct phases: reconnaissance, vulnerability assessment, exploitation, post-exploitation, and reporting. This structured approach helps identify vulnerabilities proactively, validate existing security controls, and improve the overall security posture before attackers can exploit weaknesses.

1. Open-Source Tools are Powerful for Cloud Security Auditing and Exploitation: A significant finding is the efficacy and accessibility of open-source tools like CloudFox, Prowler, and Pacu. Shutenko highlights their utility for various stages of pentesting, from asset enumeration and attack path identification (CloudFox) to compliance checks and detailed remediation reporting (Prowler), and robust exploitation/attack simulation (Pacu). She notes that these tools can often provide cost-effective alternatives or complements to native AWS solutions, especially for testing and staging environments.

1. Continuous Monitoring and Automation are Non-Negotiable: The dynamic nature of AWS environments necessitates continuous security auditing and monitoring. Shutenko advocates for automating security checks, integrating tools like Prowler with native AWS services like Security Hub, and setting up automated notifications (e.g., to Slack) to detect and respond to misconfigurations in near real-time. This proactive stance is crucial for maintaining security in rapidly evolving cloud infrastructures.

1. Security is a Shared Responsibility: A fundamental finding reiterated by Shutenko is the concept of shared responsibility in cloud security. While AWS secures the "cloud itself," customers are responsible for security in the cloud. This extends beyond security teams to every team member, emphasizing the need for security champions, awareness, and collaborative efforts to understand and mitigate potential risks.

These findings collectively paint a clear picture: AWS security is less about exotic exploits and more about diligent configuration management, adherence to best practices, and proactive, continuous assessment using specialized tools and methodologies.

Technical Deep Dive

▶ Watch: Deep dive into open-source AWS pentesting tools (18:30)

Victoria Shutenko's presentation offers a comprehensive technical deep dive into the various facets of AWS security, focusing on common attack surfaces, a structured penetration testing methodology, and specific open-source tools for identifying and exploiting misconfigurations.

Key Attack Surfaces in AWS

Shutenko outlines the critical components of an AWS environment that are frequently targeted due to misconfigurations:

• Identity and Access Management (IAM): This is often the initial point of compromise.
• Overly Permissive Roles and Policies: Granting wildcard permissions or full access where only limited actions are required (e.g., s3:* instead of s3:GetObject).
• Misconfigured Trust Relations: Incorrectly configured trust policies between AWS accounts or services that allow unauthorized role assumption.
• Weak or Exposed Access Keys: Hardcoded credentials or access keys exposed in code repositories or environment variables. A robust technique is to avoid using administrator access even for administrators, opting for specific roles.

• Storage Services (S3, EFS):
• Publicly Accessible S3 Buckets: Buckets configured for public read or write access, exposing sensitive data, user data, or even hosting websites.
• Misconfigured Permissions on EFS/EBS: Lack of proper encryption for data at rest and in transit, or overly permissive access controls.

• Compute Services (EC2, Lambda): These are frequently exposed to the public internet.
• EC2 Instances: Instances with open ports, running vulnerable software, or lacking proper security group configurations.
• Lambda Functions: Misconfigured functions allowing privilege escalation or remote code execution due to exploitable IAM roles or improper input validation.

• Network Components (Security Groups, VPC):
• Overly Permissive Security Groups: Rules allowing wide-open access (e.g., 0.0.0.0/0 for SSH/RDP).
• Exposed VPC Endpoints: Internal endpoints inadvertently exposed to the public internet.
• Misconfigured Network Access Control Lists (NACLs): Inadequate filtering of inbound/outbound traffic.

AWS Penetration Testing Methodology

Shutenko advocates for a five-step methodology, mirroring traditional penetration testing but adapted for AWS:

1. Reconnaissance:

• Objective: Identify accessible AWS assets and understand the infrastructure.
• Activities: Enumerate resources like IAM roles, EC2 instances, S3 buckets. Visualize the system architecture to understand interdependencies.
• Tools: CloudFox, ScoutSuite, AWS CLI.

1. Vulnerability Assessment:

• Objective: Analyze the environment for misconfigurations and known vulnerabilities.
• Activities: Scan for overly permissive policies, public resources, and insecure configurations.
• Tools: Prowler, Nmap (for network scanning), Pacu.

1. Exploitation:

• Objective: Test identified vulnerabilities to demonstrate potential impact.
• Activities: Attempt privilege escalation via misconfigured IAM roles, access sensitive information, or compromise data (e.g., user data on S3).

1. Post-Exploitation:

• Objective: Determine the full potential impact and maintain access.
• Activities: Access data, perform lateral movement, and verify that compromised IAM roles are not honeypots.

1. Reporting:

• Objective: Provide detailed findings, risks, and remediation steps.
• Activities: Document discovery methods, potential impact, and clear recommendations.

Crucially, Shutenko clarifies the scope of AWS penetration testing: customers can test their own applications, EC2 instances, S3 buckets, Lambda functions, IAM roles, and network configurations. However, AWS managed services, physical infrastructure, and AWS services themselves are out of scope and cannot be tested.

Open-Source Tools for AWS Security

Shutenko highlights several powerful open-source tools:

• CloudFox:
• Purpose: Asset enumeration and attack surface analysis.
• Features: Lists IAM roles, EC2 instances, S3 buckets; identifies attack paths for privilege escalation; visualizes public access and misconfigurations.
• Use Case: Identifying overly permissive S3 buckets and mapping their relationships. The output provides json data and actionable keys for next steps.

• Prowler:
• Purpose: Compliance checks, security assessments, and audits against benchmarks (e.g., CIS Benchmarks).
• Features: Actively maintained with quick updates; integrates with AWS Security Hub for centralized reporting; detailed output in HTML, CSV, and JSON with specific remediation steps; supports scans for IAM, S3, EC2, RDS, and more.
• Use Case: Running compliance scans, identifying non-compliant IAM roles, and automating security assessments. It can be configured to ignore specific non-compliant services deemed acceptable for an infrastructure.

• Pacu:
• Purpose: The "best AWS exploitation framework" for attack simulation.
• Features: Over 50 modules for reconnaissance, privilege escalation, and exploitation; easy to use (like Metasploit); flexible and scriptable for custom attacks; simulates real-world attacks.
• Use Case: Automating privilege escalation scenarios and actively testing security controls.

• ScoutSuite:
• Purpose: Multi-cloud security auditing, providing a high-level overview of security posture.
• Features: Quick, read-only assessment for cloud environments; useful for initial enumeration and discovering potential attack paths.

• CloudSploit:
• Purpose: Similar to Prowler, for security assessment and misconfiguration detection.
• Features: Nice output, but historically less integration with AWS services like Security Hub compared to Prowler.

Shutenko stresses that the most effective approach is to integrate multiple tools rather than relying on a single one. For example, CloudFox for initial reconnaissance, Prowler for compliance and vulnerability assessment, and Pacu for exploitation simulation. She also notes that a dedicated security audit role can be created in AWS to grant scanners the necessary read-only permissions without impacting the infrastructure.

Demo / Proof of Concept

▶ Watch: Exploitation scenario: AWS Lambda privilege escalation (30:30)

Victoria Shutenko illustrates the practical application of her discussed concepts by presenting two distinct AWS exploitation scenarios. While not live demos, these serve as detailed proof-of-concept walkthroughs, highlighting common misconfigurations and their severe consequences, along with crucial mitigation strategies.

1. Overly Permissive AWS Lambda Execution Role

This scenario demonstrates how an attacker can leverage a misconfigured AWS Lambda function's execution role to gain persistent access and potentially escalate privileges to administrator level.

Attack Steps:

1. Enumeration: The attacker first enumerates Lambda functions within the target AWS environment to identify those with excessive permissions attached to their execution roles. This involves checking the IAM role policies associated with various Lambda functions.
2. Permission Abuse: Once a vulnerable Lambda function is identified, the attacker abuses its overly permissive IAM role. For instance, if the Lambda role has permissions to create or modify other IAM roles or policies, this becomes a critical vector.
3. Payload Execution & Persistence: The attacker creates a new Lambda function or modifies an existing one, injecting a payload designed to gain persistence. This payload could, for example, create a new IAM user with administrative access, modify an existing policy to grant broader permissions, or generate new access keys.
4. Privilege Escalation: By executing the payload, the attacker effectively escalates their privileges, potentially achieving administrator access within the AWS account. This complete takeover allows them to access sensitive data, modify resources, or launch further attacks.

Mitigation Steps:

• Input Sanitization and Validation: Sanitize and validate all user input provided to Lambda functions to prevent code injection.
• Principle of Least Privilege for Lambda: Strictly limit IAM permissions for Lambda functions. Use AWS IAM Access Analyzer to review and refine policies, ensuring functions only have the absolute minimum permissions required to perform their specific tasks. Shutenko notes that while IAM Access Analyzer is useful, it's not always exhaustive and might flag roles used infrequently but still necessary.
• Monitor Lambda Activity with CloudTrail: Enable AWS CloudTrail to monitor all API calls and activity related to Lambda functions. This helps detect unusual or unauthorized Lambda invocations or changes.
• Prevent Lambda from Creating IAM Users: In most legitimate use cases, Lambda functions should not have permissions to create or manage IAM users. Remove such capabilities from Lambda execution roles unless absolutely necessary and thoroughly justified.

2. Lambda Remote Code Execution (RCE) to Cloud Takeover

This more advanced scenario demonstrates how an RCE vulnerability in a Lambda function can lead to a full cloud takeover, often involving data exfiltration from S3 and credential theft from Secrets Manager.

Attack Steps:

1. Lambda RCE: The attacker identifies a Lambda function vulnerable to code injection or Remote Code Execution (RCE). This typically occurs when user input is executed directly without proper sanitization.
2. Initial Access & Enumeration: Upon successful RCE, the attacker executes arbitrary commands within the Lambda environment. If the Lambda's IAM role has permissions like s3:ListBuckets and s3:GetObject, the attacker can immediately enumerate and extract sensitive data from S3 buckets.
3. SSRF for Internal Access: The attacker can then use Server-Side Request Forgery (SSRF) techniques (if the Lambda environment allows outbound requests to internal services) to send crafted requests to internal AWS metadata services or other internal endpoints. This can be used to gather more information or attempt to retrieve temporary credentials.
4. Secrets Manager Compromise: Using stolen or leveraged credentials (e.g., from an SSRF attack or directly from the Lambda's environment), the attacker queries AWS Secrets Manager. Secrets Manager often stores highly sensitive data like database credentials, API keys, and passwords.
5. Full Cloud Takeover: With credentials from Secrets Manager, the attacker gains access to critical services and resources, potentially leading to a full cloud takeover, allowing them to control various parts of the AWS environment, including EC2 instances and other sensitive data.

Mitigation Steps:

• Robust Input Validation and Sanitization: This is paramount. Implement strict input validation and sanitization for all data processed by Lambda functions to prevent code injection vulnerabilities.
• Strict IAM Permissions for Lambda and S3: Adhere to the principle of least privilege. Lambda functions should only have permissions to access the specific S3 buckets and objects they require, and only for the necessary actions.
• AWS WAF to Block SSRF and Common Attacks: Deploy AWS Web Application Firewall (WAF) in front of API Gateways or other internet-facing services that invoke Lambda functions. Configure WAF rules to block common web attacks like XSS, SQL injection, and SSRF attempts. Shutenko also discusses automating WAF reporting to Slack for real-time alerts.
• Restrict Access to Secrets Manager: Implement stringent IAM policies to restrict access to Secrets Manager. Only authorized services and roles should be able to retrieve secrets, and only for specific, approved secrets.
• Continuous Monitoring and Logging: Utilize AWS CloudTrail, Amazon GuardDuty, and VPC Flow Logs to monitor for unusual requests, API calls, and network traffic that could indicate an ongoing attack.

These scenarios clearly demonstrate how a chain of seemingly minor misconfigurations can lead to catastrophic outcomes, underscoring the necessity of a layered security approach and vigilant adherence to security best practices.

Defensive Implications

▶ Watch: Q&A: Permissions for using pentesting tools (45:20)

Victoria Shutenko’s talk provides a robust framework for defenders to proactively secure their AWS environments against misconfigurations. The defensive implications are centered on adopting a proactive, automated, and least-privilege-centric approach.

1. Embrace the Principle of Least Privilege (PoLP): This is the cornerstone of AWS security. Defenders must rigorously apply PoLP to all IAM roles and policies, granting only the minimum necessary permissions for users and services to perform their tasks. This means avoiding wildcards (e.g., * for actions or resources) and implementing granular permissions. Shutenko emphasizes that temporary administrative access, even for "five minutes," often becomes permanent due to oversight, creating persistent attack vectors. Regularly audit and remove unused permissions, but with caution, as some roles might be used infrequently but are still critical.

1. Implement Regular and Automated Security Audits: Manual checks are insufficient for dynamic cloud environments. Defenders should automate security audits using a combination of AWS native tools and third-party open-source solutions:

• AWS Config: For continuous monitoring of resource configurations and compliance.
• IAM Access Analyzer: To identify unintended access to resources.
• GuardDuty: For intelligent threat detection and continuous monitoring for malicious activity and unauthorized behavior.
• Security Hub: To aggregate, organize, and prioritize security alerts from various AWS services and partner solutions.
• Prowler: Integrate Prowler for compliance checks against benchmarks (e.g., CIS Benchmarks) and detailed security assessments. Automate its execution (e.g., daily) and integrate its output into Security Hub or send reports (e.g., percentage of compliance) to communication channels like Slack.
• CloudFox/ScoutSuite: Use for initial reconnaissance and high-level overviews to identify potential attack paths.

1. Harden Network and Compute Security:

• Avoid Public EC2 Instances: Wherever possible, prevent EC2 instances from being publicly accessible. Once an IP is known, it becomes a permanent target.
• Limit Security Group Rules: Implement the strictest possible security group rules, only opening necessary ports to specific IP ranges or security groups. Avoid wide-open rules (e.g., 0.0.0.0/0) for sensitive services like SSH or RDP.
• Enable AWS WAF: Deploy and configure AWS Web Application Firewall (WAF) to protect web applications and APIs from common web exploits like XSS and SQL injection, and to block SSRF attempts. Shutenko suggests automating WAF rule management and incident reporting for enhanced effectiveness.

1. Secure Sensitive Data and Secrets:

• Use Secrets Manager: Never hardcode credentials in code or store them in GitHub. Utilize AWS Secrets Manager to store and manage sensitive data like API keys, database credentials, and passwords securely.
• Restrict S3, RDS, DynamoDB Access: Implement strict policies to restrict access to storage services like S3 buckets, RDS databases, and DynamoDB tables. Many roles simply don't need access to these resources.
• S3 Versioning and Object Lock: Enable S3 versioning and Object Lock to protect against accidental deletions, overwrites, or ransomware attacks, ensuring data integrity and recoverability.

1. Develop a Robust Incident Response Plan:

• Define Roles and Responsibilities: Clearly define who is responsible for what during a security incident.
• Automate Response: Leverage AWS Lambda to automate aspects of incident response, such as isolating compromised resources or notifying teams.
• Monitor for Honeypots: Implement honeypot scanners or tokens (e.g., dummy credentials) with automated alerts to detect when an attacker attempts to use them, providing early warning of compromise.
• Contact AWS: It's crucial to inform AWS before conducting penetration tests, especially those involving exploitation, as AWS can block accounts if unauthorized activity is detected.

1. Foster a Security-Aware Culture:

• Shared Responsibility: Emphasize that security is a shared responsibility across all teams (developers, DevOps, security engineers).
• Security Champions: Promote the role of security champions within development teams to embed security considerations throughout the development lifecycle.
• Continuous Education: Given the rapid pace of change in AWS, continuous learning and regular security reviews are essential to stay ahead of new services and potential misconfigurations.

By integrating these defensive strategies, organizations can significantly reduce their attack surface, improve their detection capabilities, and enhance their overall resilience against cloud-based threats stemming from misconfigurations.

Key Takeaways

• Misconfigurations are the Primary Cloud Threat: Human error, the complexity of AWS's 200+ services, and a lack of security awareness are the leading causes of breaches, not inherent AWS vulnerabilities.
• Principle of Least Privilege is Paramount: Always grant the absolute minimum necessary permissions to IAM roles and users, strictly avoiding wildcards and regularly auditing for overly permissive policies.
• Automate Security Audits Continuously: Leverage a combination of native AWS tools (Config, IAM Access Analyzer, GuardDuty, Security Hub) and powerful open-source solutions (Prowler, CloudFox) for automated, regular checks and compliance monitoring.
• Adopt a Cloud-Specific Penetration Testing Methodology: Follow a structured approach encompassing reconnaissance, vulnerability assessment, exploitation (using tools like Pacu), post-exploitation, and detailed reporting to proactively identify and remediate weaknesses.
• Harden All Attack Surfaces: Pay critical attention to securing IAM, S3 buckets, EC2/Lambda functions, and network components like Security Groups by avoiding public exposure, sanitizing inputs, and using AWS WAF.
• Security is a Shared Responsibility: Foster a culture where all team members understand their role in cloud security, supported by clear policies, incident response plans, and continuous monitoring.

About the Speaker(s)

Victoria Shutenko is a dedicated Security Engineer and Penetration Tester at Techmagic. Her expertise spans web, cloud, and mobile penetration testing, making her a versatile professional in the cybersecurity domain. Beyond her corporate role, Victoria is an active member of the AWS community, holding the title of AWS Community Builder, which underscores her deep knowledge and commitment to sharing insights about AWS. She is also passionate about various interests outside of work, including music, CTF (Capture The Flag) competitions, boxing, tourism, traveling, and coffee. Victoria is from Odessa, Ukraine, and actively encourages networking and discussions on cybersecurity.