GitHub Actions 供应链攻击剖析

近日，一场针对 GitHub Actions 的供应链攻击事件浮出水面，威胁行动者利用两个流行的 GitHub Action："tj-actions/changed-files" (CVE-2024-30066, CVSS 评分：8.6) 和其依赖 "reviewdog/action-setup" 的 v1 标签 (CVE-2024-30154, CVSS 评分：8.6) 的漏洞，成功窃取了至少 218 个 GitHub 仓库的 CI/CD 秘密。

漏洞技术细节：

• tj-actions/changed-files:
  
   这个 Action 用于检测在拉取请求 (Pull Request) 中更改的文件。它通常用于自动化代码审查和测试流程。
• reviewdog/action-setup:
  
   这个 Action 用于设置 reviewdog 工具，reviewdog 是一个自动化代码审查工具，可以与各种 CI 服务集成。
• 攻击向量：
  
   攻击者首先入侵了 "reviewdog/action-setup" 的 v1 标签，植入了恶意代码。由于 "tj-actions/changed-files" 依赖于 "reviewdog/action-setup"，导致使用 "tj-actions/changed-files" 的 GitHub Actions 工作流也会执行恶意代码。 恶意代码会泄露CI/CD Runner的secrets，其中包含可以操作tj-actions/changed-files的PAT。
• 恶意代码功能:
1. 泄露CI/CD Runner的secrets。
2. 获取tj-bot-actions 用户的PAT。
3. 获取Coinbase 相关仓库的写权限。

攻击链还原（详细步骤）：

1. 入侵 reviewdog/action-setup：
   
    攻击者通过某种方式（目前尚不清楚，可能是凭据泄露、社会工程学或利用其他漏洞）获取了对 reviewdog 组织具有写入权限的令牌。攻击者分叉（fork）了 "reviewdog/action-setup" 仓库，向其中提交了恶意代码，并创建了一个“悬空提交”（Dangling Commit）。
• 悬空提交：
  
   在 Git 中，每次提交都会有一个唯一的 ID（SHA-1 哈希值）。分支和标签是指向这些提交的指针。如果一个提交没有被任何分支或标签指向，它就成了“悬空提交”。悬空提交通常难以被发现，因为它们不会出现在正常的提交历史中。攻击者通过创建分叉拉取请求，然后在合并前删除分叉仓库，使得提交记录难以追踪。
2. 获取 tj-actions/changed-files 的 PAT：
   
    由于 "tj-actions/eslint-changed-files" action 执行时会运行"reviewdog/action-setup", 导致CI runner的secrets泄露，其中包含tj-actions/changed-files的PAT。
3. 入侵 tj-actions/changed-files：
   
    攻击者利用获取到的 "tj-actions/changed-files" 的 PAT，向该仓库推送了恶意代码。
4. 大规模攻击：
   
    任何使用了 "tj-actions/changed-files" 的 GitHub Actions 工作流（Workflow）都会执行攻击者注入的恶意代码，导致 CI/CD 秘密（如 DockerHub、npm、AWS 凭据以及 GitHub 安装访问令牌）泄露。
5. 定向攻击 Coinbase：
• 攻击者利用获得的权限，修改了 Coinbase 相关仓库（如 onchainkit、agentkit）的 "changelog.yml" 文件。
• 修改后的 "changelog.yml" 文件会触发一个 GitHub Actions 工作流，该工作流使用了恶意版本的 "tj-actions/changed-files"。
• 由于该工作流在 Coinbase 的 CI/CD 环境中运行，恶意版本的 "tj-actions/changed-files" 可以访问 Coinbase 特定的密钥（如加密货币交易所的 API 密钥）。
• 攻击者在针对Coinbase时使用了不同的payload，只在仓库属于Coinbase时，才获取GITHUB_TOKEN。

不同的Payload：攻击者在不同阶段使用了不同的Payload。例如，在大规模攻击中，攻击者会转储运行器的内存并将作为环境变量存储的secrets打印到工作流的日志中。 而在针对 Coinbase 的攻击中，攻击者专门获取了 GITHUB_TOKEN，并确保有效负载仅在存储库属于 Coinbase 时才会执行。

防御建议（实操）：

1. 审查 GitHub Actions：
   
    仔细审查您使用的所有 GitHub Actions，特别是来自第三方的 Actions。查看其源代码和提交历史，确保没有可疑活动。
2. 锁定 Action 版本：
• 不要使用标签（如 v1）：标签是可以移动的，攻击者可以强制推送恶意代码到同一标签。

• 使用 commit SHA：在您的 GitHub Actions 工作流文件中，使用特定提交的 SHA-1 哈希值来引用 Action。例如：

uses: tj-actions/changed-files@a12db391f80c5915a6f15618e3299c75d794945c

• 这可以确保您的工作流始终使用 Action 的特定版本，即使该 Action 的标签被更新。
1. 最小权限原则：
   
    为 GitHub Actions 工作流配置最小权限的令牌。例如，如果工作流只需要读取仓库内容，就不要授予它写入权限。
2. 密钥轮换：
   
    定期轮换您的 CI/CD 秘密（如 API 密钥、访问令牌等）。
3. 监控：
   
    监控您的 GitHub Actions 工作流日志，以及时发现异常活动，如意外的 API 调用、文件修改或网络连接。
4. 使用Dependabot:
   
    启用 GitHub 的 Dependabot 功能，它可以自动检测您使用的 Action 的漏洞，并创建拉取请求来更新它们。

GitHub 官方回复强调： 用户应始终在使用新版本之前审查他们正在使用的 GitHub Actions 或任何其他软件包。

虽然目前尚不清楚该活动的最终目标是什么，但强烈怀疑其意图是经济利益，可能是试图进行加密货币盗窃，特别是考虑到最初针对Coinbase的攻击。 Coinbase 已于 2025 年 3 月 19 日修复了此次攻击。

原文始发于微信公众号（技术修道场）：GitHub Actions 供应链攻击剖析