Best Practices for Conducting AWS Penetration Tests

Penetration testing AWS cloud workloads is an increasingly popular and confusing initiative. This guide is meant to provide a bit of insight on how to think about approaching penetration testing in your cloud environment and help to make informed decisions in conducting offensive cloud engagements.

Understanding the AWS Security Model

The AWS Cloud Shared Security Model is a framework that delineates the security responsibilities between Amazon Web Services (AWS) and its customers. This model is crucial for understanding how to effectively secure applications and data in the cloud. The AWS Security shared responsibility model divides the tasks of securing the infrastructure that runs all the services offered between AWS and the customer. Here's a breakdown of the responsibilities:

AWS Responsibilities: “Security of the Cloud”

AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. This includes hardware, software, networking, and facilities that run AWS Cloud services. Specifically, AWS manages the security of the following components:

• The global infrastructure, including the data centers and their physical security
• The foundation services, including computing, storage, and networking
• The hardware and software that powers these services

Customer Responsibilities: “Security in the Cloud”

Customers are responsible for securing their data and applications that utilize AWS services. This involves a range of tasks that can include:

• Managing the data, including encryption options, and data integrity controls
• Managing user access, including identity, access management, and resource policies
• Securing the operating systems, platforms, and applications they use
• Network traffic protection, including firewall configurations and network segmentation

Preparing for AWS Penetration Testing - Important Outputs

Cloud penetration testing is a critical component of a comprehensive “security in the cloud” program. Conducting penetration testing in the cloud environment serves several important purposes:

1. Identifying Vulnerabilities: Penetration testing helps in identifying vulnerabilities that could be exploited by attackers. This includes misconfigurations, software bugs, and inadequate security practices within the cloud environment.
2. Compliance: Many industries and regulations require penetration testing as part of compliance requirements. Conducting these tests ensures that the cloud environment meets the necessary compliance standards.
3. Security Assurance: Regular penetration testing assures businesses and their stakeholders that their cloud infrastructure is secure. It helps in building trust and confidence in cloud-based operations.
4. Risk Management: By identifying and addressing vulnerabilities, organizations can better manage their risk posture. Penetration testing allows for the prioritization of risks based on their severity and potential impact, enabling more effective risk management strategies.
5. Incident Response Preparedness: Through penetration testing, organizations can test their incident response mechanisms. It helps in identifying gaps in response plans and improving the speed and effectiveness of response to security incidents.

Conducting the AWS Penetration Test – An Objective-Based Approach

The first thing to do when engaging in AWS Penetration Testing is to clearly define your objective. A common conversation-starting ground begins along the general initiative of “improving cloud security” which on its face is a good goal, but upon examination is too broad to have any real meaning. “The cloud” is not a singular entity. What workloads should be tested? Is the scope focused on external cloud assets or internal cloud resources? Are there business-critical applications built and hosted in the cloud that present high-value attack vectors? To refine the objective, we should consider the different approaches to cloud pen testing.

Approach 1: External

Cloud environments contain resources that are intentionally – or unintentionally – exposed on the external network. In this scenario, an organization’s primary objective is to uncover issues on its internet-facing cloud components and evaluate the efficacy of external security controls.

The penetration tester’s primary objective is to discover vulnerabilities and misconfigurations on your internet-reachable assets, and secondarily to breach the perimeter. This typically involves activities such as:

• Port scanning, recon, and other enumeration to identify exposed services.
• Manual review of discovered services and resources.
• Exploitation development and efforts targeted at identified issues to demonstrate impact.

Cloud-specific considerations from the external perspective include common misconfigurations like publicly exposed S3 buckets or EBS Snapshots and secrets leaking into Source Code Management (SCM) systems, in addition to more traditional CVE-based issues. Evaluating your external AWS infrastructure is an important initiative that simulates the most probabilistic threat model, an unauthenticated opportunistic attacker.

An important limiting factor to consider for external cloud pen testing is time. You’ve likely engaged with your pentester on a 1-2 week project, whereas real-world attackers are unbound by such constraints. Additionally, external cloud pen testing typically excludes social engineering, one of the most common attack vectors for gaining a foothold within an organization. With this in mind, it’s important to dissuade expectations of a successful “outside-in” attack wherein a pentester can breach the cloud in a matter of days. For these reasons, it is best practice to engage with a more continuous external network solution like Attack Surface Management.

Common External Cloud Pentesting Findings:

• Keys and secrets leaked into source code management (SCM) or production assets
• Insecure cloud service configurations – e.g. enabling direct user registration via AWS Cognito
• Unpatched software and services

Approach 2: Internal

Before diving into an internal AWS cloud penetration test, it’s wise to undergo a Cloud Security Assessment, which reviews the configuration of your entire cloud infrastructure. This is analogous to conducting vulnerability scanning before engaging in a full penetration test. The walk-before-you-run approach is a good way to catch common issues and harden the environment before commissioning a full cloud penetration test.

Once there’s been a good effort made at hardening the cloud environment, engaging in an Assumed Breach cloud penetration test is a good way to stress test a real-world world attacker scenario and address the question, what if? What if a user’s IAM users are stolen through a phishing attack? What if an applications server, or associated credentials, are compromised? What if an attacker gains access to my AWS environment?

For a successful cloud penetration testing engagement, the objective and perspective need to be clearly defined. The objective could be obtaining sensitive business or customer data, gaining access to the management account, or demonstrating the ability to push code to production systems. An objective serves as the anticipated North Star, but a pentester may uncover attack paths that lead to unforeseen or otherwise previously unknown outcomes.

The starting perspective is assigning a role to the assumed breach. Common perspectives include a compromised developer account, a compromised standard user, or a compromised application server. What perspective to begin with is largely dictated by the threat model you want to simulate.

Common Internal Cloud Pentesting Findings:

• Cleartext passwords and secrets in configuration files
• Insecure assume role policies
• Lack of network segmentation and access control enforcement
• Overprivileged accounts

Approach 3: The Web Application

Web applications built, managed, and deployed in the cloud require a nuanced discussion. In this case, the question becomes is your objective to test the application’s code and functionality or are you interested in testing the application’s deployment and relationship to the cloud infrastructure at large? While there is some overlap in these two objectives, the primary focus leads to separate assessment types.

If you want the application’s functionality and code tested, it's best to approach it from the perspective of a traditional web application penetration test. The Web application built, managed, and deployed in the cloud requires a nuanced discussion. In this case, the question becomes is your objective to test the application’s code and functionality or are you interested in testing the application’s deployment and relationship to the cloud infrastructure at large? While there is some overlap in these two objectives, the primary focus leads to separate assessment types.

If you want the application’s functionality and code tested, it's best to approach it from the perspective of a traditional web application penetration test. This involves focusing on the application layer issues such as SQL injection, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), security misconfigurations, and business logic flaws. This method leverages tools and techniques to assess the security of the web application itself, separate from its cloud environment. Techniques include both automated scanning and manual testing to ensure a thorough examination of the application's security posture.

On the other hand, if the objective is to understand how the web application interacts with and is secured within AWS infrastructure, the focus shifts. This approach considers the security of the application in the context of its cloud deployment, including IAM roles and policies, network configurations, and data storage solutions. This type of testing might involve assessing the effectiveness of the identity and access management (IAM) configuration, ensuring that S3 buckets are properly secured, and evaluating the security of Lambda functions and other AWS services used by the application.

Common Web Application Findings:

• Privilege Escalation via Metadata Server
• Hardcoded AWS Access Keys

Conclusion

Penetration testing AWS cloud environments is essential for identifying vulnerabilities that could be exploited by attackers. By choosing the right approach and focusing on specific objectives, organizations can effectively enhance the security of their cloud deployments. Whether through external, internal, assumed breach testing, web application assessment, or a hybrid approach, the goal is to identify and remediate vulnerabilities to protect sensitive data and maintain business continuity.