GitHub Actions 供应链攻击分析

原文地址：https://unit42.paloaltonetworks.com/github-actions-supply-chain-attack/

执行摘要

3 月 20 日更新： GitHub 操作tj-actions/changed-files和reviewdog组织内的其他操作最近遭到入侵，引起了 GitHub 社区的关注，标志着又一次重大软件供应链攻击。我们的团队对这起事件进行了深入调查，发现了有关攻击发生方式和时间线的更多细节。这些攻击者入侵了数千个存储库的持续集成/持续交付 (CI/CD) 管道，使其面临风险。

我们的团队还发现，最初的攻击目标是 Coinbase。有效载荷专注于利用他们的一个开源项目 agentkit 的公共 CI/CD 流程， 可能是为了利用它来进一步攻击。然而，攻击者无法使用 Coinbase 机密或发布软件包。

我们相信，在这次初次攻击之后，同一个攻击者又发起了更大规模的攻击，该攻击自此引起了全球的广泛关注。我们的调查还显示，攻击者在报告浮出水面的几天前就开始准备，最终影响了tj-actions/changed-files的特定版本，并使大量存储库面临风险。

此事件凸显了攻击者如何滥用第三方行为或依赖关系来破坏软件供应链，可能导致未经授权的访问、数据泄露和代码篡改。

攻击概述

GitHub Actions是一个 CI/CD 平台，可帮助用户自动化其开发流程。单个 GitHub 操作可以成为其他流程可以利用的可重复使用的工作流组件。tj -actions/changed-files GitHub 操作最近遭到入侵，攻击者可借此访问依赖于此操作的敏感工作流机密。从数字上看，超过 23,000 个 GitHub 存储库使用了此 GitHub 操作。

2025 年 3 月 14 日，安全研究人员首次发现了该入侵行为，当时检测到该行为引发了可疑活动。攻击者注入了一个有效载荷，该载荷转储了 CI/CD 运行程序的内存，将敏感的环境变量和机密直接暴露给工作流日志。

Adnan Khan 提供的线索表明， tj-actions/changed-files操作的入侵源于对另一个 GitHub 组织仓库的入侵：reviewdog/action-setup。我们现在可以确认tj-actions/changed-files被入侵是因为它使用了tj-actions/eslint-changed-files操作，而该操作又依赖reviewdog/action-setup。进一步调查发现，reviewdog组织的其他操作也被劫持。当您阅读本文时， tj-actions和reviewdog的维护者都已采取必要的安全措施，并减轻了威胁。

建议的缓解措施

我们的建议侧重于从受感染的tj-actions/changed-files操作以及属于reviewdog组织的操作的消费者的角度来采取检测和预防步骤。社区应该从这些操作及其托管存储库的受感染中吸取教训。

以下详细的缓解措施和建议措施包括针对受影响用户的紧急措施，例如：

• 识别用途

• 查看工作流日志以识别泄露的令牌和机密

• 轮换机密

• 调查恶意活动

我们还分享了与此问题相关的长期安全改进方法，以及有关Palo Alto Networks 云安全产品如何帮助防范此类安全风险和类似安全风险的信息。

如果您认为自己可能已受到威胁或有紧急问题，请联系第 42 单元事件响应团队。

相关单元 42 主题	供应链, GitHub

攻击流程概述

首先：我们来谈谈 tj-actions 和 reviewdog

2025 年 3 月 10 日至 3 月 14 日期间，攻击者成功将恶意提交推送到tj-actions/changed-files GitHub 存储库。此提交包含图 1 所示的 Base64 编码的有效负载，它将 CI 运行器内存中存在的所有凭据打印到工作流日志中。

图 1. 引入tj-actions/changed-files的恶意代码片段

攻击者能够使用之前获得的具有写入权限的 GitHub 令牌将恶意提交 ( 0e58ed8 ) 添加到存储库。攻击者伪装提交，使其看起来像是由合法用户renovate[bot]创建的。

然后，该提交被添加到由真正的renovate[bot]打开的合法拉取请求中，并按照此工作流程的配置自动合并。这些步骤使攻击者能够感染存储库，而不会检测到活动。一旦提交被合并，攻击者就会将新的 git 标签推送到存储库以覆盖其现有标签，使它们全部指向存储库中的恶意提交。

从那个入侵点开始，攻击者影响了每个依赖于tj-actions/changed-files操作的 GitHub 工作流程运行。

2025 年 3 月 14 日， StepSecurity 的研究人员发现了针对tj-actions/changed-files 的攻击，并将此事件报告给了tj-actions组织的维护人员。事件详细信息发布后，GitHub 社区立即开始修补工作流程和存储库以缓解攻击。

3 月 16 日，Adnan Khan分享了他的研究成果，指出了另一个 GitHub 组织reviewdog遭到入侵的情况。Adnan 推测，在最初的入侵中，攻击者利用了tj-actions/changed-files存储库中配置的工作流程，该工作流程使用了属于同一组织的另一个操作：tj-actions/eslint-changed-files。

反过来，tj-actions/eslint-changed-files操作直接依赖于reviewdog/action-setup操作，并在运行时将其用作复合操作。这意味着tj-actions/eslint-changed-files操作的使用者在运行后就会受到损害，因为此操作会自动执行驻留在受损reviewdog/action-setup操作中的恶意代码。

当执行tj-actions/eslint-changed-files操作时， tj-actions/changed-files CI 运行器的机密被泄露，从而允许攻击者窃取运行器中使用的凭据，包括属于tj-bot-actions GitHub 用户帐户的个人访问令牌 (PAT) 。

Adnan 随后分享了他在reviewdog/action-setup : f0d342中发现的可疑提交的详细信息。

Adnan 还指出， reviewdog使用了一种自动邀请机制。该机制会自动邀请为reviewdog组织做出贡献的 GitHub 用户加入其中，并授予他们对其存储库的写权限。reviewdog 的维护者后来也承认，这种机制确实可能是攻击者进入reviewdog组织的入口点。

从我们对reviewdog/action-setup的检查来看，我们发现f0d342提交是由攻击者引入到存储库的 — 很可能是攻击tj-actions 的同一攻击者。但是，通过更多信息以及reviewdog维护者haya14busa的帮助，我们能够确定实际推送的是 git 标签 — 而不是提交。

总结我们目前收集到的信息，我们可以得出以下结论：

• 一个具有reviewdog组织写权限的令牌被泄露（或者可能是贡献者叛变），并且该令牌被用来破坏上面提到的两个tj-actions存储库。

• 由于tj-actions/changed-files依赖于reviewdog/action-setup，我们可以假设reviewdog在tj-actions之前就被破解了。

在下一节中，我们将阐明攻击者用来向这些存储库引入隐秘提交的技术，并详细说明随后的影响。

深入分析

虽然最初的和随后的妥协乍一看似乎很相似，但它们还是存在一些差异。

在tj-actions/changed-files感染中，我们发现攻击者通过“合法”拉取请求感染了index.js文件。为了感染此文件，攻击者必须拥有对存储库具有写入权限的令牌。没有这个，他们将无法推送模拟的提交（0e58ed8）。

我们现在知道，他们利用之前感染reviewdog/action-setup获得的 PAT 获得了这种能力，而这反过来又毒害了tj-actions/changed-files的工作流程。除了拉取请求渗透之外，攻击者还使用令牌更新了tj-actions/changed-files存储库的现有 git 标签，使所有标签都指向恶意的0e58ed8提交。

这最终导致在任何GitHub 操作或使用此操作的工作流的 CI 运行器中执行代码，并通过其中一个标签引用它。

我们假设，尽管攻击者拥有对存储库具有写权限的 GitHub 令牌，但他们更喜欢通过在有效的拉取请求中模仿有效用户来掩盖他们的恶意提交——这种技术称为“提交模仿”。

这种模仿技术十多年前就已公开。您可以在此存储库中找到有关它的更多信息。

在最初的感染中，我们在reviewdog/action-setup上观察到，虽然没有拉取请求渗透或明显的恶意提交，但进行了一次更新，导致 git 标签指向恶意提交（再次感谢haya14busa！）。这再次暗示攻击者已经获得了具有此存储库写入权限的 GitHub 令牌。

这个有根据的假设仍然给我们留下了一些重要的问题：

• 恶意提交是如何引入reviewdog/action-setup存储库的？

• 如果我们找不到任何分支或拉取请求的痕迹，那么它们是从哪里来的呢？

GitHub fork 是一种常见的版本控制系统 (VCS) 功能，在世界范围内被广泛用于合法目的，但也可能被用于阴暗的用途。

用户在 GitHub 中 fork 一个仓库后，可以向该仓库添加自己的提交。这些提交会被添加到“ fork 网络”，并且可以从原始仓库中进行引用。

浏览这些提交时，它们会出现在原始存储库中，但显示悬空提交警告（图 2）。

图 2. reviewdog/action-setup存储库中的悬而未决的提交

这意味着恶意行为者可以滥用分叉功能，将任意提交引入可分叉的 GitHub 存储库，即使攻击者没有写入权限。更有趣的是，如果删除此类分叉，并且不知道分叉的确切提交 SHA 值，则这些提交将无法追踪，也无法识别。

基于这些事实，我们开始怀疑这次攻击与分叉有关。深入调查表明，我们的怀疑是正确的。

当我们查找任一受感染存储库的分支时，我们无法检测到任何可疑实例。这表明 GitHub 删除这些实例是因为它们涉及恶意活动，或者发生了其他事情。

为了解决这个难题，我们利用了自定义工具和功能，并发现了以下问题：

• 2025-03-11 17:06:12 (UTC)，名为iLrmKCu86tjwp8的用户分叉了reviewdog/action-setup存储库。当我们寻找该用户时，发现它已经消失，不再存在于 GitHub 中。这立即引起了我们的怀疑。

• 在他们的 fork 中，我们发现该用户推送了 13 个包含各种有效载荷的提交。其中一些与reviewdog/action-setup中提交0e58ed8中发现的恶意有效载荷相同，而另一些则是“清理”提交，例如8d73381。

我们还看到该用户于 2025-03-11 17:21:52 (UTC) 分叉了reviewdog/action-typos存储库，并推送了另外 15 个包含各种有效负载的提交。但是，由于该用户已被删除，我们无法直接访问该分叉及其提交。

这是我们能够利用 fork 网络功能的地方。假设攻击者创建了一个 fork，我们就知道他们的提交应该可以在reviewdog的存储库下找到 — —事实确实如此。

本文末尾的“感染指标”部分提供了用户在其 fork 中创建的所有提交的列表，以便稍后感染原始存储库。

在检查提交时，我们发现攻击者准备了reviewdog/action-setup的感染，并且还准备了reviewdog/action-typos来指向恶意提交。

感染本身包含图 3 中所示的代码片段的变体，用于在执行运行器脚本时收集受害者凭证。

图 3. reviewdog/action-setup存储库中的恶意代码片段

除了这一发现之外，从reviewdog的日志中，我们了解到攻击者推送了新的标签来指向恶意提交。这让我们想知道攻击者为什么会使用这种方法，我们很快就意识到了以下几点。推送到 GitHub 的“Git 标签”更改不会记录在使用 GitHub 免费套餐的组织和存储库的 GitHub 审计日志中。

这意味着，通过使用来自已删除分支的“影子提交”并推送未保存在审计日志中的 git 标签，攻击者几乎可以完全逃避检测。

以下几点总结了我们对reviewdog感染的分析：

• 攻击者的准备工作于 2025 年 3 月 11 日 17:06:12（UTC）开始，三天后才被发现

• 攻击者非常了解分叉功能，并且知道他们可以使用来自存储库合法代码库中的分叉的提交

• 攻击者使用具有写入权限的令牌将 git 标签推送到存储库，并通过 fork 方法引入提交而不被发现

既然我们现在知道恶意提交是通过分叉引入到reviewdog存储库的，那么我们面临另一个问题：为什么我们看不到它们的痕迹？

尽管我们对上述结论相当有信心，但本节仍将是一个 GitHub 可以确认或反驳的假设。

我们认为，iLrmKCu86tjwp8用户注册时使用了“合法”电子邮件，就像标准 GitHub 用户一样。后来，在引入影子提交后，用户将此电子邮件更改为GitHub 政策不允许的一次性/匿名电子邮件。

在这种情况下，GitHub 会标记该帐户并将其隐藏起来。这包括隐藏用户在 GitHub 平台上执行的每一个交互和操作。

我们假设用户执行此电子邮件更改是为了让 GitHub“清理”他们的痕迹和帐户，从而使追踪他们的行为和身份变得更加困难。

当我们寻找tj-actions/changed-files的分支时，我们发现了另外两个可疑用户：

• 2ft2dKo28UazTZ

• 穆沃伊维普

这两个账户也被从 GitHub 上删除。

当我们检查2ft2dKo28UazTZ用户的行为时，我们发现虽然它分叉了tj-actions/changed-files，但使用方式有所不同。与iLrmKCu86tjwp8用户不同，2ft2dKo28UazTZ被用来测试 git 标签的创建和删除。即v39和v47，如图 4 所示。

图 4. 2ft2dKo28UazTZ用户正在尝试创建 git 标签

虽然我们知道攻击者最终覆盖了tj-actions/changed-files的所有 git 标签，但我们注意到，在这里，攻击者针对了两个特定的 git 标签：

• 第 39 章

• v47

已识别的第三个用户mmvojwip也分叉了tj-actions/changed-files，但未以任何方式与其分叉进行交互。

为了在继续之前理清思路，我们来总结一下最后两部分：

1. 攻击者使用三个虚拟账户进行准备和测试：iLrmKCu86tjwp8、2ft2dKo28UazTZ和mmvojwip

2. 在使用这些账户后，我们假设攻击者让 GitHub“标记”他们的账户并清理他们的痕迹

当我们搜索2ft2dKo28UazTZ和mmvojwip用户执行的活动时，我们注意到他们创建了以下分支：

• 2025-03-12 15:28:44 → 2ft2dKo28UazTZ分叉coinbase/onchainkit

• 2025-03-12 15:29:04 → 2ft2dKo28UazTZ分叉coinbase/agentkit

• 2025-03-12 15:32:02 → 2ft2dKo28UazTZ分叉coinbase/x402

• 2025-03-13 20:36:02 → mmvojwip分叉coinbase/agentkit

• 2025-03-13 21:04:58 → mmvojwip再次分叉coinbase/agentkit

我们继续观察，发现这两个用户都对coinbase/agentkit的分支进行了更改，但没有对其他两个存储库进行更改，因此我们将重点放在了coinbase/agentkit上。在发现攻击者在对tj-actions/changed-files进行大规模攻击之前就分叉了这些存储库后，我们怀疑 Coinbase 可能是该活动的实际目标（或目标之一）。

当我们浏览coinbase/agentkit存储库时，我们发现它是一个“可轻松让 AI 代理在链上采取行动的框架”。

当我们进一步检查2ft2dKo28UazTZ在coinbase/agentkit分支中的活动时，我们发现它主要从自己的分支向自身创建拉取请求。它正在更新.github/workflows/changelog.yml文件或尝试发布nightly-20250311标签。

当我们查看coinbase/agentkit时，我们没有发现nightly-20250311标签中有任何被攻陷的迹象，但奇怪的是，我们发现changelog.yml文件实际上已被维护者于 3 月 14 日删除。虽然它已被删除，但我们可以看到工作流引用了tj-actions/changed-files的v39，这与攻击者在自己的分支中摆弄的标签完全相同。这也加强了我们对攻击者瞄准 Coinbase 的怀疑。

正如在初始攻击中观察到的那样，这些提交是通过分叉引入到存储库的，这意味着我们可以在coinbase/agentkit存储库中看到它们。在识别这些提交后，我们发现在2ft2dKo28UazTZ的coinbase/agentkit分叉的整个更改过程中，他们将tj-actions/changed-files的引用更新并替换为以下 SHA 值之一：

• fbc2c5ebe64389f297a7808025379f77133f1292

• e1e36574b3af1ddaab74f5e69505d8836bf12f52

• ce4a123414f9fffa959d1f329c4749da83c4bf10

• c17ac4b5c1cb901a7ccddf00ac9722b8e2725345

当我们尝试访问tj-actions/changed-files中的这些 SHA 时，我们遇到了死胡同：它们已被全部删除。

2ft2dKo28UazTZ用户的完整提交列表可以在下面的妥协指标部分中找到。

至此，我们知道：

• 2ft2dKo28UazTZ尝试修改coinbase/agentkit中changelog.yml文件（使用tj-actions/changed-files的v39 版本），并测试创建nightly-20250311标签

• 合法维护者或持有泄露令牌的参与者从coinbase/agentkit存储库中删除了changelog.yml文件

由于我们没有找到2ft2dKo28UazTZ用户的任何其他开放结局，因此我们转向找到的第三个用户。

在调查的这个阶段，我们开始调查mmvojwip用户的行为，同时通过 GitHub API获取coinbase/agentkit中changelog.yml工作流的已删除工作流日志。

按照与初始入侵中描述的方式，用户创建了一个包含其更改的分支。

完整的提交列表在“妥协指标”部分提供，但特别突出的是三个提交：

1. coinbase / agentkit - 提交 8edc60f

2. coinbase / agentkit - 提交 b3a1c72

3. coinbase / agentkit - 提交 b39e2d4

所有这些提交都将tj-actions/changed-files的引用更改为 SHA 6e6023c01918b353229af0881232f601a4cc8365或从 SHA 6e6023c01918b353229af0881232f601a4cc8365 更改。当我们访问该提交时，我们看到它是另一个悬空提交，如图 5 所示。这一次，它冒充（或滥用）了github-actions[bot]。

图 5. tj-actions/changed-files中新发现的冒充恶意提交

值得注意的是，此时，攻击者对tj-actions/changed-files存储库具有写权限，并且可以推送任意提交或分支，冒充任何用户并保持不被发现。

当我们查看此提交的有效载荷时，我们发现了一个尚未透露的有效载荷。此有效载荷演示了参与者、tj-actions/changed-files和coinbase/agentkit之间的连接，如图 6 所示。

图 6. tj-actions/changed-files存储库中的恶意提交，针对coinbase/agentkit

此提交中的详细信息证明攻击者正在专门寻找 Coinbase 存储库。

此时，我们联系了 Coinbase，并开始在coinbase/agentkit的工作流日志中搜索提交内容，以查看他们的工作流是否提取了恶意 SHA。不久之后，我们就找到了答案，如图 7 所示。

图 7. coinbase/agentkit提取并执行针对 Coinbase 的恶意 SHA

我们还发现，此工作流程是在存储库中使用写入全部权限执行的，允许执行敏感操作，可能允许将恶意代码引入coinbase/agentkit存储库的代码库。

此时，我们可以陈述以下内容：

• 攻击者发起了针对 Coinbase 的攻击活动

• 攻击者于 2025 年 3 月 14 日 15:10 UTC 获得了具有对coinbase/agentkit存储库写入权限的 GitHub 令牌，这距离针对tj-actions/changed-files发起更大规模攻击不到两小时

• 我们不知道其他组织是否也遭遇了同样的攻击

• 我们尚未确定coinbase/agentkit中的changelog.yml文件被删除是否是由于令牌被盗用，或者维护者是否由于安全报告而删除了此工作流程

• 虽然有效载荷收集了敏感信息，但据我们所知，它们不包含通常与恶意行为者相关的更严重的操作，例如远程代码执行或反向 Shell 操作

3 月 19 日 18:28，我们向删除了changelog.yml工作流程的 Coinbase 维护人员发送了电子邮件，以确定维护人员是否主动删除了该工作流程，以及他们是否知道泄漏的情况。

到 19:15，维护人员回复说，他们确实根据安全报告删除了工作流程，并已经修复了攻击。

随后，我们与 Coinbase 分享了更多我们发现的细节，Coinbase 表示，此次攻击未能对agentkit项目或任何其他 Coinbase 资产造成任何损害。

受影响的存储库

为了直观地展示此次攻击的潜在影响，我们为reviewdog/action-setup构建了一个操作依赖树，这是此次事件的核心。为了创建图 8 所示的树，我们搜索了所有依赖于reviewdog/action-setup 的操作，以及那些依赖于依赖操作的操作，递归搜索至三级。

每个节点代表一个动作。最内圈的动作都直接依赖于reviewdog/action-setup作为复合动作，或者间接地在其工作流程中使用它。

每个节点内都有许多直接依赖于该操作的存储库（操作和工作流）。图 8 还包括每个级别的依赖存储库总数。

这些是整个攻击活动中可能受影响的存储库和项目。随着更多存储库受到影响，每个级别都会显著扩大。

实际受抚养人数要高得多，因为：

• 图中仅包含公共存储库

• 由于搜索限制，结果不完整

• 不包括没有公共依赖的行为

该图是在攻击发生几天后创建的，因此不包含已删除易受攻击操作的项目。这表明攻击时的影响更大。

图 8.Actions 依赖树显示 Coinbase 依赖于出现在第二级的tj-actions/changed-files 。

我们团队在之前的研究中展示了利用 GitHub Actions 依赖链的概念。

迄今为止我们对此次袭击的了解的结论和总结

虽然 Coinbase 的响应有效地补救了针对其自身组织的攻击，但社区尚未确定其他组织是否也受到了有针对性的攻击，或者该活动的整体情况是否还有其他方面。

仍有几个悬而未决的问题，例如：

• 引发对tj-actions造成广泛影响的攻击者的动机

• reviewdog/action-setup的 token 是如何泄露的

• 最初有针对性的攻击演变成大规模、隐蔽性较差的行动的原因

• 攻击者打印日志而不是采取更具破坏性的行动的原因

下面，我们根据调查提供了完整的时间线，以及我们在研究期间确定的三个用户所做的完整提交列表。

我们要赞扬 Coinbase 的安全措施，以及他们在我们研究过程中对我们的调查的配合。Coinbase 还展示了对事件的快速响应，并在短时间内实施了缓解措施。

我们还要感谢tj-actions和reviewdog的维护人员对我们调查的帮助。

活动时间表

此时间表基于现有信息。所有时间均为 UTC+0。

日期：2025 年 3 月 11 日
时间	行动
17:06:12	由iLrmKCu86tjwp8创建的reviewdog/actions-setup分支，设置和准备
17:21:52	由iLrmKCu86tjwp8创建的reviewdog/actions-typos分支，设置和准备
18:17:20	用户iLrmKCu86tjwp8与reviewdog/actions-setup fork的最后一次互动记录
18:17:53	用户iLrmKCu86tjwp8与reviewdog/actions-typos fork的最后一次互动记录
18:42:09	将reviewdog/actions-setup中的“v1”标签推送到b833eecdf13c615cd60d5dede6f6593a4b3b4376 （恶意）
20:31:49	在reviewdog/actions-setup中强制将“v1”标签推送到3f401fe1d58fe77e10d665ab713057375e39b887 （清理）
日期：2025 年 3 月 12 日
时间	行动
15:28:44	2ft2dKo28UazTZ分叉coinbase/onchainkit，无需采取任何进一步行动
15:29:04	由2ft2dKo28UazTZ分叉coinbase/agentkit ，随后进行设置和准备
15:32:02	2ft2dKo28UazTZ分叉coinbase/x402 ，无需采取任何进一步行动
16:54:44	由2ft2dKo28UazTZ创建的tj-actions/changed-files分支，随后进行设置和准备
日期：2025 年 3 月 13 日
时间	行动
02:08:59	2ft2dKo28UazTZ与tj-actions/changed-files分支的最后一次互动记录
17:55:11	2ft2dKo28UazTZ与coinbase/agentkit分叉的最后一次互动
20:36:02	mmvojwip分叉coinbase/agentkit ，然后进行设置和准备
日期：2025 年 3 月 14 日
时间	行动
13:49:00	mmvojwip与coinbase/agentkit分叉的最新互动记录
15:10:00	Coinbase 执行恶意版本的tj-actions/changed-files并泄露具有写入权限的令牌
16:37:00	Coinbase 维护者从存储库中删除了coinbase/agentkit的易受攻击的工作流程
16:57:00	在tj-actions/changed-files中推送事件，将所有标签替换为恶意提交

攻击指标

用户 iLrmKCu86tjwp8 所做的提交：

1. https://github.com/reviewdog/action-setup/commit/0f176b316e1d41a945e574fc2ba76b0dc752d585

2. https://github.com/reviewdog/action-setup/commit/96be5a72d8adac89200e08658f69273912fe4783

3. https://github.com/reviewdog/action-setup/commit/61902a2b3c982d3551ad219bb0ff22f3663e44de

4. https://github.com/reviewdog/action-setup/commit/f966d8d897bc8033657b8e77da56a988029ce8c7

5. https://github.com/reviewdog/action-setup/commit/909ace6b17fc4045030e55f5ac27ca99f276ae80

6. https://github.com/reviewdog/action-setup/commit/454c8a19a12cde77505464d7e4549500c8ac68d0

7. https://github.com/reviewdog/action-setup/commit/04d5b6d4c18c06d7df6edabf914d0ded986c3a87

8. https://github.com/reviewdog/action-setup/commit/81796e43b6348d628e3e739a910d50704a5292c1

9. https://github.com/reviewdog/action-setup/commit/8d73381aa1c2ccd12c8ddcfefa47aeb1443e67e3

10. https://github.com/reviewdog/action-setup/commit/c27af8180030e1f3d0434473731f030dc1849edf

11. https://github.com/reviewdog/action-setup/commit/efa6ce46bcaa8751ad223e44be7977798c909304

12. https://github.com/reviewdog/action-setup/commit/143a52c0d919c1a69bdeafeab564650f6939a2b3

13. https://github.com/reviewdog/action-setup/commit/31b1df0e735ad8511fd7df3be8cf9351d8cb4de7

1. https://github.com/reviewdog/action-typos/commit/26f36301be817815fbcb896d2c85e89f04b17df4

2. https://github.com/reviewdog/action-typos/commit/9bb460e92befdbb6506d2e643ae06c8b50205f97

3. https://github.com/reviewdog/action-typos/commit/75b5741c6bd9de9815741a40a41844598d409e7b

4. https://github.com/reviewdog/action-typos/commit/f33bbbbf1282af26b285a9a131e0bd43ca355e79

5. https://github.com/reviewdog/action-typos/commit/3a06be07e9c02ee1c5fede46928b6031d8d2383c

6. https://github.com/reviewdog/action-typos/commit/6db74f2d6b0600b8e38cf24b18fda283217e5ffb

7. https://github.com/reviewdog/action-typos/commit/1d10399139bd16e69ed2b7dbfda38735ea1cf324

8. https://github.com/reviewdog/action-typos/commit/3b9482055ba84ea8761eed6b3b9ecf9e79692a55

9. https://github.com/reviewdog/action-typos/commit/6c7b129ed2bbb59ed684c3847a587f4f4e94eaf8

10. https://github.com/reviewdog/action-typos/commit/cb6e155e9dec580de71f0fe89f832d2d9932997b

11. https://github.com/reviewdog/action-typos/commit/eb183376a83bdc6ecfc8168b22ffa6e2b1a9cb6e

12. https://github.com/reviewdog/action-typos/commit/5db6a72f3984e847a2a7d2a25169ca5e849798da

13. https://github.com/reviewdog/action-typos/commit/16c5092f4eb672004001d9bcdc0cf693fb76c1b4

14. https://github.com/reviewdog/action-typos/commit/1368857b9c9a47ba08727409ae9fbdeeba8a590a

15. https://github.com/reviewdog/action-typos/commit/48fbacf68b808429af544d0d7ebd90a5b4cec642

用户 2ft2dKo28UazTZ 所做的提交

1. https://github.com/coinbase/agentkit/commit/0723a75a67a1de4b1b1c6cd66a8cab551023fc30

2. https://github.com/coinbase/agentkit/commit/868213ddd4dad8b24a3cb716a6ccc9f89e10d087

3. https://github.com/coinbase/agentkit/commit/8a269616e225e93b8f74d0eb4a86be041a493a76

4. https://github.com/coinbase/agentkit/commit/0723a75a67a1de4b1b1c6cd66a8cab551023fc30

5. https://github.com/coinbase/agentkit/commit/71f4822157821d0998d4a0f8e9e849cdcce9bdd2

6. https://github.com/coinbase/agentkit/commit/18b3e737f9449d94d73fad0bca718ba677676ac7

7. https://github.com/coinbase/agentkit/commit/7a7432e65a8666e4b04695f7c1ef03dfca75ad0b

8. https://github.com/coinbase/agentkit/commit/1ca37970d73ee40c173725de97fc8696aac93aa1

9. https://github.com/coinbase/agentkit/commit/bbbb1c63ceae1e7fb40054bb763f407dc200b37d

10. https://github.com/coinbase/agentkit/commit/2161165ec14fcb9d985970c353e17e84794fd694

11. https://github.com/coinbase/agentkit/commit/823bd75199f474ea7abdbe3a5debf9825c490156

12. https://github.com/coinbase/agentkit/commit/9cefe659a770b8d32ffe5f08f44de6456d9592af

13. https://github.com/coinbase/agentkit/commit/c00af6911bf03512d130462b6b7fe6a286f7ec98

用户 mmvojwip 所做的提交

1. https://github.com/coinbase/agentkit/commit/8edc60f030035f377780f421431a7ac66828253d

2. https://github.com/coinbase/agentkit/commit/b3a1c722b2aed7fa3e373fb04861826a7a00d0aa

3. https://github.com/coinbase/agentkit/commit/db25249e859d0259011a2f820ec75b5d1047c99b

4. https://github.com/coinbase/agentkit/commit/b39e2d4c31bc786b3a93ea832da887debfee1fc1

5. https://github.com/coinbase/agentkit/commit/a3bbd802082446e36b8976de78a7727e71638e36

6. https://github.com/coinbase/agentkit/commit/faf8d9d8b35369541d38f8d087d71e92cbeadd6b

缓解措施和建议措施

受影响用户的紧急措施

• 识别用途：在您的存储库中搜索tj-actions/changed-files操作和上面提到的其他操作，以确定它是否已被使用以及在何处使用。

• 查看工作流日志：检查过去的工作流程，寻找以 Base64 文本双重编码的秘密暴露证据，尤其是在日志公开的情况下。

• 轮换机密：撤销并重新生成可能已暴露的任何凭据。确保所有 API 密钥、访问令牌和部署凭据都已刷新。

• 调查恶意活动：如果您发现任何迹象表明已执行了受损操作，请进一步调查是否有任何恶意活动的迹象。

长期安全改进

• 管理正在使用的第三方服务：实施审查程序，以确保外部行动在集成到工作流程之前获得批准。

• 实施严格的基于管道的访问控制 (PBAC)：将授予 GitHub Actions 工作流的权限减少到必要的最低限度。使用细粒度和短期令牌，而不是长期和广泛范围的机密。

• 固定 GitHub 操作：不要通过标签或分支 (例如@v3或@main ) 引用 GitHub 操作，而是将操作固定到全长提交 SHA-1 哈希，以确保代码不会被恶意行为者更改。

要了解有关保护版本控制系统 (VCS) 和 CI/CD 系统的更多信息，我们建议您联系OWASP Top 10 CI/CD 安全风险项目。

tj -actions/changed-files漏洞凸显了 CI/CD 管道固有的风险以及第三方依赖项带来的风险。随着攻击者越来越多地瞄准这些环境以快速访问生产资产，组织在将外部工具纳入其工作流程时必须采取安全第一的方法。

通过实施严格的安全措施可以显著降低供应链遭受攻击的可能性，例如：

• 固定依赖项

• 使用经过验证的操作

• 采用 PBAC

团队必须优先考虑安全性并采取主动措施来保护其自动化管道免受潜在威胁。

Palo Alto Networks 保护和缓解措施

对于现有客户，Prisma Cloud 可识别其管道中执行的可执行文件和 GitHub 操作。该产品可识别组织使用的工具，使客户能够轻松找到是否存在易受攻击的操作以及在哪些管道中使用。客户还可以实施开箱即用的策略来防范相关风险，如下所述。

随着客户从 Prisma Cloud 升级到 Cortex Cloud，他们可以从所有现有的保护中受益，这些保护增强了用户允许或限制在其管道中运行的工具的使用，以及跟踪禁止工具的部署的能力——如下图 9 所示。

图 9. 识别 Cortex Cloud 中所有恶意 Github Action 的用途。

通过旨在识别 CI/CD 环境中的脆弱区域的各种开箱即用策略，客户可以帮助防止未来类似的攻击，并减少潜在漏洞的影响。

面向 Palo Alto Networks 客户的相关现成 CI/CD 策略

Palo Alto Networks 客户应在其环境中参考以下政策，并根据每项政策中提供的建议缓解问题。

• 取消固定的 GitHub 操作：取消固定的 GitHub 操作是可变的。这允许攻击者将恶意版本的tj-actions/changed-files操作推送为现有标签，从而引入可在消费者管道中执行的中毒代码 - 即使攻击者没有更改标签的版本。如果执行了受感染的版本，任何使用此操作的取消固定版本的消费者都可能容易受到此恶意代码执行的影响。

• 允许在存储库/整个组织中不受限制地使用 GitHub 操作：允许在存储库中使用所有 GitHub 操作（无论其作者是谁）会使组织面临恶意行为者控制操作存储库的风险，就像最近的违规行为一样。GitHub 允许将允许的操作仅限于企业操作，从而阻止执行外部操作。

• GitHub 操作管道对存储库的权限过多：执行管道时，GitHub 会创建一个短暂的GITHUB_TOKEN以与存储库交互。如果在管道的 YAML 文件中未定义授予GITHUB_TOKEN的权限，则管道的默认权限将设置为所有范围的读写（旧存储库中的默认设置）或读取存储库内容，而不考虑工作流程的具体要求。

另一个安全隐患是，在管道中定义了全部读取或全部写入权限时，这会授予所有范围内的GITHUB_TOKEN权限。由于GITHUB_TOKEN在攻击中从内存中泄露，因此，以过多权限访问 GitHub Actions 管道的攻击者可以充分利用并利用宽容的GITHUB_TOKEN。

• GitHub Actions 使用不安全的长期凭证访问云提供商：用于 GitHub Actions 工作流程向云提供商帐户进行身份验证的长期凭证以机密形式存储在 GitHub 上。这增加了凭证盗窃的影响，因为被盗凭证可以在工作流程运行完成后很长时间内使用。

GitHub 支持 OpenID Connect (OIDC) 身份验证协议，以使用短期访问令牌取代长期凭证。使用 OIDC，GitHub Actions 工作流程可以直接从云提供商处请求短期令牌；工作流程运行结束时，此令牌会自动过期。

此外，OIDC 允许更精细地控制机密的使用方式。例如，当请求源自特定受保护的分支或环境时，可以过滤对令牌的访问。

Palo Alto Networks 提供针对未来代码漏洞的全面保护

Cortex 云应用安全可帮助客户构建安全的应用并在威胁出现之前将其阻止。通过在单一风险、策略和自动化引擎中统一代码、管道、运行时、应用上下文和第三方发现，团队可以获得所需的可见性和控制力，从而从源头上预防问题。Cortex 云应用安全将情境感知、基于 AI 的优先级与预防优先的方法相结合，使团队能够加速安全部署。这有助于组织识别其环境中的安全漏洞，并减轻和降低最严重威胁的影响。

原文始发于微信公众号（安全视安）：GitHub Actions 供应链攻击分析