Kubernetes 权限提升技术 - 1

“ Kubernetes (K8s) 已成为云原生环境不可或缺的一部分，它提供强大的容器编排功能，使企业能够高效地部署、管理和扩展应用程序。然而，随着 Kubernetes 的普及，其作为攻击者目标的吸引力也日益增强。 ”

在本文中，将与各位读者分享 Kubernetes 权限提升相关的技术。这些技术在ATT&CK中，对应到账户操纵 (T1098) 和有效账户利用 (T1078) ，以及在攻击链中系统 Pod 的潜在滥用方法。

Kubernetes（K8s）权限提升

Kubernetes 中的权限提升是指攻击者在集群内获得未经授权的更高权限访问权限。

在初始访问 (TA0001) 之后，针对 Kubernetes 的攻击通常会先尝试通过凭证访问 (TA0006) 、 权限提升 (TA0004) 或两者的组合来扩大攻击范围。

这可以通过各种手段实现，包括利用错误配置、利用漏洞或滥用过于宽松的基于角色的访问控制 (RBAC) 策略。一旦攻击者提升权限，他们就可能控制整个 Kubernetes 集群、访问敏感数据、破坏关键服务或部署恶意工作负载。

• 账户操纵 ——攻击者会提升其控制的用户或服务的权限或添加其他角色。具体到 Kubernetes，我们观察到攻击者会创建 RoleBinding 或 ClusterRoleBinding，将 Role 或 ClusterRole 绑定到 Kubernetes 账户。此外，如果使用了 Kubernetes 基于属性的访问控制 (ABAC) 授权，则可以通过直接操纵策略来授予其他权限。值得注意的是，对于部署在公有云环境中的 Kubernetes，账户操纵行为已扩展到特定于云的访问服务，例如 AWS IAM、GCP IAM 和 Azure 基于角色的访问控制。
• 有效账户 ——攻击者利用或滥用默认或本地账户来进一步实施攻击活动。对于 Kubernetes 而言，这包括利用默认服务账户的威胁行为者。
• 创建或修改系统进程 —攻击者创建或修改集群管理工具（例如 Docker 和 Podman）或特定于环境的组件（例如 kubelet）。对于 Kubernetes，威胁行为者可以修改 DaemonSet，以便在所有节点（包括后续添加的节点）上部署容器。
• 逃逸至主机 ——攻击者获取相关容器化资源或底层主机的访问权限。在 Kubernetes 环境中，例如，利用特权容器在主机上运行命令，或使用可写的 hostPath 挂载创建具有类似功能的新容器来运行命令或投放有效载荷。
• 利用漏洞提升权限 ——攻击者利用软件漏洞运行自己的代码，以达到提升权限的目的。以 Kubernetes 为例，与流行的自带漏洞驱动程序 (BYOVD) 攻击类似，这种攻击允许攻击者利用漏洞在内核模式下执行代码。eBPF 中的漏洞已被发现允许攻击者以非特权用户身份越界 (OOB) 访问 Linux 内核，这既构成了容器逃逸，也构成了主机权限提升。
• 计划任务/作业 ——攻击者滥用计划任务功能来运行恶意代码。

通过账户操作提升权限

Kubernetes RBAC 是一种关键的安全机制，用于控制集群内资源的访问。 然而，当 RBAC 角色配置错误或权限过高时，它们就会成为攻击者提升权限的首要目标 。

RBAC 的工作原理是通过角色和 ClusterRoles 结构化地控制哪些用户能够对 Kubernetes 资源执行特定操作。

• 角色和 ClusterRoles ：
• 角色 – 角色在特定的命名空间内定义，由指定允许对特定资源执行的操作（动词）的规则组成。例如，一个角色可能允许读取 ( get ) 或修改 ( update ) 命名空间内的 ConfigMap 。
• ClusterRoles – 这些角色与 Role 类似，但在集群级别运行，可以应用于所有命名空间，也可以应用于集群范围内的资源，例如节点或持久卷。ClusterRoles 可以在整个集群范围内授予广泛或细粒度的权限。
• RoleBindings 和 ClusterRoleBindings ：
• 角色绑定 – 将角色与特定命名空间内的一组用户、组或服务帐户关联起来。此绑定授权指定的主体在该命名空间内执行角色中定义的操作。
• ClusterRoleBindings – 通过将 ClusterRole 与用户、组或服务帐户关联，并授予他们跨所有命名空间或集群级别的权限，从而扩展此概念。这允许集中分配适用于整个集群的通用权限。

以下 ClusterRoleBinding，它将 pod-reader ClusterRole 授予 reader-sa 服务帐户：

现在将允许 reader-sa 服务帐户执行 pod-reader ClusterRole 中列出的操作。

在 Kubernetes 中，权限由角色和集群角色中的规则定义，这些规则指定了可对指定 API 组内的资源执行的动词（操作）。

常见的动词包括 get、list、create、update、patch 和 delete。角色和集群角色可以通过服务账户与 Pod 关联，将服务账户绑定到 Pod 即可使其能够在整个集群中执行操作。例如，将 reader-sa 服务账户绑定到 Pod 即可使其能够访问整个集群中的 Pod

从理论到实践

在对 RBAC 有了一定理解之后，我们现在将深入研究如何操纵这些基本组件来入侵 Kubernetes 环境。

攻击者经常利用这些元素在集群内横向移动或提升权限。

攻击者通常会利用权限过高的 RBAC 角色，瞄准那些权限过高或应用范围过广的角色 。

例如，原本旨在提供有限、特定命名空间访问权限的角色可能会被错误地赋予集群范围的权限。

同样，服务帐户也可能被授予了超出实际需要的权限。

因此，攻击者通常会专注于获取具有提升权限的 Pod 或用户的访问权限，以进一步提升访问权限，并获得集群范围的管理控制权。

利用相邻Pod

一种特别隐蔽的方法是利用邻近的 Pod，使攻击者能够从一个 Pod“跳跃”到另一个 Pod，从而获得对集群的未授权访问和控制权。

当攻击者获得对 Kubernetes 环境的未授权访问权限时，他们在集群中的确切落脚点通常难以预测。然而， DaemonSet 的固有特性（旨在确保特定 Pod 在每个节点上运行）使它们不可避免地成为攻击目标 。

这些关键服务对攻击者来说是高价值目标，无论他们从哪里进入集群，都有可能遇到它们。

然而，风险并不止于 DaemonSet。位于同一节点的 Pod（通常称为“相邻 Pod”）也可能被联合利用，从而使攻击者能够提升权限或在集群内横向移动。即使 DaemonSet 本身不受影响，相邻 Pod 的配置或漏洞也可能为具有提升权限的 Pod 提供可利用的路径。

提升权限

为了分析攻击中最常使用和滥用的权限，有必要记录权限范围，从允许升级到集群管理员权限的权限，到在特定场景下可被利用的权限。

为了规范围绕这些权限的讨论，根据其所造成的威胁性质，将其分为四种主要攻击类型：

为了避免过度复杂化，类似的操作和资源已被聚合。

例如， update 和 patch 动词被合并为单个“修改”动词，而各种 Pod 控制器（例如 DaemonSets, Deployments 的权限则统称为“ Pod 管理服务”。这种方法简化了框架，同时准确地反映了这些权限的潜在影响。

攻击类型详解

触发远程代码执行

此类别包含允许在 Pod 或节点内执行任意代码的权限。虽然并非所有 RCE 实例都会导致权限提升，但这些权限允许攻击者控制额外的计算资源或服务，从而显著扩大了攻击面。

攻击场景示例 ：拥有 create pods/exec 权限的攻击者可以在其他 pod 中执行任意命令，利用 kubectl exec 等工具来扩大其影响力并可能危及整个集群的关键服务

获得访问令牌

此类别包含允许攻击者检索或颁发服务帐户令牌的权限，这可能导致 Kubernetes 环境中的未经授权的访问。这些权限的影响很大程度上取决于其范围，尤其是在应用于 kube-system 等高权限命名空间时。如果从具有高权限服务帐户的命名空间获取这些令牌，则会增加风险。

攻击场景示例 ：在特权命名空间中拥有创建 serviceaccounts/token 权限的攻击者可以生成与高权限服务帐户绑定的令牌。这些令牌使攻击者能够冒充这些帐户，获取对关键资源的未授权访问权限，提升其在集群内的权限，并可能危及整个环境。

妥协型访问管理

这些权限允许直接操纵集群的身份验证和授权机制，使其成为旨在提升权限的攻击者的攻击目标。它们可以启用诸如分配角色或冒充其他身份之类的操作，从而有效地授予攻击者对集群的广泛控制权。

攻击场景示例 ：如果攻击者能够 bind clusterrolebindings ，他们就可以将 cluster-admin 角色分配给已泄露的身份，从而获得整个集群的完全管理访问权限。在这种情况下，这些权限是关键的瓶颈，一旦被泄露，可能导致严重的安全漏洞。

Divert Pod 控制

这些权限允许攻击者操纵 Pod 调度，从而有效地将关键 Pod 迁移到受感染的节点。这种技术非常复杂，攻击者需要首先控制集群中的某个节点。

攻击场景示例 ：此技术依赖于操纵 Kubernetes 污染机制来控制 Pod 的调度位置。

• 节点泄露 ——攻击者获得集群内节点的控制权。

• 污点操纵 ——通过向受感染节点添加 NoExecute 污点并向其他节点添加 NoSchedule taint，攻击者可以强制 Kubernetes 驱逐并重新安排目标 pod。

• Pod 重新调度 ——然后将 Pod 重新调度到攻击者控制的节点上，从而使攻击者能够访问敏感资源，例如服务帐户令牌和与被盗 Pod 相关的其他机密。

利用系统 Pod

系统 Pod 是 Kubernetes 集群的骨干，对于网络、资源管理和存储等功能至关重要。与用户部署的 Pod 不同，这些系统 Pod 由云提供商预先安装和管理，通常以提升的权限运行。这种固有的强大功能和预配置特性使其成为一把双刃剑。

用户通常继承这些 Pod，但无法直接控制其配置或权限，这构成了静默威胁。由于这些特权 Pod 拥有固有的强大功能，攻击者越来越多地将其作为提权的入口点，并利用它们作为垫脚石，潜在地入侵整个集群。

错误配置

系统 Pod 中的错误配置在 Kubernetes 环境中构成了一种微妙且经常被低估的安全风险。

其复杂性源于这样一个事实：构成错误配置的因素高度依赖于具体情况。

例如，在一个集群中操作所需的权限或设置，在另一个集群中可能就显得过高或危险，因为这两个集群都继承了相同的系统 Pod。

当不同的系统 Pod 中存在多个配置错误时，风险会变得更大，从而形成一个攻击者可以利用的链条。很多时候，这些链条中的“环节”被忽视或未得到修补。虽然每个“问题”单独来看可能看起来无害，但它们组合在一起，就可能造成一种情况：攻击者一旦进入集群，就可以提升权限，未经授权访问敏感资源，甚至接管整个集群。

为了说明系统 Pod 为何成为攻击者的首要目标，并了解其错误配置带来的风险，下表中总结了主要的系统 Pod 。我们将根据每个系列所拥有的权限、错误配置如何扩大攻击面以及它们为何对攻击者具有吸引力进行评估。

攻击类型详解

在本篇文章中，我们从攻击者的角度探讨了 Kubernetes 中的提权技术，分析了攻击者如何利用 Kubernetes 功能获取未授权的控制权。

我们首先概述了 MITRE ATT&CK 技术，然后深入探讨了攻击者如何利用 RBAC 进一步入侵和提权。

之后，我们将重点转移到系统 Pod——这些拥有提升权限的关键组件对于集群操作至关重要，而这些组件通常出现在攻击链中。

原文始发于微信公众号（WH0secLab）：Kubernetes 权限提升技术 - 1