AWS Penetration Testing – EC2

AWS Elastic Compute Cloud “EC2” allows users to spin up virtual machines within the cloud, these are referred to as instances. During instance deployment users can specify the operating system, architecture, instance type and even the SSH keys required to access the file system.

When it comes to performing penetration tests on EC2 instances, Amazon has a specific EC2 testing policy, this goes through what’s allowed with regards to network stress testing. For any additional testing, amazon states that as long as you’re testing the instance itself and not the underlying EC2 service then you’re all good to proceed.

Getting started with penetration testing on an EC2 instance

From an external perspective, instances can host just about any application that you would find on a traditional computer. With this in mind, performing a penetration test against an instance would be similar to performing a standard network penetration test against physical machines. You would enumerate the target and look for vulnerabilities or outdated software which can be exploited.

A couple of tools which are commonly used in the early stages of a network penetration test are Nmap and Nessus.

terminal$ sudo nmap -sC -sV -vv 111.221.15.53

Nmap scan report for ec2-111-221-15-53.compute-1.amazonaws.com (111.221.15.53)
Host is up, received reset ttl 49 (0.11s latency).
Scanned at 2023-12-14 15:13:16 GMT for 14s
PORT    STATE  SERVICE REASON         VERSION
22/tcp  open   ssh     syn-ack ttl 51 OpenSSH 8.9p1 Ubuntu 3ubuntu0.4 (Ubuntu Linux; protocol 2.0)
80/tcp  open   http    reset   ttl 51 Apache/2.4.51
443/tcp closed https   reset   ttl 51
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

The IP address in this example was randomly changed for security reasons, this will not link to any AWS services and further scans should not be performed.

In the fictitious example above, there are some nmap scan results. The results reveal that the sample IP resolves back to the AWS compute service, this is indicated by the presence of ec2-111-221-15-53.compute-1.amazonaws.com. Furthermore, it also reveals that the services SSH and HTTP are both active on the target instance. This would suggest the instance is most likely being used as a basic HTTP web server.

Once the initial enumeration has been completed, the next steps in a penetration test would focus on the individual services. In this example, the initial approach would most likely focus on the web application running on port 80.

Exploiting the metadata endpoint

The metadata endpoint is a special service provided by AWS for accessing EC2 instance metadata. The endpoint is only accessible from within an EC2 instance and is commonly used by applications which require information about the instance itself.

The metadata endpoint can be accessed from any EC2 instance with the use of the internal IP address 169.254.169.254. As long as the endpoint accepts HTTP GET requests then it can be enumerated using a web browser.

Instance metadata can be used to configure or manage the running instance. It’s divided into categories such as hostname, events, and security groups. Instance metadata can also be used to access user data that was specified when the instance was first launched.

If an instance is compromised or hosts an application which is found to have vulnerabilities then it may be possible to access the metadata endpoint.

http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/

Let’s consider the URL in example 2. After further inspection, it becomes clear that the URL has proxy functionality and can make connections to the domain which follows the proxy keyword. As the application makes HTTP GET requests to the appended domain this can connect to the metadata endpoint.

This example was taken from flaws.cloud, feel free to navigate to the given URL and explore the metadata service to see what treasure can be found.

The metadata endpoint is often targeted when a hosted web application is found to have a Server-Side Request Forgery “SSRF” vulnerability, more information on SSRF can be found here – OWASP – Server-Side Request Forgery “SSRF”.

Further web application exploitation

While SSRF may be one approach towards finding crucial information to access the AWS environment, other web application vulnerabilities can play an important role in compromising an EC2 instance.

Some instances may be configured with AWS profiles. As any AWS access keys are stored within a credentials file this can be leaked via any file inclusion or path traversal vulnerabilities. An example of this can be seen below.

terminal$ curl http://aws-ec2-domain.com/?page=/root/.aws/credentials

[jessie]
aws_access_key_id = AWSKGPMS34WWXHQ3U
aws_secret_access_key = AWKFAKE/PO9736SDS09POWQS/8UKJAS21dedFG

In addition to the AWS credentials file, instances are often set up with SSH access. If such a vulnerability allows it, it may be possible to steal the SSH key file to gain a foothold on the instance.

Unfortunately, web application testing is out of scope for this series. However, many interesting articles can be found within the arctil learning centre. Alternatively, Portswigger Academy has a huge library of free content.

Exploring snapshots

For redundancy, AWS administrators can create snapshots of their EC2 instances. A snapshot is a backup of a volume, should their active volume get corrupted or accidentally deleted then the snapshot can be mounted within a new one.

As a snapshot is like a window in time for an EC2 instance, they can be a treasure trove of valuable information and are often worth further investigation.

To enumerate any snapshots the owner-id would be required. Although the owner-id is unique to each AWS account, they can often get leaked through various means, including;

  • Screenshots
  • Github and code repositories
  • AWS error messages
  • Public EBS snapshots
terminal$ aws --profile Jessies-Bookstore  ec2 describe-snapshots --owner-id 1234df5679432a

Snapshots can be enumerated using the AWS CLI tool ec2 describe-snapshots command. This is essential as there are specific details which are needed to be able to mount it to another volume. To proceed further with this, a personal AWS account would be needed, this is where the free tier becomes useful.

To mount a found Snapshot the snapshot-id would be needed, this information would have been revealed when describing the snapshots in the previous example.

terminal$ aws --profile arctil ec2 create-volume --availability-zone us-east-1a --region us-east-1  --snapshot-id  hsyei28766ai09p

As soon as the volume has been created, it would need to be assigned to a newly created instance, this can be done within the AWS web console. Lastly, using either SSH or the AWS console the created instance can be accessed and the snapshot mounted.

Understanding Security Groups

Security groups act as a virtual firewall for EC2 instances and other AWS services such as databases. Once configured, a security group can be assigned to the instance to allow or block certain traffic to and from.

{
    "SecurityGroups": [
        {
            "Description": "Allows database access.",
            "GroupName": "DatabaseAccess",
            "IpPermissions": [
                {
                    "IpProtocol": "-1",
                    "IpRanges": [
                        {
                            "CidrIp": "0.0.0.0/0"
                        }
                    ],
                    "Ipv6Ranges": [],
                    "PrefixListIds": [],
                    "UserIdGroupPairs": []
                }
            ],
            "OwnerId": "2906752511721,
            "GroupId": "sg-09c81sgs789aga",
            "IpPermissionsEgress": [
                {
                    "IpProtocol": "-1",
                    "IpRanges": [
                        {
                            "CidrIp": "0.0.0.0/0"
                        }
                    ],
                    "Ipv6Ranges": [],
                    "PrefixListIds": [],
                    "UserIdGroupPairs": []
                }
            ],
            "VpcId": "vpc-09c81sgs789aga03"
        }
    ]
}

Above is an example of a security group, this is called DatabaseAccess. From the name and description, it’s quite clear what this security group is for. It allows all traffic to and from the associated database, enabling remote connections.

terminal$ aws --profile jessies-bookstore ec2 describe-security-groups

terminal$ aws --profile jessies-bookstore ec2 describe-security-groups --group-id sg-09c81sgs789aga

Security groups can be enumerated using the ec2 describe-security-groups command. By specifying the –group-id the returned information can be limited to only the desired security group. With the second command in Example #7, this would return the same output as Example #6.




Up Next “Identity and Access Management”

Spread the love