Wiz EKS Challenge
第一关 Secret Seeker
题目描述:Jumpstart your quest by listing all the secrets in the cluster. Can you spot the flag among them?
EKS权限配置如下,可以对secrets进行列举和读取:
1 | { |
根据提示是寻找集群中的secrets资源,通过kubectl get secrets
列出当前 命名空间(namespace) 下的所有 Secret,并使用命令kubectl get secret log-rotate -o jsonpath='{.data.flag}' | base64 --decode
查看即可获得flag。

第二关 Registry Hunt
题目描述:
1 | A thing we learned during our research: always check the container registries. |
EKS配置如下,secrets仅可获取不可列举,pods可列举和读取
1 | { |
先看看有什么pods:

使用命令kubectl get pods database-pod-14f9769b -o yaml
获取该pod的配置信息:

题目要求关注registry,Kubernetes容器注册表(Container Registry)是用于存储和管理Docker镜像的集中化存储库。它允许开发人员构建、保存和传输容器镜像,以供在Kubernetes集群中部署和运行。配置信息里面提到了image镜像地址和拉取进行的secret:

使用secret拉取对应的镜像:
先获取secret,解码得到登录index.docker.io/v1/的账号密码eksclustergames:dckr_pat_YtncV-R85mG7m4lr45iYQj8FuCo

登录认证crane auth login -u eksclustergames -p dckr_pat_YtncV-R85mG7m4lr45iYQj8FuCo index.docker.io
crane pull eksclustergames/base_ext_image 1.tar
tar -xvf 1.tar
tar -xvf ce2d28790c34f433c7675ac64b6e9b9e1524ccdfb8d46eeded43000d832238a0.tar.gz
cat flag.txt
第三关 Image Inquisition
题目描述:
1 | A pod's image holds more than just code. Dive deep into its ECR repository, inspect the image layers, and uncover the hidden secret. |
EKS配置:
1 | { |
提示是在AWS 的pod环境中,且要获得image去寻找secret。
通过获取pod的详细信息,可以看到存在image信息

但因为没有权限,无法获取:

因为是在AWS 的pod中,可以尝试通过有关接口获取凭据。元数据服务是一种提供查询运行中的实例内元数据的服务,在云场景下可以通过元数据进行临时凭证和其他信息的收集,在 AWS 下的元数据地址为:http://169.254.169.254/latest/meta-data
或http://instance-data/latest/meta-data
。此外如果目标配置 了IAM 角色,还可以通过访问元数据的 /iam/security-credentials/<rolename>
路径可以获得目标的临时凭证,进而接管目标服务器控制台账号权限。

这里获取到了aws sts临时凭据,可以使用cli工具来获取image的信息

先获取登录ECR的密码

随后进行登录

登录之后就可以查看镜像的内容了,在此之前需要先找到镜像名称,之后通过crane config查看镜像的信息,在运行记录中发现有flag


第四关 Pod Break
题目描述:
1 | 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? |
权限设置为:{}
提示当前处于EKS集群中一个存在漏洞的pod中,需要获取node的权限来访问服务账户。
由于没有list或者get权限,先尝试收集凭据

获取到的是eks-challenge-cluster-nodegroup-NodeInstanceRole这个角色的凭据,而AWS的role命名有一个规则:<cluster-name>-nodegroup-NodeInstanceRole,因此可以知道cluster-name为eks-challenge-cluster,可以通过get-token来获取集群的凭据:

根据题目提示,这里就可以拿token来获取secret

在 Kubernetes 中,通过 kube-apiserver对集群进行访问,访问需要使用如ServiceAccount 令牌、客户端证书、基本身份验证(用户名和密码)、静态令牌文件等凭据来进行授权验证。AWS EKS使用了Webhook Token Authentication的身份验证,允许外部服务(AWS的EKS使用的是STS)对令牌进行身份验证,并返回与该令牌关联的用户信息。
使用 aws eks get-token
命令AWS CLI 会调用 STS 的 GetCallerIdentity操作并获取一个带有签名的文档,这个带有签名的文档就是你的令牌。当你使用这个令牌与 EKS 集群通信时,EKS 集群会将这个令牌发送给 STS 进行验证,STS 会返回与这个令牌关联的用户信息,所以可以使用这个令牌直接管理集群。
第五关 Container Secrets Infrastructure
题目描述:
1 | 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? |
提示当前已经成功通过有限权限的服务账户获取到了节点服务账户,下一步是从EKS到AWS账户的获取,拿到s3access-sa账户的权限。
IAM策略为:
1 | { |
允许的操作:
- **
s3:GetObject
**:读取对象的内容(下载文件)。 - **
s3:ListBucket
**:列出存储桶中的对象(相当于查看目录列表)。
限制作用的资源:
arn:aws:s3:::challenge-flag-bucket-3ff1ae2
→ 代表整个 S3 存储桶。arn:aws:s3:::challenge-flag-bucket-3ff1ae2/flag
→ 代表桶里特定的对象flag
。
这个策略允许:
- 列出
challenge-flag-bucket-3ff1ae2
桶中的对象(但不一定能访问所有对象)。 - 读取桶里特定的
flag
文件。
也就是说,用户能看到桶里的对象清单,并且可以 下载 flag
文件,但并不能随意访问桶里其他文件(除非也被明确授予 s3:GetObject
权限)。
Trust策略为:
1 | { |
Principal指定了一个 Federated(联合身份)主体:这是你在账号 688655246681
中创建的 EKS OIDC 提供方(IRSA 用到的那个 OIDC Provider)。也就是说:来自这个 OIDC Provider 签发的 Web Identity Token(来自你的 EKS 集群)可以来扮演该角色。
Action说明允许通过 STS 的 AssumeRoleWithWebIdentity API 进行代入(典型 IRSA 流程)。
Condition要求来自该 OIDC 的令牌中,aud(Audience)必须是 sts.amazonaws.com
,这是 IRSA 的标准校验之一,确保该令牌是面向 STS 使用的,而非其他受众。
pod权限为:
1 | { |
**secrets: ["get","list"]
**:允许读取并列出命名空间内的 Secret。拿到 Secret 往往就等于能拿到数据库密码、云凭证、Docker registry token、TLS 私钥等,具备横向&向外部升级的可能。
**serviceaccounts: ["get","list"]
**:允许查看并列出 ServiceAccount(SA)对象(名称、注解、挂载的 secret 引用等)。这为后续“挑选目标 SA”提供信息。
**pods: ["get","list"]
**: 允许查看并列出 Pod(包含它运行所用的 serviceAccountName
、挂载卷、镜像、环境变量)。这能帮助识别“更高权限的 SA 在哪些 Pod 上使用”。
serviceaccounts/token: ["create"]
(子资源): 允许调用 TokenRequest API 为某个 ServiceAccount 签发短期 JWT 令牌(Bound Service Account Token), 这张 token 可直接作为 Bearer Token 调 K8s API,拥有该 SA 的全部权限。
由IAM的策略可知,flag位于arn:aws:s3:::challenge-flag-bucket-3ff1ae2存储桶中,我们需要获取相关IAM权限才能够获得flag。
通过get可以看到没有pods和secrets资源,但是有三个sa:

s3access-sa这个账户的角色拥有S3Role字段,可能拥有对flag的读取权限,所以目标是获取s3access-sa的相关凭据。
Trust策略中提到允许OIDC来通过sts扮演角色,Condition要求来自该 OIDC 的令牌中,aud(Audience)必须是 sts.amazonaws.com
,但并没有更细致的划分,即没有对subject进行检查,这就可能导致了身份扮演滥用的风险。
kubectl create token
可以创建一个新的身份验证令牌,并将其分配给指定的用户或服务账号。这样,用户或服务账号就可以使用该令牌来进行身份验证,并获得相应的权限来执行操作。

可以创建debug-sa的token,但无法创建s3access-sa的token,他们的OIDC均为688655246681,解码也可以看到debug的aud为:oidc.eks.us-west-1.amazonaws.com/id/C062C207C8F50DE4EC24A372FF60E589

符合Trust策略,因此可以让debug-sa来通过sts:AssumeRoleWithWebIdentity来扮演s3access-sa的challengeEksS3Role角色,其中token需要由sts.amazonaws.com颁发。

这样就让debug-sa切换到了s3access-sa的challengeEksS3Role角色,这样就可以获取flag了
