AWS Hacking

Penetration Testing in AWS

AWS permits security testing for eight User-Operated Services only:

• EC2 Instances (including NAT and ELBs)
• S3 Buckets
• RDS
• Aurora
• Lambda & Lambda Edge functions
• Lightsail
• Cloudfront*
• API Gateway*

Amazon has a Shared Responsiblitity platform; meaning users are responsible for their data, encryption and configuration of services. Amazon is responsible for the underlying cloud architecture. Therefore, the following normal pentest activities are forbidden:

• Denial of Service
• Spoofing
• DNS Zone Walking on Route 53
• Flooding Attacks (including Port and Protocol based attacks)
• Physical hardware related attacks

(*)Cloudfront and the API Gateway configuration may be pentested but the hosting infrastructure is off limits.
Note:At this time, AWS policy does not permit testing small or micro RDS instance types. Testing of m1.small, t1.micro or t2.nano EC2 instance types is not permitted.

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 organisation
• 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.

How traditional pentesting methodolgy differs for AWS

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.

Preparing for an AWS pentest

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:

• Defining the scope, including the AWS environment and target systems
• Run your own preliminary
• Determine the type of pentest you would like conducted (e.g. black box, white box, gray box)
• Outline expectations for both internal stakeholders and the pentesting company
• Establishing a timeline for the technical assessment to occur, receive formal reports, and potential remediation and follow-up testing
• 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
• Obtaining written approval to conduct the test by the client (and other third parties that may be involved). You will need to:
  • Complete the Amazon NDA for the Customer Service Policy for Pentesting:
  • pen-test-nda@amazon.com

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.