Reporting and Tracking – Show Me Where I Am
Our Darwin Attack® platform provides one authoritative source for all information about identified vulnerabilities.
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.
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 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:
Customers are responsible for securing their data and applications that utilize AWS services. This involves a range of tasks that can include:
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:
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.
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:
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:
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:
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:
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.
Unlock your organization's full security potential and uncover even more vulnerabilities than before by choosing our advanced penetration testing services.