Skip to main content

Challenge 1 - Secret Seeker

Jumpstart your quest by listing all the secrets in the cluster. Can you spot the flag among them?
Permissions

Challenge 2 - Registry Hunt

A thing we learned during our research: always check the container registries. For your convenience, the crane utility is already pre-installed on the machine.
Permissions
We can see the image registry from the output
Crane is already installed in shell we can try to pull the image but we are missing an argument most probably because we are not authorised.
With this cred let’s try to login with crane.
Success! Based on real events We successfully used this technique in both of our engagements with Alibaba Cloud and IBM Cloud to obtain internal container images and to prove unauthorized access to cross-tenant data.

Challenge 3 - Image Inquisition

A pod’s image holds more than just code. Dive deep into its ECR repository, inspect the image layers, and uncover the hidden secret. Remember: You are running inside a compromised EKS pod. For your convenience, the crane utility is already pre-installed on the machine.
Permissions
Lets list out the pods first and check for more information
We can see the image container hosted on AWS ECR. Let’s pull the image using crane.
We start by looking for credentials that can help us connect to the ECR repository. When working in a cloud environment, one way to check for interesting data is to look over the Amazon Metadata Service. Looking at hacktricks and find meta endpoints which are accessible at http://169.254.169.254
We can load these manually onto environment variables and proceed from there
With these credentials we can get authenticated and pull data from ECR.
In this challenge, you retrieved credentials from the Instance Metadata Service (IMDS). Moving forward, these credentials will be readily available in the pod for your ease of use.

Challenge 4 - Pod Break

You’re inside a vulnerable pod on an EKS cluster. Your pod’s service-account has no permissions. Can you navigate your way to access the EKS Node’s privileged service-account? Please be aware: Due to security considerations aimed at safeguarding the CTF infrastructure, the node has restricted permissions
We have absolutely no access to even check the lost of available pods
from the response we can see that the cluster name is eks-challenge-cluster We do not have permission to describe or list the cluster but are able to get a token.
In this task, you’ve acquired the Node’s service account credentials. For future reference, these credentials will be conveniently accessible in the pod for you. Fun fact: The misconfiguration highlighted in this challenge is a common occurrence, and the same technique can be applied to any EKS cluster that doesn’t enforce IMDSv2 hop limit.

Challenge 5 - Container Secrets Infrastructure

IAM role atached to “debug-sa” is challengeTestRole-fc9d18eand “s2access-sa” is challengeEksS3Role Lets create a token for debug-sa
This is a JWT token which we need to decode on jwt.io E1 Avi Lets use this token to assume the role
The above token will still have the default audience of the Kubernetes service. We can change that though with the --audience flag.
From the IAM policy we know the flag is at challenge-flag-bucket-3ff1ae2/flag
Cet3 Avi