Penetration Testing on AWS: A Practical Guide

• What Is Pentesting? How Does It Work Step-by-Step?
• 7 Pentesting Tools You Must Know About
• Penetration Testing on AWS: A Practical Guide
• Pentesting Certification: Why Certify and Top 6 Certifications
• What is Penetration Testing as a Service (PTaaS)?

10 Minute Read

Amazon Web Services (AWS) is the world’s leading cloud platform. It provides elastic computing services, cloud storage, databases, and a range of data analytics and AI applications, as well as deployment and automation services.

Before migrating to AWS, companies should consider compliance obligations, the risks of cyber attacks against cloud resources or sensitive data hosted on the cloud, and how to address them. A highly effective way of discovering security vulnerabilities in a cloud environment is via penetration testing. A penetration tester can discover critical security weaknesses in an AWS deployment and provide actionable recommendations for remediating them.

However, because AWS is a third-party data center, companies who perform penetration tests are required to follow specific instructions and comply with AWS restrictions.

In this article:

• Why Pentesting on AWS Matters
• The Shared Responsibility Model
• AWS Penetration Testing vs On-Premise Penetration Testing
• What Are You Allowed to Test in AWS?
• What Are You Not Allowed to Test in AWS?
• How to Perform Penetration Testing on AWS
  • Prerequisites
  • Testing Identity and Access Management (IAM)
  • Testing Logical Access Control
  • S3 Buckets
  • Database Service

Cloud environments are highly complex, and there are several security issues that are difficult to discover using existing cloud security measures. Here are a few examples of security gaps that penetration testing can help discover and remediate.

Failure to secure the client’s part of the shared responsibility model
AWS uses a shared responsibility model, which states that the cloud customer is responsible for securing workloads and data. In many cases organizations have poor visibility over their security responsibilities in the cloud.

Missing authentication, permissions, or network segmentation
Many AWS resources do not have multi-factor authentication, do not use network segmentation (via AWS security groups), or provide excessive permissions. It can be difficult to identify these assets in a large cloud deployment.

Compliance requirements
Organizations subject to compliance standards such as HIPAA, SOX, PCI DSS, etc. need to ensure that AWS resources meet their compliance requirements. This makes it important to perform internal audits of cloud assets, identify and remediate their security weaknesses

Security testing performed on AWS follows the shared responsibility model. Amazon differentiates between two types of security:

• Security of the cloud—this means security of the AWS cloud platform itself, including the cloud platform and all AWS services. Amazon is responsible for securing the cloud platform and regularly tests its cloud with internal or external security engineers. Amazon customers may not perform penetration testing on this aspect of cloud security.
• Security in the cloud—this means the security of resources or assets deployed by an organization on the AWS platform. These are the responsibility of the company or resource owner, who need to ensure applications, assets, and systems are securely configured. In general, organizations may perform penetration testing to verify these aspects of a secure deployment.

The methodologies and methods used for AWS penetration differ from traditional penetration testing in many ways. The most important difference is ownership of the asset under test.

Amazon corporation owns all of the core infrastructure operated by AWS. Therefore, many tests and strategies used in traditional penetration testing may violate the AWS Terms of Service. If a penetration testing procedure conflicts with AWS policies, it is prohibited on AWS infrastructure, and might trigger the involvement of the AWS Incident Response Team.

AWS allows customers to perform security assessments of AWS assets. The term security assessment includes various activities performed to verify and validate security controls across AWS assets.

Here are key examples of security assessments allowed by AWS:

• Port scanning
• Vulnerability scanning or checks
• Web application scanning
• Exploitation
• Forgery
• Injections
• Fuzzing

Here’s a summary of Amazon’s rules for security assessments that are allowed:

• Allowed: Security tools that perform a remote query of AWS assets to determine the software’s name and version, for example, banner grabbing. This test aims to compare against a list of versions vulnerable to DoS.
• Allowed: Security tools or services that crash a running process on AWS assets, temporarily or otherwise, for local or remote exploitation during a security assessment. This tool is not allowed to engage in resource request flooding or protocol flooding.
• Allowed: Security tools or services with DoS capabilities with explicit ability to disarm, disable or otherwise render harmless the DoS capability.

You can perform these tests remotely against your AWS assets, locally within your virtualized assets, and between your AWS assets.

Related content: Read our guide to pentesting tools

AWS allows you to perform security assessments to validate your security controls. However, AWS must ensure that these tests do not harm other AWS customers and that AWS can continue providing quality service across the AWS ecosystem.

AWS prohibits simulating Denial of Service (DoS) or similar attacks against any AWS assets. This restriction is explained in AWS’s DDoS Simulation Testing policy.

Here’s a summary of Amazon’s rules for prohibited security assessments:

• Not allowed: Any security service or tool that creates, demonstrates, or determines the existence of a DoS condition in any manner, simulated or actual.
• Not allowed: Tools, services, or features of tools and services that include actual DoS capabilities.
• Not allowed: Security tools or services with DoS capabilities that do not include any explicit ability to disarm, disable or otherwise render harmless the DoS capability.

AWS holds customers responsible for verifying and validating that any security assessment performed by the customer or on their behalf complies with the policy. Customers violating this policy will be held responsible for all damages to AWS and AWS customers caused by the offending security assessment activities.

Prerequisites

Define the following aspects prior to conducting a penetration test on AWS:

• The scope of the penetration test, including the target system.
• The type of test to be performed.
• Requirements of the test, which should be agreed between stakeholders and the penetration testing contractor.
• A schedule for the penetration test.
• A protocol the penetration tester should follow in case they discover an existing security breach.
• Written approval by system owners for penetration testers to conduct the test.

Testing Identity and Access Management (IAM)

Penetration testers should focus on the following aspects when testing IAM and identity security in AWS:

• Testing whether keys exist in the root account
• Testing whether two-factor authentication is in place
• Testing whether root account is used for day-to-day tasks or automation
• Testing whether service accounts have unrestricted permissions
• Testing whether users have more than one key
• Testing whether SSH and PGP keys have not been refreshed
• Checking for inactive accounts

Testing Logical Access Control

Testers should focus on:

• Identifying if actions have been properly assigned to resources
• Testing if access to sensitive resources and processes in AWS is properly controlled
• Testing that credentials related to AWS accounts are safe and secure

S3 Buckets

Testers should focus on:

• Testing if relevant security features are enabled on buckets—authentication, encryption, etc.
• Testing if security auditing is enabled on buckets—versioning, logging, etc.
• Testing if permissions for operations like GET, PUT, and DELETE are restricted to certain users.

Database Service

Testers should focus on:

• Testing whether data is regularly backed up and if backups can be safely restored.
• Testing whether sensitive resources are deployed across multiple availability zones (multi-AZ).
• Testing whether database access is limited to known IP addresses.

In this article, we explained the basics of penetration testing on AWS and the differences between penetration testing in your own environment vs. an environment owned by a third-party provider.

We presented the rules for pentesting on AWS, which can be summarized as follows:

• AWS allows port scanning, vulnerability scanning, exploitation, code injection, fuzzing, crashing Amazon resources as part of a penetration test.
• AWS does not allow denial of service (DoS) or distributed denial of service (DDoS) against Amazon resources, except with special restrictions.

Finally, we showed how to approach your penetration test across different parts of the Amazon infrastructure - Identity and Access Management (IAM), logical access control, S3 buckets, and database services. In each of these, testers should be aware of risks and attack surfaces specific to the Amazon environment.

HackerOne can help you manage penetration tests against Amazon and other cloud and on-premise environments. Learn more about the HackerOne penetration testing service.