This Sunday, I had the opportunity to participate in AWS Community Day Nepal, and it was an amazing experience filled with engaging talks and events. One of the highlights was the Capture the Flag competition, where I participated and secured the first place. Below are some writeups of the challenges I tackled during the event.
Escape your vessel
The challenge description included a link. Upon opening it, I was greeted with a basic web interface. .
Inspecting the source code and checking for common files or directories like /admin and robots.txt yielded no results. So, I decided to fuzz the web server for hidden endpoints.
Using a common wordlist, I found two endpoints: /health and /hi.
/health: This endpoint returned a generic message stating "Site is up"—nothing particularly useful.
/hi: This endpoint returned an interesting response—"Method not allowed."
After some investigation, I discovered that only POST and OPTIONS methods were accepted on the hi endpoint. I tried various POST parameters, but they all returned the following error. To narrow down the valid parameter, I decided to use fuzzing again. I leveraged a tool called Arjun, which scans for potential GET and POST parameters. After running Arjun, I got the breakthrough I needed.
To narrow down the valid parameter, I decided to use fuzzing again. I made useof a tool called Arjun, which scans for potential GET and POST parameters. After running Arjun, I got the parameter I was looking for command.
Due to the obvious name I tried running basic Linux commands and confirmed that we had command execution.
Looking around, I realized that I was inside a docker container.
Since the challenge was named Escape your vessel I figured that the flag was in the host machine rather than in the container. So I started to check for hints to access the host machine. First I thought we might get sensitive information by quering to the AWS meta data IP i.e. http://169.254.169.254/ but it did not lead to anywhere. Then I started to look if any volume has been mounted from our host machine. Looking around I found out that /host was mounted to / of host machine. That gave me access to the host’s filesystem.
Once, I had access to the files of host machine, it was a matter of moment before I got the flag. For this, first I checked the .bash_history file of the users i.e root and ubuntu in our case. Looking at ubuntu's history, I found some juicy information
With the information found in the bash history, I read the file that was located at /var/log/flag.txt
Pwned the Bucket
The challenge description provided a URL http://ctf.csaju.com/ which showed the following:
Initially, I assumed the S3 bucket might be named ctf.csaju.com, as AWS bucket names often follow domain-like structures which was wrong. To identify the correct bucket, I used nslookup to query the canonical name (CNAME) associated with ctf.csaju.com. The DNS resolution indicated that the domain was pointing to an AWS S3 bucket via a CNAME record, which revealed the actual bucket name: awscommunitydayctf.
Upon confirming that the bucket name, I proceeded to enumerate its contents using the AWS CLI. By running the command aws s3 ls s3://awscommunitydayctf/, I confirmed that the bucket was fully exposed.
So, I went ahead and downloaded all the content of the bucket to my machine.
Looking around I found the flag at pdf/main.inc
Mistaken Image
In this challenge, a link to the Github repo was given which contained the text r4s1p1w2/awscloudclubnepal in the README.md file.
The challenge hinted about ECR in its description. So I directly started to check if it was a publicly accessible ECR image. I navigated to gallery.ecr.aws and checked for awscloudclubnepal as a public repository. And to no one’s surprise, it was indeed a publicly available image.
Once I located the publicly available container,hen I pulled the docker image to my local machine
docker pull public.ecr.aws/r4s1p1w2/awscloudclubnepal:latest
After I pulled the image, it was fairly simple enough to get inside the docker container and grab the flag located at /flag/flag.txt
Balti
The challenge description provied an Android app and hinted about reverse engineering the app to find something useful.
So, I downloaded the android apk provided in the challenge description and ran it through JADX decompiler. Poking and looking around, I stumbled accross this file at com.example.oggybhai/aws.java which seem to contain AWS access key and secret key.
On my local machine I setup the AWS CLI with the found credentials and checked if the creds were working with the following command. This revealed that indeed, the credentials were working and the username of the account was mobile
➜ awsctf aws sts get-caller-identity
{
"UserId": "AIDAUGO4KMZB4PGSYXVZZ",
"Account": "288761734723",
"Arn": "arn:aws:iam::288761734723:user/mobile"
}
Since the challenge was named Balti which means bucket in Nepali, I looked if there were any buckets available.
➜ awsctf aws s3 ls
An error occurred (AccessDenied) when calling the ListBuckets operation: User: arn:aws:iam::288761734723:user/mobile is not authorized to perform: s3:ListAllMyBuckets because no identity-based policy allows the s3:ListAllMyBuckets action
Seeing that access to list bucket was not available, I checked what policies this account was attached to.
➜ awsctf aws iam list-attached-user-policies --user-name mobile
{
"AttachedPolicies": [
{
"PolicyName": "oggy_bhai",
"PolicyArn": "arn:aws:iam::288761734723:policy/oggy_bhai"
},
{
"PolicyName": "IAMReadOnlyAccess",
"PolicyArn": "arn:aws:iam::aws:policy/IAMReadOnlyAccess"
}
]
}
The first policy seemed interesting. So I digged deeper to check the contents of the policy.
➜ aws iam get-policy-version --policy-arn arn:aws:iam::288761734723:policy/oggy_bhai --version-id v11
{
"PolicyVersion": {
"Document": {
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSpecificBucketActions",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::oggyandcockroachesbucket",
"arn:aws:s3:::oggyandcockroachesbucket/*"
]
},
{
"Sid": "AllowIAMPolicyReadAccess",
"Effect": "Allow",
"Action": [
"iam:GetPolicy",
"iam:GetPolicyVersion"
],
"Resource": "arn:aws:iam::288761734723:policy/oggy_bhai"
}
]
},
"VersionId": "v11",
"IsDefaultVersion": true,
"CreateDate": "2024-09-27T11:11:45+00:00"
}
}
Looking at the policy, I found out that the account mobile had permissions to view and download contents of the S3 bucket oggyandcockroachesbucket. So I checked the mentioned bucket contents and found a file oggy.txt. Wrapping the text in flag format, I submitted the flag successfully.
➜ aws s3 ls s3://oggyandcockroachesbucket
2024-09-19 15:15:14 17 oggy.txt
➜ aws s3 sync s3://oggyandcockroachesbucket .
download: s3://oggyandcockroachesbucket/oggy.txt to ./oggy.txt
➜ cat oggy.txt
tLgxjcbrlmkAoYdR
Serverless
The following Github repository was linked in the challenge description
Checking the commit history of the repo, we find an interesting commit message
First I thought it was some base64 encoded text but on closer inspection I found it to be access id and secret token of an AWS ac. So I updated my AWS CLI credentials to include it and ran some commands to verify it.
Once the credentials was setup, I directly started looking at lambda functions as the challenge was named serverless. Upon enumerating all the lambda functions available, I found flag in the environment variable section of description of Lambda function called EnvBreaches
➜ aws lambda list-functions --region ap-south-1
{
"Functions": [
{
"FunctionName": "EnvBreaches",
"FunctionArn": "arn:aws:lambda:ap-south-1:288761734723:function:EnvBreaches",
"Runtime": "python3.10",
"Role": "arn:aws:iam::288761734723:role/service-role/EnvBreaches-role-9b68sucr",
"Handler": "lambda_function.lambda_handler",
"CodeSize": 420,
"Description": "A starter AWS Lambda function.",
"Timeout": 3,
"MemorySize": 128,
"LastModified": "2024-09-24T11:26:41.000+0000",
"CodeSha256": "v1xwIoDXIUeuD0DlTfWkCCHYaQpg/RAtlvvfc1IfpV4=",
"Version": "$LATEST",
"Environment": {
"Variables": {
"SECRET_KEY": "CTF{wow_congrats}"
}
},
"TracingConfig": {
"Mode": "PassThrough"
},
Exposed Volume
The main event site was given in the challenge description i.e.https://awscloudclubnepal.com. Checking the robots.txt in the main website, I found the following contents
What I found suspicious was the last entry i.e. #backup: snap-0cfd61c21e57c8138. This looked like a snapshot id of EBS volume. To confirm my suspicions, I opened my AWS account and started the search for the given snapshot id and my guess was correct. There was a valid snapshot with the given id.
So the next step was to create a volume using the snapshot.
Once the volume was created, I thought of launching a new EC2 instance and attaching our new created volume to check its contents.
So I very quickly created a ubuntu EC2 instance.
Then I went and attached our volume we created using snapshot to the EC2 instance.
After attaching the volume to our EC2 instance, I created a mount directory and mounted the volume. Looking at the contents inside the volume, I found a file called flag.txt which contained the flag.
Overall, AWS Community Day Nepal was a fantastic experience that not only enhanced my technical skills but also allowed me to connect with like-minded individuals in the community. The Capture the Flag event was challenging and rewarding, and I'm looking forward to more such opportunities in the future. Kudos to everyone involved at the event.