This is will be a brief walkthrough of the flaws.cloud ctf scenarios, flaws.cloud is a vulnerable AWS cloud environment. It is perfect to show cloud security misconfigurations and practical exploitability ,giving a glimpse into cloud penetration testing.
The ctf is in levels each showing a different attack scenarios ranging from open buckets, IAM misconfigurations, Instance Metadata service(IMDS) and more nuanced scenarios, all build on top of the previous attack
Level 1
vulnerability is bucket is accessible to everyone for the first challenge, start off simple with a dns lookup using dig
then complete an nslookup to do a reverse dns lookup to get the corresponding domain name,Its hosted on an s3 bucket
add flaws.cloud to the domain name, It resolves back to the main page. since its an s3 bucket, it is possible to list content for the next stage(the vulnerability).
Assuming aws cli is installed we can be able list the content
see anything interesting, use that to go to the next level
Level 2
Vulnerability is content accessible to all authenticated users, this can be an issue as all authenticated users technically could mean any aws user who is authenticated even though its not their bucket content they are accessing
To complete the challenge, create an IAM user on aws and create a profile with the aws cli(CLI creds)
if we list the bucket using the configured profile, we get the following files, find the flag :
we move to Level 3:
Level 3 :
Vulnerability is all users and issue of leaked credentials, similar in some ways to level 2 navigating to the bucket url, we can see .git/config files
for further investigation, we can download the contents of the bucket and comb further
configure the profile with the creds found
with the new profile lets look around
with the files found we can go
Level 4
vulnerability is publicly accessible ec2 snapshot
Level 4, vulnerability is publicly accessible ec2 snapshot, the roles we found will play a key role
we then create a volume using the snapshot which we will use to later
from the volume created we can now create an instance
then ssh into the instance,
lets try listing the content of our volume:
we have to mount the drive to be able to list content:
now we browse around until we get something interesting like credentials
in the /mnt/home/ubuntu, we find an interesting file setupNginx.sh with creds
we can use the creds to complete the challange
Level 5 :
Vulnerabilty is Metadata service, instance metadata service(IMDS) and its flaws or rather misconfigurations.
Meta-data, data about data or in this instance data about this ec2 instance, used for management and configuration of a running instance, however this exploited
To learn more on AWS metadata service, the good the bad and downright well bad, read this article by checkpoint https://blog.checkpoint.com/security/aws-instance-metadata-service-imds-best-practices/
Get credentials here to be able to list the contents of the level 6 sub-directory
we then go to one of the listed urls and find our way(we can list creds… flaw in IMDS v1) append 169.254.169.254 which is the link-local IP address for IMDS for AWS and follow the journey
and you will get creds at
create a profile with those credentials
now that we have the credentials lets try listing the contents of level 6 sub directory
if listing is possible we can find the file append and move to Level 6
Level 6:
Vulnerability is the overly permissive IAM user
we start off level 6 with credentials and SecurityAudit policy attached
create a profile
since the creds have secaud. policies i brought in scoutsuite(effective open-source security auditing tool for cloud). This is however a rabbit hole. I will do another blog on sec tools for cloud later
observe the username , we will then list the policies attached to Level6
“list_apigateways” seems interesting
use resource ARN to list
the policy is using “apigateway:GET” on the “arn:aws:apigateway:us-west-2::/restapis/* which can allow us to list rest APIs
we can use that to list all lambda functions
a single function
we can list its policies
this shows that the principal can execute/InvokeFunction on the “arn:aws:execute-api:us-west-2:975426262029:s33ppypa75/*/GET/level6\” resource
lets view the s33ppypa75 rest-api-id :
we see the stage name is “Prod” which are lamda functions using the rest-api-id, stage name, region and resource, we can call them/invoke or rather this one using
`https://s33ppypa75.execute-api.us-west-2.amazonaws.com/Prod/level6
and finally we finish;
The End
This was a great box, it challenged my knowledge and skills, Totally recommend for anyone to gain a deeper understanding on why or how exactly certain aws security breaches happen.
On to flaws2.cloud.
