Pentesting CI/CD Methodology

Tip

学习并练习 AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
学习并练习 GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
学习并练习 Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

VCS

VCS 代表 Version Control System，这个系统允许开发者 管理他们的源代码。最常见的是 git，你通常会发现公司在以下 platforms 之一中使用它：

  • Github
  • Gitlab
  • Bitbucket
  • Gitea
  • Gitblit
  • Cloud providers (they offer their own VCS platforms)

CI/CD Pipelines

CI/CD pipelines 使开发者能够为各种目的 自动执行代码，包括构建、测试和部署应用程序。这些自动化工作流会被特定操作触发，例如代码 push、pull requests 或计划任务。它们有助于简化从开发到生产的流程。

然而，这些系统需要在某个地方执行，而且通常需要使用特权凭证来部署代码或访问敏感信息。

VCS Pentesting Methodology

Note

即使某些 VCS platforms 允许为这一节创建 pipelines，我们这里也只分析对源代码控制的潜在攻击。

包含项目源代码的平台包含敏感信息，且人们需要非常谨慎地管理在这个平台内授予的权限。以下是 attacker 可能利用的 VCS platforms 中一些常见问题：

  • Leaks: 如果你的代码在 commits 中包含 leaks，并且 attacker 可以访问 repo（因为它是公开的，或者因为他有访问权限），他就可能发现这些 leaks。
  • Access: 如果 attacker 能够 访问 VCS platform 内的一个 account，他就可以获得 更多可见性和权限。
  • Register: 一些平台会直接允许外部用户创建 account。
  • SSO: 一些平台不允许用户注册，但会允许任何拥有有效 SSO 的人访问（例如 attacker 可以用他的 github account 进入）。
  • Credentials: Username+Pwd、personal tokens、ssh keys、Oauth tokens、cookies… 有多种 token 可被用户窃取，从而以某种方式访问 repo。
  • Webhooks: VCS platforms 允许生成 webhooks。如果它们没有用不可见的 secrets 保护，attacker could abuse them。
  • 如果没有 secret，attacker 可以滥用第三方平台的 webhook
  • 如果 secret 在 URL 中，情况也一样，而且 attacker 还能拿到这个 secret
  • Code compromise: 如果恶意行为者对 repos 拥有某种 write 权限，他可能尝试 inject malicious code。为了成功，他可能需要 bypass branch protections。这些动作可以基于不同目标执行：
  • 破坏 main branch 以 compromise production。
  • 破坏 main（或其他 branches）以 compromise developers machines（因为他们通常会在自己的机器上执行 test、terraform 或 repo 内的其他内容）。
  • Compromise the pipeline（查看下一节）

Pipelines Pentesting Methodology

定义 pipeline 最常见的方式，是使用一个托管在该 pipeline 所构建仓库中的 CI configuration file。这个文件描述了执行 jobs 的顺序、影响流程的条件，以及 build environment settings。
这些文件通常有固定的名称和格式，例如 — Jenkinsfile (Jenkins)、.gitlab-ci.yml (GitLab)、.circleci/config.yml (CircleCI)，以及位于 .github/workflows 下的 GitHub Actions YAML files。触发后，pipeline job 会从选定的 source 拉取代码（例如 commit / branch），并针对该代码运行 CI configuration file 中指定的 commands。

因此，attacker 的最终目标是以某种方式compromise 这些 configuration files 或它们执行的commands。

Tip

一些 hosted builders 允许贡献者选择 Docker build context 和 Dockerfile path。如果 context 可由 attacker 控制，你可以将其设置到 repo 之外（例如 “..”），从而在 build 过程中提取 host files 并 exfiltrate secrets。参见：

{{#ref}} docker-build-context-abuse.md {{#endref}}

PPE - Poisoned Pipeline Execution

Poisoned Pipeline Execution (PPE) 路径利用 SCM repository 中的权限来操纵 CI pipeline 并执行恶意 commands。具有必要权限的用户可以修改 CI configuration files 或 pipeline job 使用的其他文件，以包含恶意 commands。这样就会“poison” CI pipeline，并导致这些恶意 commands 被执行。

要成功执行 PPE attack，恶意行为者需要能够：

  • 拥有对 VCS platform 的 write access，因为 pipeline 通常在 push 或 pull request 执行时触发。（查看 VCS pentesting methodology 以总结获取访问权限的方法）。
  • 注意，有时 external PR 也算作 “write access”。
  • 即使他有 write permissions，他也需要确保自己能 modify CI config file 或 config 依赖的其他文件。
  • 为此，他可能需要能够 bypass branch protections。

PPE 有 3 种变体：

  • D-PPE: 当行为者 修改将要执行的 CI config file 时，就发生 Direct PPE attack。
  • I-DDE: 当行为者 修改 将要执行的 CI config file 依赖 的一个 file 时，就发生 Indirect PPE attack（例如 make file 或 terraform config）。
  • Public PPE or 3PE: 在某些情况下，pipeline 可能会被没有 repo write access 的用户（甚至可能不是 org 的一部分）触发，因为他们可以发送 PR。
  • 3PE Command Injection: 通常，CI/CD pipelines 会基于 PR 的信息设置 environment variables。如果某个值能被 attacker 控制（比如 PR 的标题），并且在危险位置被使用（比如执行 sh commands），attacker 可能会在其中inject commands。

Exploitation Benefits

了解 poison pipeline 的 3 种变体后，看看成功利用后 attacker 能得到什么：

  • Secrets: 如前所述，pipelines 运行它们的 jobs 需要特权（获取代码、构建、部署等），而这些特权通常会以 secrets 形式提供。这些 secrets 通常可通过 env variables 或系统内文件访问。因此 attacker 总会尝试尽可能多地 exfiltrate secrets。
  • 根据 pipeline platform 的不同，attacker 可能需要在 config 中指定 secrets。这意味着如果 attacker 不能修改 CI configuration pipeline（例如 I-PPE），他就只能 exfiltrate 该 pipeline 已有的 secrets。
  • Computation: 代码在某处执行，取决于执行位置，attacker 可能进一步 pivot。
  • On-Premises: 如果 pipelines 在本地环境执行，attacker 可能最终进入一个内部网络，并能访问更多资源。
  • Cloud: attacker 可能访问 cloud 中的其他机器，同时也可能从中 exfiltrate IAM roles/service accounts tokens，以获得 cloud 内部的进一步访问。
  • Platforms machine: 有时 jobs 会在 pipelines platform machines 内执行，这些机器通常位于 cloud 中，但没有更多访问权限。
  • Select it: 有时 pipelines platform 会配置多台机器，如果你可以 modify the CI configuration file，你就可以 indicate where you want to run the malicious code。在这种情况下，attacker 很可能会在每台可能的机器上运行 reverse shell，以尝试进一步利用。
  • Compromise production: 如果你在 pipeline 内，而且最终版本是由它构建并部署的，你就可以 compromise 将在 production 中运行的代码。

Dependency & Registry Supply-Chain Abuse

攻陷 CI/CD pipeline 或从中窃取凭证，可能让 attacker 从 pipeline execution 进一步走向 ecosystem-wide code execution，方法是对 dependencies 或 release tooling 做后门植入：

  • Install-time code execution via package hooks: 发布一个 package version，添加 preinstall、postinstall、prepare 或类似 hooks，使 payload 在 developer workstations 和 CI runners 上的 dependency installation 期间自动运行。
  • Secondary execution paths: 即使目标使用 --ignore-scripts 安装，恶意 package 仍可在 bin 字段中注册一个 common CLI name，这样 attacker 控制的 wrapper 会被 symlink 到 PATH 中，并在之后命令被使用时执行。
  • Runtime bootstrapping: 一个小型 installer 可以在安装期间下载第二个 runtime 或 toolchain（例如 Bun 或打包过的 interpreter），然后用它启动主 payload，从而避免本地依赖要求。
  • Credential harvesting from build environments: 一旦代码在 CI 中运行，检查 environment variables、~/.npmrc、~/.git-credentials、SSH keys、cloud CLI configs，以及诸如 gh auth token 的本地工具。在 GitHub Actions 上，也要查看 runner-specific secrets 和 artifacts。
  • Workflow injection with stolen GitHub tokens: 拥有 repo + workflow 权限的 token 足以创建 branch、在 .github/workflows/ 中提交恶意文件、触发它、收集生成的 artifacts/logs，然后删除临时 branch/workflow run 以减少痕迹。
  • Wormable registry propagation: 被盗的 npm tokens 应验证是否具有 publish 权限，以及是否绕过 2FA。如果可以，就枚举可写 packages，下载它们的 tarballs，注入一个诸如 setup.mjs 的 loader，将 preinstall 设为执行它，提升 patch version，然后 republish。这样就能把一次 CI compromise 变成其他环境中的下游自动执行。

Practical checks during an assessment

  • 审查 release automation 中是否存在添加到 package.json 的 package-manager hooks、意外的 bin entries，或只修改 release artifact 的 version bumps。
  • 检查 CI 是否将长期有效的 registry credentials 明文存储在如 ~/.npmrc 这样的文件中，而不是使用短期 OIDC 或 trusted publishing。
  • 验证 CI 中可用的 GitHub tokens 是否能够写入 workflow files 或创建 branches/tags。
  • 如果怀疑某个 package 已被 compromise，请检查已发布的 tarball，而不只是 Git repository，因为恶意 loader/runtime 可能只存在于已发布 artifact 中。
  • 在 CI 中寻找意外的 package-manager execution，例如 npm install 而不是 npm ci、意外的 Bun downloads/execution，或由临时 branches 生成的新 workflow artifacts。

More relevant info

Tools & CIS Benchmark

  • Chain-bench 是一个开源工具，用于基于新的 CIS Software Supply Chain benchmark 审计软件 supply chain stack 的安全合规性。该审计关注整个 SDLC process，可揭示从 code time 到 deploy time 的风险。

Top 10 CI/CD Security Risk

查看这篇关于根据 Cider 评出的前 10 个 CI/CD risks 的有趣文章：https://www.cidersecurity.io/top-10-cicd-security-risks/

Labs

Automatic Tools

  • Checkov: Checkov 是一个用于 infrastructure-as-code 的静态代码分析工具。

References

Tip

学习并练习 AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
学习并练习 GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
学习并练习 Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks