打开潘多拉魔盒 - 开源项目中的供应链内部威胁

文章探讨了开源项目中的内部威胁，特别关注了如何防范恶意 Git 标签注入攻击。文章指出，开源项目虽然倡导透明度和协作，但仍然需要面对内部威胁的挑战。深蓝平台详细解释了AWS Karpenter项目的一个漏洞，展示了恶意标签注入攻击的实际案例，并提出了应对内部威胁的建议。

在文章中，作者提到授予数十个贡献者写入权限的决定可能存在风险，并强调了严格的分支和标签保护、代码审查等措施的重要性。他们利用实际案例展示了如何通过注入恶意 Git 标签实现远程代码执行（RCE），并提出了一系列限制和考虑因素，以及加强权限控制的方法。

TL;DR：在开源项目中授予存储库“写入”访问权限是一个高风险的决定。我们深入研究了内部威胁的风险，使用AWS Karpenter 项目的负责任披露来证明为什么严格的保护措施至关重要 - 分支和标签保护、代码审查，尤其是围绕发布工件发布的控制。此外，GitHub 可能缺乏审计功能来帮助发现某些情况下的妥协指标 (IoC)。  

信任，但要验证：做好准备

传统的信息安全模型通常通过在公司机密和公共信息之间定义明确的界限来解决内部威胁。相比之下，开源项目拥护透明度和协作。然而，这并不能消除内部威胁。该项目的声誉及其软件工件的完整性仍然是重要的资产。作为核心维护者，授予数十个（甚至数百个）贡献者“写入”权限需要仔细考虑风险。职责划分仍然至关重要——识别特权行为并将其限制于选定的合作者子集。

负责任的披露打开了潘多拉魔盒

正如我们在上一篇文章中提到的，我们喜欢探究我们在自己的供应链中消耗的依赖项，这使我们在 2023 年 11 月达到了Karpenter的顶峰，这是一个由 AWS 启动和主要维护的开源项目，有助于动态配置计算Kubernetes 集群中的资源。鉴于其在 Kubernetes 中的特权角色，Karpenter 需要高度的信任。正如我们所讨论的，我们拥有大规模的数据基础设施，可以帮助我们大规模识别开源包中的供应链问题。一旦我们确定了某个漏洞类别，我们就可以快速发现其他项目中的所有类似问题。在这种情况下，我们首先查看项目中的工作流程，很快就出现了一个奇怪的工作流程注入案例。不过，很明显，这仅与内部漏洞有关。

“人生就像CTF”

看到这个工作流程注入，我立刻想起了夺旗（CTF）玩家中曾经听到过的一句话：“生活就像一场 CTF”。有时，漏洞似乎几乎是为了挑战安全分析师而设计的。在本例中，面临的挑战是制作一个可以推送到 GitHub.com 的恶意 Git 标签。成功利用该漏洞需要在工作流程步骤的限制内通过 Git 标签注入有效的 JavaScript，最终导致不受约束的 RCE。奖项？通过存储库写入权限访问 GITHUB_TOKEN，并能够通过滥用授予 AWS ECR 注册表访问权限的真实 OIDC 声明来篡改 Karpenter Helm Charts 版本。

制作第一个 POC

限制和考虑因素

标签长度：恶意制作的 Git 标签必须保持在 255 个字符以下（包括refs/tags/），并且在这种情况下，以语义版本格式 ( v*.*.* ) 开头。

字符限制：标准 Git 标签仅限于字母数字字符、连字符、下划线和句点。这可以防止直接使用漏洞利用中常见的许多特殊字符。

只是一个 POC

这是注入标签的上下文：

const result = await github.rest.pulls.create({  title: 'chore: Release ${ {steps.tag.outputs.TAG }}',   owner,  repo,  head: 'release-${ {steps.tag.outputs.TAG}}',  base: 'main',  body: [    'Stable Release Changes for ${ { steps.tag.outputs.TAG }}.',    'Please disregard this PR if it is for a patch release.',    'Please remove the branch after merging.',    'This PR is generated by [StableRelease](https://github.com/aws/karpenter/actions/workflows/stable-release.yml).'  ].join('n')});

首先，我们需要用单引号转义 JavaScript 字符串。标签中通常避免使用单引号 (') 以及其他特殊字符，例如空格、双引号 (") 和不可打印字符，但是，Git 本身并没有在技术层面严格强制执行这些命名约定。

让我们首先验证这是否有效：

$  git tag "v1.2.3'+console.log(333)+'"$  git push origin "v1.2.3'+console.log(333)+'"

是的，我们有 RCE！继续。

提升权限

真正的目标是任意远程代码执行（RCE）。在这种情况下，例如，RCE 将允许我们使用aws CLI（已存在于 GitHub Actions 运行程序上），并直接从工作流程通过 OIDC ( id-token: write )新获取的临时 AWS ECR 凭证中受益在注射点之前。

为了简化我们的漏洞利用开发，我们添加一些脚本来生成随机标签并使用 Base64 编码。这使我们能够绕过标签内的字符限制：

https://gist.github.com/fproulx-boostsecurity/90f07cd2987f63901d39b3ec51bea7c7 

完整的开发链

如前所述，此工作流程利用 OIDC 来访问 AWS ECR 注册表。尽管我们没有测试完整的漏洞利用，但根据对 GitHub Actions 日志的审查，我们确信威胁行为者可能已经这样做了。

想象一下，一个民族国家的参与者通过持续的贡献随着时间的推移赢得了维护者的信任。凭借写入权限，他们可以自由创建、推送并立即删除恶意 Git 标签（除非存在标签保护规则）。然后，他们可以通过删除 GitHub Actions 日志进行清理，留下最少的痕迹。对于企业中的许多经典内部威胁来说也是如此。

妥协指标 (IoC)

• GitHub 公共事件：可能会发现恶意标签创建/突变/删除（例如https://api.github.com/repos/aws/karpenter-provider-aws/events）

• 审核日志：

• 删除工作流运行（日志）将留下workflows.delete_worklow_run 事件。

• 另一方面，篡改发布工件（添加、更新、删除）不会留下任何审核日志事件。 

经验丰富的攻击者肯定会使用多阶段有效负载，其中恶意标签获取包含真正恶意有效负载的辅助脚本。更令人担忧的是，GitHub 发布工件可以使用基本写入访问权限（GITHUB_TOKEN在我们的披露中拥有权限 - 即内容：write ）进行篡改。这给 Homebrew Taps、Terraform 模块、 goreleaser和其他依赖 GitHub 发布工件完整性的项目带来了严重的风险。有趣的是，将 cosign 无密钥签名与 Fulcio 透明日志结合使用可能有助于发现奇怪的标签。