Git-Sync 遇到麻烦：探讨 Kubernetes 中的命令注入缺陷
执行摘要
Akamai 研究人员 Tomer Peled 在 Kubernetes 的 Sidecar 项目 git-sync 中发现了一个允许潜在命令注入的设计缺陷。他将在 2024 年 DEF CON 大会上披露这些发现结果。
此设计缺陷可能导致 Pod 中的任意文件发生数据外泄（包括服务帐户 令牌）或者使用 git_sync 用户权限执行命令。
要利用此缺陷，攻击者需要在集群上应用 YAML 文件，这是一个低权限操作。
在所有平台的 Kubernetes 默认安装（包括 Amazon Elastic Kubernetes Service (EKS)、Azure Kubernetes Service (AKS)、Google Kubernetes Engine (GKE) 以及 Linode）中，均可以利用此漏洞。
在本博文中，我们将提供 概念验证 (PoC) YAML 文件以及用于说明潜在影响的演示。
由于目前还没有为此设计缺陷分配 CVE，因此也没有针对该缺陷的修补程序，目前该缺陷仍然能够被利用。
Kubernetes 团队支持我们分享此研究成果，以提高大众对这些攻击媒介的认知。
简介
Kubernetes 上的命令注入漏洞可谓屡见不鲜。仅在 2023 年就发现了 7 个类似的漏洞，其中包括多个 我们自行发现的漏洞。对输入清理问题的关注促使我们更深入地研究这些辅助攻击媒介：此攻击媒介是 Kubernetes 主项目所特有的，还是更普遍的存在？Kubernetes 有多个可能存在漏洞的关联 Sidecar 项目，其中就包括 git-sync。
git-sync 项目旨在连接 Pod 与 git 存储库，以便在其站点/服务器之间自动同步更改，这样就无需通过 CI/CD 解决方案来手动进行更改。例如，用户可以使用此功能将其 nginx Pod 关联到某个存储库，该存储库中包含要通过 nginx Pod 公开的文件。
本博文将详细介绍该设计缺陷、Kubernetes 源代码中导致此缺陷的问题，以及一些缓解措施。我们还将说明 Kubernetes 针对发现结果 作出的回应 。
攻击媒介详细信息
通过查看 git-sync 的用法页面，我们发现该命令支持许多可能的配置参数，因此用户可以根据自己的需求来自定义 git-sync。这有可能造成攻击面扩大，导致被攻击者利用（图 1）。
图 1：git-sync 的一些参数
Kubernetes 框架几乎将 YAML 文件用于各个方面，从配置容器网络接口到 Pod 管理，甚至是密钥处理，因此 YAML 中的漏洞极其严重。在本例中，可以创建 Pod 来使用 git-sync 连接到远程存储库（攻击者也可以这样做）。
图 2 是使用 git-sync 部署 Pod 的配置 YAML 文件的示例。
图 2：使用 git-sync 部署 Pod 的配置 YAML 文件
最有可能成为潜在攻击媒介的两个参数是 GITSYNC_GIT 和 GITSYNC_PASSWORD。
根据 git-sync 的公开 文档， GITSYNC_PASSWORD_FILE 指定了一个文件，“系统将从该文件中 读取密码或个人访问令牌（请参阅 github 文档），以用于 git 身份验证（请参阅 --username）”这意味着，Pod 上的 “ accesstoken” 或其他文件有可能发生数据外泄。
GITSYNC_GIT 是（此信息同样源自于 公开文档）“要运行的 git 命令”(根据 PATH 进行搜索，主要用于测试）。此参数默认为 "git"， 这意味着我们可以选择要执行的二进制文件， 而不是 执行 git，然后利用二进制文件在集群上执行代码。
设想的攻击链
利用上述信息，我们开始证明我们的理论。我们认为攻击者会利用几种攻击媒介。
隐秘代码执行
具有集群或命名空间低级权限（创建权限）的攻击者，可以应用一个恶意 YAML 文件，其中包含指向其二进制文件的路径，从而使该文件以 git-sync 的名义执行。
该二进制文件需要位于 Pod 中，而这可以通过多种不同的方法来实现，例如通过 Kubernetes 探测、 Kubernetes 卷或随 git-sync Pod 提供的 LOLBins（图 3）。
图 3：使用 LOLBins 的 YAML 示例
在应用 YAML 文件之后，蓝队人员认为 git-sync 是在与远程服务器通信，因此可以合理地假定它与外部的通信是可以信任的。这样攻击者便可以绕过安全措施，获得命令执行以外的额外好处。
图 4 描述了以 git-sync 用户名义启动 XMrig 加密货币挖矿程序的潜在攻击的 POC。
图 4：潜在 XMRig 加密货币挖矿程序的 PoC
现在，当网络管理员审核现有的 Pod 及其在公司网络外部的通信时，他们很可能看到的是 git-sync 用户在与外部服务器进行通信。
数据外泄
具有编辑权限的攻击者可以编辑 git-sync 部署，以更改或添加 GITSYNC_PASSWORD_FILE 参数，并将该参数指向 Pod 上的任意文件。这会导致 git-sync 在下次连接到 git 存储库时发送该文件作为身份验证方式。
如果攻击者还修改了 git 存储库位置并设置伪存储库服务器，那么在 Pod 中，git-sync 进程的下次部署会将 GITSYNC_PASSWORD_FILE 参数对应的文件从 Pod 发送到攻击者的计算机。 而对于 GITSYNC_PASSWORD_FILE要求的文件路径或权限没有限制。
不难想象，这属于高外泄风险。请考虑下面这种情况：攻击者可以利用此技术检索 Pod 的访问令牌，这样他们就能够以 git-sync Pod 为幌子与集群进行交互（图 5）。
图 5：潜在 GITSYNC_PASSWORD_FILE 攻击的 PoC
信息披露和 Kubernetes 的回应
我们最初向 Kubernetes 团队披露这些发现结果可以回溯到 2023 年 12 月。在与 Kubernetes 团队进行了一些讨论之后，该团队认为 编辑 YAML 被视为一项高权限操作 ，因此我们的发现结果没有超过安全阈值。不过，从我们的角度来看，虽然在 Pod 上执行编辑操作被视为需要特权，但利用这项技术仍有可能实现横向移动。同时我们还担心会损害完整性：攻击者能够伪装成合法的 git-sync 用户来窃取信息。
对于 GITSYNC_GIT，Kubernetes 团队也认可此类操作所需的权限较低，但不认为这种低权限操作会导致任何有害的行为。不过我们认为，所述的设计缺陷使攻击者可以在假冒身份的同时执行命令，而只要攻击者在集群上获得了低级权限，便能够实施有害行为。 对于在集群中使用预授权 git-sync 通信的企业而言，这种攻击流程尤其危险。
考虑到这两种情况，Kubernetes 支持我们在网络上分享这项非常有价值的研究，因为这“有助于提醒管理员谨慎考虑暴露给用户的攻击面。”
缓解措施
由于 Kubernetes 团队认为本博文中描述的攻击技术不是漏洞，因此不会为其发布修补程序。为了减少这些“功能”所带来的攻击面，我们提出了一些可能的缓解措施建议。
首先，加强对企业出站通信的监控，尤其是从 Kubernetes Pod 传出的通信。如果可以对 git-sync Pod 应用此精细监控措施，需要格外谨慎。
其次，我们建议审核 git-sync Pod，查看它们在运行什么命令。此操作可通过以下命令完成：
kubectl describe pod <git-sync-pod>
例如，在图 4 所示的加密货币挖矿程序上执行此命令后，我们可以看到 –git 参数在检测时会发出危险信号，尤其是当参数的值不是“git”时（图 6）。
图 6：在图 4 所示加密货币挖矿程序上执行此审核命令
这种审核方法是很好的常规安全实践，因此我们建议对所有 Pod 执行此命令，而不仅仅是对 git-sync Pod。
我们还编写了 OPA 规则，可用于检测所设想的攻击媒介之一，即攻击者利用恶意有效负载替换 git 二进制文件：
package kubernetes.admission
deny[msg] {
input.request.kind.kind == "<Deployment/Pod>"
path := input.request.object.spec.env.name
contains(path, "GITSYNC_GIT")
msg := sprintf("Gitsync binary parameter detected, possible payload alteration, verify new binary ", [path])
}
结论
在本博文中，我们演示了 Kubernetes 的 Sidecar 项目 git-sync 中的两种攻击媒介。这两种媒介都是缺少输入清理造成的，这凸显处针对用户输入清理采取可靠防御措施的必要性。这些 Kubernetes 清理问题并非 git-sync 所特有，这一点我们 之前 已讨论过。
蓝队成员应注意他们企业中来自于 gitsync 用户的异常行为。我们认为，这些攻击媒介可能会对公司造成巨大的影响；因此对我们而言，提升大众认知并帮助安全管理员了解可能造成的危害非常有必要。
Akamai 安全情报组将继续研究此类威胁，并随时向我们的客户及整个安全社区报告相关情况。如需及时了解我们的最新工作进展， 请关注我们的微信公众号 。
尽管我们对发现结果存在分歧，但还是要感谢 Kubernetes 团队作出回应和披露。
