深入探索 EKS 安全之后渗透提权与维持-先知社区

深入探索 EKS 安全之后渗透提权与维持

前言

在云原生环境中，Amazon Elastic Kubernetes Service（EKS）为企业提供了强大的容器编排能力，但其复杂的权限管理和多层安全机制也为攻击者提供了潜在的突破口。

在后渗透阶段我们如何提权和维持呢，详细的操作我们跟着靶机一起探索

**文章中涉及的敏感信息均已做打码处理，文章仅做经验分享用途，切勿当真，未授权的攻击属于非法行为！文章中敏感信息均已做多层打码处理。传播、利用本文章所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，作者不为此承担任何责任，一旦造成后果请自行承担。**

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?

您正在 EKS 集群上一个易受攻击的 pod 中。您的 pod 的服务帐户没有权限。您能通过导航访问 EKS 节点的权限服务帐户吗？

简单来说就是提权

基础思路和过程

可以看见我们是没有什么权限的

但是可以使用aws的部分命令

简单分析一下获取的信息

主要分析

Arn (Amazon Resource Name)

提供了关于当前身份的详细信息：

●

Partition

aws

代表该资源属于 AWS 公共云。

●

Service

sts

代表该 ARN 是通过 AWS 的

Security Token Service (STS)

获取的，意味着该身份是临时的。

●

Account

688655246681

对应的账户 ID，如上所述。

●

Resource Type

assumed-role

表示当前身份是通过角色（IAM Role）假设而来的。

●

Role Name

eks-challenge-cluster-nodegroup-NodeInstanceRole

，这是当前身份的 IAM 角色名称，它是一个与 Amazon EKS (Elastic Kubernetes Service) 集群相关的角色。该角色可能被用于与 Kubernetes 集群通信、管理集群节点等操作。

●

Instance ID

i-0cb922c6673973282

，这是当前 AWS EC2 实例的 ID。说明该身份是在一个 EC2 实例上运行的角色（通过 EC2 Instance Profile 获得）。

下面是具体的分析

IAM 角色

当前身份基于名为

eks-challenge-cluster-nodegroup-NodeInstanceRole

的角色。这个 IAM 角色可能具有与 Amazon EKS 集群及相关资源交互的权限。例如，可能用于管理节点组、处理 pod 安全策略，或者访问 AWS ECR（Elastic Container Registry）镜像。

STS

当前角色是通过 AWS STS（安全令牌服务）来假设的，这意味着该实例通过临时凭证访问 AWS 资源。临时凭证可以有权限限制和到期时间限制，常用于短期任务或会话管理。

EC2 实例角色

当前角色被分配给了 EC2 实例

i-0cb922c6673973282

。这表明该实例可能是一个 Amazon EKS 节点，它通过该 IAM 角色与 AWS 资源（如 EKS 集群、ECR、S3 等）进行交互。

隐含权限

基于当前角色名，我们可以推测它被分配了与 EKS 节点相关的权限，比如从 ECR 拉取容器镜像、管理 Kubernetes 工作负载、访问相关的 IAM 和网络资源等。你可以通过

aws iam get-role

命令进一步查看该角色的具体权限。

通过名称eks-challenge-cluster-nodegroup-NodeInstanceRole

我们可以分析出

eks-challenge-cluster

这个部分表明该角色与一个名为

eks-challenge-cluster

的 EKS 集群相关联，通常用于执行与该 EKS 集群的操作。因为EKS 集群中的 EC2 节点通常需要与控制平面、Kubernetes API Server 和 AWS 服务进行交互，这需要 IAM 角色来授予它们相应的权限。

NodeInstanceRole这一部分表明这是一个

EC2 实例角色

，并且它是专门为 EKS 集群中的

节点组 (Node Group)

配置的 IAM 角色。

Assumed-role

这一字段表明这个 IAM 角色是通过 STS（安全令牌服务）被 EC2 实例假设的。

我们是没有Kubernetes 权限的，不过有aws权限，因为aws经常需要和 kubectl 交互

这里利用刚刚提到的隐藏权限，看看我们这个IAM的权限

没有权限，尝试其他办法

这里有两个方法

更新

kubeconfig

文件

在 AWS EKS 集群中，

kubeconfig

文件是 Kubernetes 客户端与集群通信的关键配置文件。通过方法一，你可以在

kubeconfig

中配置 AWS 认证信息，并获取高权限的 Kubernetes 集群访问权限。

kubeconfig

文件中会包含以下关键信息：

●

API Server 地址

：指向 Kubernetes API 的 URL。

●

认证信息

：比如用户名、密码、令牌或者执行认证命令来获取临时的认证令牌。

●

上下文信息

：确定当前使用的集群、用户等。

通过

kubeconfig

文件，Kubernetes 的

kubectl

工具可以知道应该如何认证、与哪个集群通信，以及使用哪个上下文环境。

对于 EKS 集群，可以通过

exec

模式来动态获取身份认证令牌。exec 模式会调用一个外部命令（如

aws eks get-token

），以临时生成一个访问 Kubernetes 集群的令牌。

简单来说比如

command: aws

：告诉 Kubernetes 使用

aws eks get-token

来获取集群认证令牌。

args

：指定要执行的参数，包括区域、集群名称等。

env

：通过设置 AWS 凭据（

AWS_ACCESS_KEY_ID

、

AWS_SECRET_ACCESS_KEY

和

AWS_SESSION_TOKEN

），使得 AWS CLI 能够认证你为合法的 IAM 用户。

配置了这些之后通过

kubectl

发出请求时，

kubeconfig

会触发 AWS CLI 调用

aws eks get-token

，获取一个临时的访问令牌并将其传递给 Kubernetes API Server，用于认证。

获取高权限token

这个方法更为简单

只需要知道集群名称，而刚刚已经知道了

获取到token之后就可以使用高权限的token再次去访问以前不能访问的api了

可以看到权限已经提升很多了

然后查看secret

成功读到flag

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?

您已成功从有限服务帐户过渡到节点服务帐户！干得好下一个挑战是从 EKS 迁移到 AWS 账户。你能获得 s3access-sa 服务帐户的 AWS 角色并获得标记吗？

权限分析

首先看一下权限

IAM

简单解释一下

Principal

是身份联合的实体，也就是允许执行此操作的对象。

Principal

使用了

Federated

字段，表明角色授权给了一个外部身份提供者（OIDC）

ARN 指向了一个具体的 OIDC 提供者，

oidc.eks.us-west-1.amazonaws.com

是 Amazon EKS 集群的 OIDC 提供者 URL，后面的 ID 是该提供者的唯一标识。

Condition

部分是可选的，用于进一步限制策略的应用条件。在这个策略中，使用了

StringEquals

条件来指定某些字符串值必须匹配。

oidc.eks.us-west-1.amazonaws.com/id/C062C207C8F50DE4EC24A372FF60E589:aud": "sts.amazonaws.com"

这里的条件表示，只有当 OIDC 提供者的 audience 字段等于

"sts.amazonaws.com"

时，身份联合才会被允许。这是为了确保 OIDC 提供者发送的请求是 AWS STS 接受的请求。

这个在后面是会使用到的

Action

●

"s3:GetObject"

: 允许从存储桶中获取对象（下载文件），在这个情况下，具体是允许读取 S3 桶中的对象，比如

flag

文件。

●

"s3:ListBucket"

: 允许列出 S3 存储桶中的对象（查看存储桶的文件列表）。

Resource

●

"arn:aws:s3:::challenge-flag-bucket-3ff1ae2"

: 这是指向整个 S3 存储桶的 ARN，允许列出桶中的文件。

●

"arn:aws:s3:::challenge-flag-bucket-3ff1ae2/flag"

: 这是桶中的具体对象（

flag

文件）的 ARN，允许获取该对象。

应该就是我们要读存储桶的flag了

RBAC 权限

可以创建serviceaccounts

ServiceAccount

是一种特殊的身份标识机制，用于将应用程序与云资源进行身份关联。

权限提升

首先尝试看看能不能列出存储桶的对象内容

没有权限

因为可以创建token

我们需要拿到一个更高权限的 aws 凭证来访问存储桶。

这里看看有哪些用户

因为题目描述了是s3access-sa用户，尝试为他创建token

显示没有权限，尝试为其他用户创建，不过这里需要注意一个小细节，就是前面的对我们的用户做了限制

只有当 OIDC 提供者的 audience 字段等于

"sts.amazonaws.com"

时，身份联合才会被允许。

我们创建sd的时候指定一下字段

只需要通过--audience 指定

获取了token之后我们就可以尝试获取伪造其他用户的凭证了

理解为伪造高权限用户

这是一个 AWS STS（Security Token Service）的命令，它允许通过

Web Identity Federation

扮演一个 IAM 角色，并返回临时的安全凭证（临时的

AccessKeyId

、

SecretAccessKey

和

SessionToken

）。这些凭证可以用来访问 AWS 资源，基于 IAM 角色所分配的权限。

然后有一些选项，

--role-arn

: 这是你想要扮演的 IAM 角色的 Amazon Resource Name (ARN)

--role-session-name

: 这是会话的名称

--web-identity-token

: 就是token值

所以我们可以伪造高权限角色

查询一下高权限角色的arn

可以看到为challengeEksS3Role

我们就伪造这个

然后就是设置环境变量

然后我们尝试读取内容

因为根目录没有写的权限，写到tmp目录就ok了

得到最后的flag