WIZ EKS Cluster Games CTF WriteUp

type

status

date

slug

summary

Challenge1 - Secret Seeker

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

当前命名空间为 challenge1 ，看看有什么权限

发现能 list 和 get secrets

查看 log-rotate 即可获取 flag（需base64解码）

Challenge2 - 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.

rbac 权限为 list 和 get pod 以及 get secret，命名空间为 challenge2

获取pod 信息

发现使用了镜像 secret registry-pull-secrets-780bab1d

得到镜像仓库认证信息：eksclustergames:dckr_pat_YtncV-R85mG7m4lr45iYQj8FuCo

认证

查看 pod 的镜像得到 flag

💡

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.

Challenge3 - 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.

rbac 权限为 list 和 get pod，命名空间为 challenge3

查看镜像信息发现没权限，这次镜像认证信息不在 pod yaml里

一般是存在 /etc/docker/config.json 或者 ~/.docker/config.json ，但发现没有（如果有是因为上个题目存的

仔细看，发现这次的镜像不是在 docker 中，而是在 aws 里的，这个仓库又是私有仓库，找下文档 Private registry authentication，需要通过 aws ecr get-login-password 获取登录密码，并且需要知道 aws_account_id 以及 region

获取密码，但没有凭据

尝试在元数据里找找，可以找到

region 区域也可以通过 metadata 获取

设置凭证

然后请求即可获得仓库密码

还剩个 aws_account_id ，在官方文档可找到 View Your Account ID using the AWS CLI

得到 Account ID 为 688655246681

最后拼接上，因环境没有 docker-cli，换成 crane 即可

获取 flag

突然发现，原来镜像id的host部分，就是由 <aws_account_id>.dkr.ecr.<region>.amazonaws.com 组成的，就不用特意去找 aws_account_id 和 region 了

💡

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.

Challenge4 - 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

这次的sa没有任何权限

通过枚举一下权限

并没有发现什么有用的权限，

尝试获取 eks token，集群名字根据 arn 命名猜 ->1 、->2

看看这个token的权限

查看一下 sa 和 secret 信息，得到 flag

💡

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.

Challenge5 - Container Secrets Infrastructure

You've successfully transitioned from a limited Service Account to a Node Service Account! Great job. Your next challenge is to move from the EKS to the AWS account. Can you acquire the AWS role of the s3access-sa service account, and get the flag?

题目 IAM Policy

Trust Policy

rbac 权限

存在 sa token 的创建权限

pod 和 secret 都是空的，存在 3个 sa，其中 debug-sa 和 s3access-sa 对应的 arn 定了 iam 角色，应该就是对应题目给的 IAM Policy 和 Trust Policy

EKS 和 IAM的使用和绑定可以见 IAM roles for service accounts ，发现

In 2014, AWS Identity and Access Management added support for federated identities using OpenID Connect (OIDC). This feature allows you to authenticate AWS API calls with supported identity providers and receive a valid OIDC JSON web token (JWT). You can pass this token to the AWS STS AssumeRoleWithWebIdentity API operation and receive IAM temporary role credentials. You can use these credentials to interact with any AWS service, including Amazon S3 and DynamoDB.

也就是说，因为 sa 绑定了 iam 角色，如果他创建的token符合Trust Policy，那么就拥有该Trust Policy 绑定角色的权限，就可以通过 AssumeRoleWithWebIdentity 模拟请求了，不过我们创建不了 s3access-sa 的 sa token，只能创建 debug-sa 的

注意 create token 需要加上 --audience 参数，因为 Trust Poliay 有做校验

解码得到

iss 部分和 Trust Policy 主体是一样的，模拟角色请求

设置这个 token 再去请求 s3 即可

即可得到 flag

Certificate