Penetration_Testing_In_Cloud

Module 06: Penetration Testing in Cloud

CyberQ Document
Module 06: Penetration Testing in Cloud

Exercise 1: Identifying Misconfigured S3 Buckets in AWS by Penetration TestingA misconfigured AWS S3 bucket will be vulnerable to different types of threats. A penetration testing of AWS S3 buckets helps in identifying misconfigured and secure buckets.
Lab Scenario
Amazon simple storage service (S3) is an AWS service that can be used to store data. It allows a cloud security engineer to securely store data, ensure its availability, and improve performance. If the S3 buckets are not appropriately configured, they will be vulnerable to different threats. Cloud security engineers can perform penetration testing to identify the misconfigured and secured S3 buckets.
Lab Objective
This lab will demonstrate how to create a secure S3 bucket, create a vulnerable S3 bucket, install AWS CLI to create a penetration testing environment in Windows VM, and perform penetration testing to identify a vulnerable S3 bucket.
Overview of AWS S3
Amazon S3 allows AWS customers to upload and retrieve data anytime, from anywhere on the web. Amazon S3 uses buckets to store objects. An object refers to any type of file, such as a text file, a video, or a photo. While adding files to Amazon S3, customers have the option to include their metadata and set permissions to control access to them. Customers can control access to each bucket (for example, who can list, create, and delete objects in a bucket), choose the geographical region where the bucket will be stored, and view the access logs for a bucket and its objects. Cloud security engineers can provide groups of users with read/write access to S3 buckets or objects within them. By default, public access to S3 buckets is blocked. If a cloud security engineer accidentally configures a bucket for public read and write access, it becomes vulnerable and anyone with the bucket name can access the data and perform malicious activities.
Lab Tasks
Note: Web applications in a cloud environment may undergo frequent updates. As we are working on a cloud-based environment for this lab (i.e., AWS), the application interface may be updated with time. Hence, in case you happen to work on an updated version of AWS, the user interface you see on the application might differ from what you see in the lab. Consequently, the steps and screenshots demonstrated in this lab might also differ.
Note: Before starting this lab, you should create an AWS Free Tier account using the following link: https://aws.amazon.com/free, in case you have already not created for the previous module. Once the registration is complete, perform the following tasks:
Note: You can also use any existing AWS account but be aware that it may incur significant charges to your account.

By default Admin machine is selected. Click Ctrl+Alt+Delete
By default Admin account is selected, type Pa$$w0rd and press Enter button to login.
To open the browser, double-click on the Google Chrome icon on the desktop.
Type aws.amazon.com in the address bar and press Enter
The AWS Web Services - Cloud Computing Services page appears. Click on AWS Management Console from the My Account dropdown menu, as shown in the screenshot below.
The AWS Sign-in page appears. Choose Root user and type the AWS administrator account ID (Root user email address), as shown in the screenshot below, and click on Next.
The security check page appears. Type the characters shown in the image and click Submit.
Type the password in the Password field and click on Sign in, as shown in the screenshot below.
Select Services from the menu bar and click on S3 under the Storage section of All Services page.
The Amazon S3 page appears now. Click on Create Bucket at the right corner of the Buckets pane.
In the Create bucket window that opens, give an appropriate name and AWS region for the bucket under General configuration. In this lab, we are providing the following General configuration:
Bucket name: ccse-demobucket-1
AWS Region: us-east-2
Click on ACLs enabled radio button for Object Ownership. Scroll down to the bottom. Under Block Public Access settings for this bucket, ensure the checkbox for Block all public access is selected.
Scroll down to the bottom and click on Create bucket to create your bucket.
Now, to upload objects into the bucket, scroll down in the Amazon S3 dashboard, locate your bucket named ccsedemobucket-1, and click on it.
Click on Upload under the Objects tab.
In the Upload window that appears, click on Add files.
Now, create a ccsedemo-1.txt file, select the created text file ccsedemo-1.txt from the local VM, and then click on Open.
Scroll down and click on Upload at the bottom.
In the subsequent window that appears, click on ccsedemo-1.txt under Files and folders.
It will take you to another window named ccsedemo-1.txt. Click on the Permissions tab.
Click on Edit at the right corner of Access control list (ACL).
In the Access control list (ACL) window that appears, you will see that the Read/Write options are not active for Everyone (public access). This ensures the S3 bucket named ccse-demobucket-1 is secure and its objects cannot be accessed by everyone.
Now, you need to create a vulnerable S3 bucket. To do this, click on Amazon S3 in the left pane.
In the Amazon S3 dashboard, click on Create bucket at the right corner of the Buckets section.
In the Create bucket window, provide an appropriate bucket name and region under General configuration. In this lab, we have used the following general configuration:
Bucket name: ccse-demobucket-2
AWS Region: us-east-2
Click on ACLs enabled radio button for Object Ownership. Scroll down and uncheck Block all public access under Block Public Access settings for this bucket.

Scroll down and select the acknowledgement checkbox.
Scroll down and click on Create bucket.
Now, you will be in the Amazon S3 dashboard. Scroll down in the Buckets table to locate the bucket you created, ccse-demobucket-2, and click on it.
In the Objects pane, click on Upload.
Click on Add files in the subsequent Upload window.
Now, create a ccsedemo-2.txt file, select the created text file ccsedemo-2.txt , and then click on Open.
Scroll down and click on Upload.
After the text file is successfully uploaded, scroll down and click on ccsedemo-2.txt under Files and folders.
You will be taken to a new window that displays ccsedemo-2.txt properties. Click on the Permissions tab.
Click on Edit to the right corner of Access control list (ACL).
Under Access control list (ACL), select the Read checkboxes for Objects and Object ACL next to Everyone (public access).
Scroll down and select the acknowledgement checkbox. Then, click on Save changes.
Now, you need to enable full access to everyone for ccsedemobucket-2 using CloudShell. Click on the CloudShell icon at the top right corner of AWS console.
In the CloudShell window, type the following command in CloudShell, to enable write access control list and press Enter.

Note: Alternatively, you can copy the below command from D:\CCSE Lab Commands.htm to the clipboard and paste it into the editor.
Note: In the following command replace the vulnerable S3 bucket name(ccse-demobucket-2) with the name of your vulnerable bucket in the CloudShell window.
aws s3api put-bucket-acl --bucket ccse-demobucket-2 --grant-write-acp-uri=http://acs.amazonaws.com/groups/global/AllUsers

Next, type the following command in CloudShell and press Enter, to grant full control to the resources.

Note: Alternatively, you can copy the below command from D:\CCSE Lab Commands.htm to the clipboard and paste it into the editor.
Note: In the following command replace the vulnerable S3 bucket name(ccse-demobucket-2) with the name of your vulnerable bucket in the CloudShell window.
aws s3api put-bucket-acl --bucket ccse-demobucket-2 --grant-full-control uri=http://acs.amazonaws.com/groups/global/AllUsers

Now, go back to AWS console, click on Services, and then click on S3 under Storage.
Click on ccse-demobucket-2.
Click on Permissions.
Scroll down and click on Edit in the Access control list (ACL) section.
You will see that all permissions are granted for Everyone (public access) for Objects and Bucket ACL.
You have created a vulnerable bucket with full public access.
Next, To create a penetration testing environment, you need to install AWS CLI. To do this, navigate to D:\CCSE\CCSE Tools\CCSE Module 05 Penetration Testing in Cloud\AWS CLI and double-click on AWSCLI64PY3.exe on the setup file.
In the AWS Command Line Interface Setup window, click on Next.
Now, select the checkbox for accepting the license agreement and click on Next.
In the Custom Setup window, click on Next.
In the next window, click on Install.

Note: If a User Account Control pop-up appears, click on Yes.

When the installation is complete, click on Finish.
Now, in the local VM machine, search for cmd at the bottom and click on Open.
Type the following command in command prompt and press Enter confirm the installation.

Note: Alternatively, you can copy the below command from D:\CCSE Lab Commands.htm to the clipboard and paste it into the editor.
aws --version

Now, you need to set the environment variable. Type the command that is given below in cmd to get the location of the AWS CLI file path. Press Enter. Then, copy the path of the AWS CLI file.

Note: Alternatively, you can copy the below command from D:\CCSE Lab Commands.htm to the clipboard and paste it into the editor.
where aws

To execute the AWS CLI from command prompt, search for Environment Variables in the start menu of the local Windows VM. Then, click Open for Edit the system environment variables.
In the Advanced tab of the System Properties window, click on Environment Variables.
In the next window, select Path and click on Edit under User variables.
In the Edit User Variable window that appears, in the Variable value field, put a semicolon at the end of the existing path and paste the AWS CLI location that you copied from the command line. Click OK.
Click OK again.
Click OK again.
Close Command Prompt and launch it again.
After you have installed the AWS CLI, open the command prompt and type the following command in cmd to list the objects in the S3 bucket named ccse-demobucket-1. Press Enter.

Note: Alternatively, you can copy the below command from D:\CCSE Lab Commands.htm to the clipboard and paste it into the editor.
Note: In the following command replace the secure S3 bucket name(ccse-demobucket-1) with the name of your secure S3 bucket in the cmd window.
aws --no-sign-request s3 ls s3://ccse-demobucket-1

You will get an Access Denied output because the bucket has been secured and configured properly.
Next, to get the access control list of the S3 bucket named ccse-demobucket-1, run the following command:

You will get an Access Denied output because the bucket has been appropriately configured and secured.
Now, run the following command to perform a penetration testing on the second S3 bucket named ccse-demobucket-2

Note: Alternatively, you can copy the below command from D:\CCSE Lab Commands.htm to the clipboard and paste it into the editor.
Note: In the following command replace the vulnerable S3 bucket name(ccse-demobucket-2) with the name of your vulnerable S3 bucket in the cmd window.
aws --no-sign-request s3 ls s3://ccse-demobucket-2

Upon running the command, you will get the text file object named ccsedemo-2.txt stored in the S3 bucket named ccse-demobucket-2 because this bucket is misconfigured with public access.
Now, to get the access control list of the second S3 bucket named ccse-demobucket-2, run the following command:

Note: Alternatively, you can copy the below command from D:\CCSE Lab Commands.htm to the clipboard and paste it into the editor.
aws s3api get-bucket-acl --bucket ccse-demobucket-2 --no-sign-request

You will get FULL_CONTROL as the permission output. This indicates ccse-demobucket-2 is misconfigured and the information is publicly accessible.
Next, to prevent all users from writing to the ccse-demobucket-2 bucket, go back to Edit access control list (ACL) of ccse-demobucket-2 and uncheck the Bucket ACL Write permissions for Everyone (public access).
Scroll down and select the acknowledgement checkbox. Click on Save changes.
Now, go back to the Command Prompt window and run the following command again to check the ACL.

Note: Alternatively, you can copy the below command from D:\CCSE Lab Commands.htm to the clipboard and paste it into the editor.
Note: In the following command replace the vulnerable S3 bucket name(ccse-demobucket-2) with the name of your vulnerable S3 bucket in the cmd window.
aws s3api get-bucket-acl --bucket ccse-demobucket-2 --no-sign-request

You will see that the permissions have changed from Full Control to READ, WRITE, and READ_ACP.

As described above, a cloud security engineer can perform penetration testing on AWS S3 buckets to identify misconfigured buckets and take necessary actions to secure them.

Note: Ensure you delete, shut down, or terminate all resources created and used in this lab to prevent their billing.

Now delete the instances created in this lab. Navigate to the Buckets under Amazon S3 and select the checkbox of the bucket created in this lab (here. ccse-demobucket-1). Click on the Empty button to empty the bucket before deleting it. In the pop up window, enter permanently delete and click on Empty.
Navigate to the Buckets under Amazon S3 and select the checkbox of the bucket created in this lab (here. ccse-demobucket-2). Click on Empty button to empty the bucket before deleting. In the pop up window, enter permanently delete and click on Empty.

Exercise 2: Identifying Publicly Accessible Data with Compromised AWS API KeysAWS IAM access keys consist of an access key ID and a secret access key that act as long-term credentials for making programmatic calls to AWS CLI.
Lab Scenario
AWS identity and access management (IAM) services can be used for secure access control of resources. The access keys consist of an access key ID and a secret access key and are long-term credentials for making programmatic calls to AWS CLI or AWS API. A secret access key that is included with the API keys is only available for the time at which the cloud administrator created it. This secret access key needs to be stored securely. If the secret keys are lost or if a cloud administrator feels they are stolen, new access keys will have to be created. A cloud security engineer should gather information about the organization’s AWS resources that would be easily available if the access keys fall into the hands of a turncloak, pawn, or imposter.
Lab Objective
This lab will demonstrate how a pentester will gather information about an organization’s AWS resources that would be easily available if the access keys are compromised.
Overview of IAM access keys
AWS IAM services allow a cloud security engineer to implement access control to their resources. Programmatic access to the AWS APIs can be implemented using AWS access keys to confirm user identity. The access keys consist of an access key ID and a secret access key. The secret access keys are only available at the time of their creation. Thus, the secret access keys should be stored securely. In an organization, these access keys will be shared with the users. If they are accidentally leaked from the user or go into the hands of a turncloak or an imposter, certain information on the organization’s AWS resources can be easily accessed by them. Therefore, if the secret keys are lost or stolen, the corresponding user should be deleted and a new user should be created.
Lab Tasks
Note: Web applications in a cloud environment may undergo frequent updates. As we are working on a cloud-based environment for this lab (i.e., AWS), the application interface may be updated with time. Hence, in case you happen to work on an updated version of AWS, the user interface you see on the application might differ from what you see in the lab. Consequently, the steps and screenshots demonstrated in this lab might also differ.
Note: Before starting this lab, you should create an AWS Free Tier account using the following link: https://aws.amazon.com/free, in case you have already not created for the previous module. Once the registration is complete, perform the following tasks:
Note: You can also use any existing AWS account but be aware that it may incur significant charges to your account.

By default Admin machine is selected. Click Ctrl+Alt+Delete

Note: If admin machine is already launched move to step #3. If you are logged into AWS console move to step #9.

By default Admin account is selected, type Pa$$w0rd and press Enter button to login.
To open the browser, double-click on the Google Chrome icon on the desktop.
Type aws.amazon.com in the address bar and press Enter.
The AWS Web Services - Cloud Computing Services page appears. Click on AWS Management Console from the My Account dropdown menu, as shown in the screenshot below.
The AWS Sign-in page appears. Choose Root user and type the AWS administrator account ID (Root user email address), as shown in the screenshot below, and click on Next.
The security check page appears. Type the characters shown in the image and click Submit.
Type the password in the Password field and click on Sign in, as shown in the screenshot below.
To create an IAM user, click on Services. Then, scroll down and click on IAM under Security, Identity, & Compliance under All services.
In the IAM dashboard, click on Users on the left pane under Access management.
Click on Add users at the top.
In the Add user window that opens, configure the following, and click on Next: Permissions at the bottom.
User name: ccseuser
Access type: Programmatic access
In the next window that appears, under Set permissions, click on the third option: Attach existing policies directly.
In the Filter policies search box, type AmazonEC2FullAccess. Then, select the checkbox for AmazonEC2FullAccess.
Click on Next: Tags at the bottom.
In the Add tags window, do not configure anything. Click on Next: Review.
A Review window appears with the configured settings. Verify the configuration and click on Create user.
A user named ccseuser will be successfully created now. Note the Access key ID for ccseuser. Under Secret access key, click on Show to get the secret access key. Note the secret access key and click on Close at the bottom.

Note: Do not close the User created window before noting the Secret access key, as it cannot be accessed later.

Now, you can add ccseuser to a group. In the IAM Dashboard window, click on User groups under Access management in the left pane.
Click on Create group at the top right.
In the User group name field under the Create user group window, enter CloudSecurityEngineer.
Scroll down and select ccseuser under Add users to the group.
Scroll down and search for IAMReadOnlyAccess under Attach permissions policies and press Enter.
Select the checkbox for IAMReadOnlyAccess and click on Create group.
The CloudSecurityEngineer group will be successfully created.
Click on Users in the left pane.
You will see that ccseuser comes under CloudSecurityEngineer.
Now, you will create a Security Group. Click on Services at the top of the AWS console and select EC2 under Compute Engine.
In the left pane of the EC2 console, click on Security Groups under Network & Security.
Click on Create security group at the top right of the EC2 console.
In the Create security group window that appears, configure the following under Basic details:
Security group name: ccsesecuritygroup
Description: Allow access to ccse users
VPC: Default value
Scroll down and click on Add rule under Inbound rules.
Configure the following for Inbound rules:
Type: SSH
Source: 0.0.0.0/0
For Outbound rules, configure the following:
Type: All traffic
Destination: 0.0.0.0/0
Scroll down and click on Create security group.
The security group has been created successfully. Note the Security group ID.
Now, assume the access keys are stolen or used by an insider for performing malicious activities. You, as a cloud security engineer, can collect the information about the AWS resources that are leaked when these access keys are misused.
To do this, you need to install AWS CLI in your Windows VM machine, which can be found in the previous lab (Step 48 -Step 62 ) on identifying misconfigured S3 buckets. If it is already installed, you can continue with the next step.
Search for cmd in the Search section at the bottom task bar of the Windows VM and press Enter.
In the command prompt window, type the following command in cmd to ensure AWS CLI is installed successfully. Then, press Enter.
Note: Alternatively, you can copy the below command from D:\CCSE Lab Commands.htm to the clipboard and paste it into the editor.
aws --version

Note: If AWS CLI is not installed, follow the Steps 48–63 of Lab 1 in this module to install AWS CLI before proceeding to the next step.

Now, type the following command in cmd and press Enter to add compromised user credentials to AWS CLI. This stores the compromised access key credentials in the profile named ccsetest.
Note: Alternatively, you can copy the below command from D:\CCSE Lab Commands.htm to the clipboard and paste it into the editor.
aws configure --profile ccsetest
When running this command, you will have to enter certain values. For each value, configure the following and press Enter.
AWS Access Key ID [None]: (access_key_ID)
AWS Secret Access Key [None]: (secret_access_key)
Default region name [None]: (default_region)
Default output format [None]: json

Note:(Here, replace (access_key_ID) with the access key ID of ccseuser you noted after creating the user, (secret_access_key) with the secret access key of ccseuser you noted, and (default_region) with the name of your default region.)

Now, type the following Security Token Service (STS) command to gather information about the leaked keys and press Enter.
Note: Alternatively, you can copy the below command from D:\CCSE Lab Commands.htm to the clipboard and paste it into the editor.
aws sts get-caller-identity --profile ccsetest
The STS: Get Caller Identity command gathers the user’s User ID, Account ID, and Amazon Resource Name (ARN). Here, the user is named ccseuser.
Type the following command to list the instances in the region (here, the region is us-east-2) and press Enter.

Note: Alternatively, you can copy the below command from D:\CCSE Lab Commands.htm to the clipboard and paste it into the editor.
aws ec2 describe-security-groups --region us-east-2 --profile ccsetest
Note: Replace us-east-2 with your region if you are using a different region

You will get the instances configured in the region us-east-2. This information is available because ccseuser has the AmazonEC2FullAccess policy.
Now, if you run the following command to list the instances of a region that has no instances, you will get an output that follows the command. Here, there is no instance in us-east-1.
Note: Alternatively, you can copy the below command from D:\CCSE Lab Commands.htm to the clipboard and paste it into the editor.
aws ec2 describe-instances --region us-east-1 --profile ccsetest
The output will be { "Reservations": }
Now, type the following command to get information about the security group and press Enter.

Note: Alternatively, you can copy the below command from D:\CCSE Lab Commands.htm to the clipboard and paste it into the editor.
Note: Replace us-east-2 with your region if you are using a different region
aws ec2 describe-security-groups --region us-east-2 --profile ccsetest

You will get the information regarding the configured security groups.
Note: The security groups listed in this screenshot is the default security group
You will get the details of ccsesecuritygroup, that you have created for this lab,including the firewall rules.
Thus, a cloud security engineer can test for AWS resource data that gets leaked because of stolen or leaked access keys and take appropriate security measures to secure their environment.

Note: Ensure you delete, shut down, or terminate all resources created and used in this lab to prevent their billing.

Now, to delete the instances created in this lab, navigate to the Security Groups under EC2 and select the checkbox for the security group you want to delete (here, ccsesecuritygroup). Select the Actions dropdown and click on the Delete security groups option. In the pop-up window, click on the Delete button.
Navigate to User groups under IAM console and select the checkbox of the instance created in this lab (here, CloudSecurityEngineer). Click on the Delete button. In the pop-up window, enter the user group's name and click on Delete.
Navigate to Users under IAM console and select the checkbox of the instance created in this lab (here, ccseuser). Click on the Delete button. In the pop-up window, enter the user's name and click on the Delete button.

CCSE Pentesting the Cloud

Module 06: Penetration Testing in Cloud

CCSE
Pentesting the Cloud