In previous posts, we have covered a range of AWS (Amazon Web Services) security research topics, including attacking S3 buckets and compromising AWS environments. In this article, we’ll be walking through what you need to know when penetration testing your AWS service.

AWS offers over 90 different cloud hosting services that include offerings such as compute and storage, content delivery, security management, network infrastructure, and physical hosting facility for tenant organizations. The wide range of these services typically falls into Infrastructure (IaaS), Platform (PaaS), or Software as a service (SaaS). Uses for these virtual environments include internal organizational, a service to consumers, or a mixture of both. The most common purposes include networking, data storage, web application services, and code development.

The benefit of using cloud services is that it gives organizations and individuals the ability to quickly, and efficiently scale web service needs on a reliable, and flexible platform. At the same time, offloading the maintenance and upfront fixed costs associated with network-connected hardware.

What is important to understand here is that the AWS platform that you build your environment upon cannot be pentested. However, your organization’s configuration of the AWS platform and the additional application code or assets living in your environment can be tested.

AWS permits security testing for User-Operated Services, which includes cloud offerings created and configured by the user. For example, an organization can fully test their AWS EC2 instance excluding tactics related to disruption of business continuity such as launching Denial of Service (DOS) attacks.

Pentests involving Vendor Operated Services, which are those cloud offerings that are owned and managed by a third-party vendor, are restricted to the implementation and configuration of the cloud environment and not the underlying infrastructure. For example, AWS services such as Cloudfront and the API Gateway configuration may be pentested but the hosting infrastructure is off limits.

Elastic Cloud Computing (EC2) is an AWS service which is commonly penetration tested. In an AWS EC2 instance, specific areas that allow penetration testing include:

• Application Programming Interface (API) (e.g. HTTP/HTTPS)
• Web and mobile applications that hosted by your organization
• The application server and associated stack (e.g. programming languages such Python, React)
• Virtual machines and operating systems.

These areas are not the limits of what can be penetration tested, but are commonly included during an AWS pentest.

Many of AWS services are based on the Software-as-a-Service (SaaS) model, which means the end user does not own the environment and cannot be pentested in the same way as a traditional on-premise environment or Infrastructure-as-a-Service (IaaS) model. However, the configuration and identity of those SaaS services can be tested from a blackbox engagement or even through a security audit.

Additional things that cannot be pentested within the AWS cloud due to legal and technological constraints:

• Services or applications that belong to AWS (IE: SaaS offerings as previously addressed);
• The physical hardware, underlying infrastructure, or facility that belong to AWS;
• EC2 environments that belong to other organizations (such as partners or vendors)
• Security appliances that are managed by other vendors without their permission;
• Amazon’s small or micro Relational Database Service (RDS).

The methodologies used to pentest traditional security infrastructure and the AWS Cloud differ in a multitude of ways. Most of these differences refer back to the ownership of the systems. Since Amazon owns the core infrastructure, the methodology invoked used in traditional ‘ethical hacking’ would violate the AWS acceptable use policies and potentially invoke incident response procedures by the AWS security team.

Pentesting AWS must instead focus on user-owned assets, identify and accesses management user permissions configuration, and use of the AWS API’s that are deeply integrated into the AWS ecosystem. For example, targeting and compromising AWS IAM Keys, Testing S3 bucket configuration and permission flaws, establishing access through Lambda backdoor functions, and covering tracks by obfuscating Cloudtrail logs. These strategies for attack are specific to AWS Cloud and require specific knowledge and approach.

Performing a pentest within the cloud requires adequate planning and expert knowledge. General steps and preparation that should be taken before the pentest begins include:

1. Defining the scope, including the AWS environment and target systems
2. Run your own preliminary
3. Determine the type of pentest you would like conducted (e.g. black box, white box, gray box)
4. Outline expectations for both internal stakeholders and the pentesting company
5. Establishing a timeline for the technical assessment to occur, receive formal reports, and potential remediation and follow-up testing
6. Developing the protocol and rules of engagement if the pentest reveals the client may already have been breached or is under an ongoing (live) attack
7. Obtaining written approval to conduct the test by the client (and other third parties that may be involved). You will need to:
   • Fill out penetration test request form
   • Tell AWS the dates that testing will take place
   • Tell AWS the IP Address range the scan or penetration testing will come from
   • Tell AWS the IP Address range being tested (scope)

Not all of these questions are easy to answer and can lead to additional questions. What’s important is clearly defining the scope, objectives, and rules for the AWS Pentesting to take place. This will help avoid costly, time-consuming mistakes later on and help you in determining the right pentesting company.

Organizations must understand the purpose of conducting a pentest in the AWS cloud before the test. The objectives – commonly driven by legal, regulatory, or other industry requirements – will develop and guide both the pentesters and the organizations including the frequency and scope.

For example, the Payment Card Industry (PCI) requires that merchants perform annual internal and external network pentests relating to their cardholder data environment (CDE). This includes a pentest against segmentation controls if the merchant has segmented their CDE. However, service providers that are under PCI must conduct a pentest against the segmentation controls of the CDE every six (6) months as opposed to annually.

Understanding these requirements will help ensure that organizations conduct pentests that meet both their organizational and security obligations.

There are many independent and COTS tools that are developed uniquely to the cloud environment and help with understanding misconfigurations and flaws in AWS. One example is the tool we released around enumerating AWS S3 buckets called Buckethead.

Before the Pentest Begins, run the following basic tools to identify basic flaws:

• AWS Inspector (designed for the security of apps deployed on AWS)
• Nmap (network discovery and service enumeration)
• Rhino Security Lab’s BucketHead (Identifying misconfigured AWS S3 Buckets)

While the tools referenced here can help sniff out and exploit some of these vulnerabilities, there are several things you can look for manually. It helps to perform regular reviews of your configurations to ensure top-notch security. Seemingly simple things like limiting permissions allocated to users, not performing operations with your root account unless necessary, and implementing reliable multifactor authentication are all quick and easy ways to beef up your AWS instances’ security.

Selecting a third-party to conduct your pentest should not be “on the whim” or because the third-party has great marketing materials or “X” number of certifications. Bigger is not always better; it is critical to find (and vet) a pentest company that can demonstrate expertise within the industry, including extensive knowledge of AWS.

A great pentesting company will be able to provide non-sensitive reports, attest to the AWS environment and its technical functions, and be able to tailor the pentest in accordance to the client’s objectives. If there are doubts about a potential pentest company, you should consider alternatives.

We employ a range of AWS-specific tests, including the following:

• EC2 instance and application exploitation
• Targeting and compromising AWS IAM keys
• Testing S3 bucket configuration and permissions flaws
• Establishing private-cloud access through Lambda backdoor functions
• Cover tracks by obfuscating Cloudtrail logs

Checkout our previous research regarding AWS Penetration testing and finding configuration flaws that lead to unnecessary information disclosure.

Following a pentest, a documented report of findings and remediation recommendations will be provided to the organization. Findings are based on risk to the AWS environment; the higher the risk, the more likelihood of an exploit or the greater the potential impact to the organization. Obviously, you should remediate the highest risks first. However, it is equally important to have the pentest company perform a retest verify remediation closure. In specific laws, regulations, and standards, a retest is required if “Critical” or “High” findings were discovered by the pentesting company.

Additionally, if any pentest reports are distributed to an auditor, a client of the organization or another third-party, remediation details should be included. Safe distribution of these reports must be considered to prevent a malicious attacker from intercepting the data and gaining knowledge of how to potentially launch an attack against the organization.

AWS includes many technical and legal aspects, some of which are complex and not easily understood. To recap, proper planning, identifying key risks and objectives, and selecting an appropriate pentest company are crucial elements for success. Organizations should understand the capabilities and limitations when conducting a pentest in the AWS cloud, including what types of tools and tests are permitted and what their roles and responsibilities are; if they are unsure, it is imperative they consult with a third-party expert for guidance.