EKS Cluster Games
The EKS Cluster Games is a cloud security Capture The Flag (CTF) event organize by Wiz with the goal of identifying and and learning about common Amazon EKS security issues
To learn more: https://www.wiz.io/blog/announcing-the-eks-cluster-games
Level 1: Secret Seeker
Permission
Our service account permission
We can see that the service account has list, get permission on secrets, lets try listing it out.
We can see the flag in base64
Flag: wiz_eks_challenge{omg_over_privileged_secret_access}
Reference:
https://cloud.hacktricks.xyz/pentesting-cloud/kubernetes-security/kubernetes-enumeration#get-secrets
Level 2: Registry Hunt
Permissions
Listing the pods
We can see that ImagePullSecrets name is registry-pull-secrets-780bab1d
Based on the kubernetes documentation, we know that ImagePullSecrets ios referencing a secret in the same namespace.
Listing out the secrets, we can retrieve the credentials for the private registry
Decoding the .dockerconfigjson jwt token gives us the authentication token, which can further be decoded to the credentials.
Since crane is pre-installed, we can use crane to authenticate and pull from the docker registry
Based on the documentation, the syntax for crane auth login
To login to index.docker.io, we will use the following command.
Reading the /home/user/.docker/config.json files shows that we have authenticated succesfully.
We are able to then list and pull the docker container tarball
Doing some manual enumeration allows us to retrieve the flag
We can also view the configuration of the image using crane config
Flag: wiz_eks_challenge{nothing_can_be_said_to_be_certain_except_death_taxes_and_the_exisitense_of_misconfigured_imagepullsecret}
Interestingly, this attack path is based on 2 real engagement on Alibaba Cloud and IBM Cloud linked below.
https://www.wiz.io/blog/hells-keychain-supply-chain-attack-in-ibm-cloud-databases-for-postgresql
Reference:
https://cloud.hacktricks.xyz/pentesting-cloud/kubernetes-security/kubernetes-enumeration#get-pods
https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#containers
https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod
https://github.com/google/go-containerregistry/blob/main/cmd/crane/doc/crane.md
https://github.com/google/go-containerregistry/blob/main/cmd/crane/doc/crane_ls.md
https://github.com/google/go-containerregistry/blob/main/cmd/crane/doc/crane_pull.md
Level 3: Image Inquisition
Permission
Doing the same pod enumeration, since we have list and get pods permission
We can see the image container is 688655246681.dkr.ecr.us-west-1.amazonaws.com/central_repo-aaf4a7c@sha256:7486d05d33ecb1c6e1c796d59f63a336cfa8f54a3cbc5abf162f533508dd8b01 which is hosted on AWS ECR.
From the challenge description, we are running inside a compromised EKS Pod, and while in a AWS EKS Pod, we are able to steal the metadata credentials.
Next, we can login using the aws configure command, and then manually setting the session token by modifying the .aws/credentials file.
Next, we confirm if the credentials is configured properly using the aws sts get-caller identity and then perform further enumeration.
Looking at aws ecr cli reference page, I found a few command interesting and decided to perform those enumeration.
Running aws ecr describe-repositories shows that there are 2 image repository within the registry.
Running aws ecr get-authorization-token allows us to retrieve the authorization tokene to login using crane.
And upon base64 decoding, we get the username and the password token. The command aws ecr get-login-password will automatically retrieve the authentication token.
Using the same command from level 2, I was able to login succesfully.
We are able to retrieve the flag from the configuration file again.
Flag: wiz_eks_challenge{the_history_of_container_images_could_reveal_the_secrets_to_the_future}
Reference:
https://hackingthe.cloud/aws/exploitation/ec2-metadata-ssrf/
https://docs.aws.amazon.com/cli/latest/reference/ecr/
https://docs.aws.amazon.com/cli/latest/reference/ecr/describe-repositories.html
https://docs.aws.amazon.com/cli/latest/reference/ecr/get-authorization-token.html
Level 4: Pod Break
Permission
Upon solving level 3 challenge, we are being told that the credentials will be available in the pod for ease of use. However, as I manually modified the .aws/credentials file previously, I will need to retrieve the token from IMDS again and to re-configure with the level4 credentials/
Note that the pod service account has no permission, so we will be looking towards abusing the AWS permission instead.
Looking at the aws cli eks reference page, we found a few interesting commands, namely the describe-cluster, list-cluster and get-token. We do not have permission to run both describe and list cluster, but am able to retrieve a token using get-token
I tried to update the kubeconfig file following this article guide, but was facing some issues. Then, I saw another stackoverflow question to show how to directly use the token with kubectl without configuring the kubeconfig file.
We are able to then retrieve the flag from the secrets.
Flag: wiz_eks_challenge{only_a_real_pro_can_navigate_IMDS_to_EKS_congrats}
Reference:
https://docs.aws.amazon.com/cli/latest/reference/eks/
https://amod-kadam.medium.com/how-does-kubeconfig-works-with-aws-eks-get-token-8a19ff4c5814
https://stackoverflow.com/a/77407767
Level 5: Container Secrets Infrastructure
Based on the description, we will need to pivot from EKS to the AWS account and retrieve a flag from AWS S3 bucket. First, lets take a look at the policy they have given.
Running a kubectl auth can-i --list to see the permission scope properly.
We can see the user has permission on pods, secrets and service accounts, so lets enumerate and find out more.
From the enumeration, we can see there is two service account, namelydebug-sa and s3access-sa. Based on the permission from the kubectl auth can-i --list, we are able to create a service account token for the debug-sa account. Also note the EKS role arn assigned to both service account.
However, we have less permission within the pods using the debug service account, which is also inline with the debug-sa description of being a dummy account.
Based on the trust policy, theres the action of sts:AssumeRoleWithWebIdentity.
Doing some research leads me down to this user guide by AWS. Theres also a section on hacktricks that showcases this technique. So lets try and assume the role based on the policy file above. Note that I will need to renegerate the token according the the trust policy file, where the token audience has to be sts.amazonaws.com
Next, we can authenticate using aws configure with the new credentials and retrieve the flag.
Note that we will need to use --profile default as there are already credentials being set in the environment variable, which will take precendence if we dont call a profile.
Retrieving the flag
Reference:
https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-web-identity.html
Last updated