Translated ['', 'src/pentesting-ci-cd/pentesting-ci-cd-methodology.md']

src/pentesting-ci-cd/pentesting-ci-cd-methodology.md

@@ -1,4 +1,4 @@
-# Pentesting CI/CD Methodology
+# Pentesting CI/CD 方法论
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,7 +6,7 @@
 
 ## VCS
 
-VCS 是 **版本控制系统 (Version Control System)**，该系统允许开发者**管理他们的源代码**。最常见的是 **git**，你通常会在以下**平台**中看到公司使用它：
+VCS 代表 **Version Control System**，这个系统允许开发者 **管理他们的 source code**。最常见的是 **git**，通常你会看到公司在以下 **platforms** 中使用它：
 
 - Github
 - Gitlab
@@ -18,39 +18,39 @@ VCS 是 **版本控制系统 (Version Control System)**，该系统允许开发
 
 ## CI/CD Pipelines
 
-CI/CD pipelines 使开发者能够**自动执行代码**以完成多种目的，包括构建、测试和部署应用。这些自动化工作流由特定的操作触发，例如 code pushes、pull requests 或计划任务。它们有助于简化从开发到生产的流程。
+CI/CD pipelines 让开发者能够为各种目的 **自动化执行 code**，包括构建、测试和部署应用。这些自动化工作流会被 **特定动作触发**，例如代码 push、pull request 或计划任务。它们有助于简化从开发到生产的流程。
 
-但是，这些系统需要在某处**执行**，并且通常需要**有特权的凭证来部署代码或访问敏感信息**。
+然而，这些系统需要在某个地方被 **执行**，而且通常需要 **privileged credentials** 才能部署 code 或访问敏感信息。
 
 ## VCS Pentesting Methodology
 
 > [!NOTE]
-> 即便一些 VCS platforms 允许为此部分创建 pipelines，我们在本节中只分析对源代码控制的潜在攻击。
+> Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code.
 
-托管项目源代码的平台包含敏感信息，因此必须非常小心在该平台内授予的权限。以下是攻击者可能滥用的一些常见问题：
+包含项目 source code 的 platforms 会包含敏感信息，因此人们必须非常小心在这个 platform 内授予的权限。以下是攻击者可能利用的一些常见 VCS platform 问题：
 
-- **Leaks**: 如果你的代码在提交中包含 leaks，且攻击者可以访问 repo（因为它是 public 或者他已有访问权限），他可能会发现这些 leaks。
-- **Access**: 如果攻击者能**访问 VCS platform 内的一个账户**，他可能会获得**更多的可见性和权限**。
-- **Register**: 一些平台允许外部用户直接创建账户。
-- **SSO**: 有些平台不允许直接注册，但允许任何拥有有效 SSO 的人访问（例如攻击者可以用他的 github 账户登录）。
-- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... 有多种类型的令牌可以被窃取，从而以某种方式访问 repo。
-- **Webhooks**: VCS platforms 允许生成 webhooks。如果这些 webhooks **未用不可见的 secret 保护**，**攻击者可能会滥用它们**。
-- 如果没有 secret，攻击者可能滥用第三方平台的 webhook。
-- 如果 secret 在 URL 中，同样会发生并且攻击者也会拥有该 secret。
-- **Code compromise:** 如果恶意行为者对仓库拥有某种**写入**权限，他可能尝试**注入恶意代码**。要成功，他可能需要**绕过 branch protections**。这些操作可以出于不同目的：
-  - 攻破 main branch 以**影响 production**。
-  - 攻破 main（或其他分支）以**感染开发者的机器**（因为他们通常在机器上运行测试、terraform 或其他在 repo 内的任务）。
-- **Compromise the pipeline**（见下一节）
+- **Leaks**: 如果你的 code 在 commits 中包含 leaks，而攻击者能够访问 repo（因为它是公开的，或者因为他有访问权限），他就可能发现这些 leaks。
+- **Access**: 如果攻击者能够 **访问 VCS platform 内的一个 account**，他就可能获得 **更多可见性和权限**。
+- **Register**: 有些 platforms 允许外部用户直接创建 account。
+- **SSO**: 有些 platforms 不允许用户注册，但会允许任何人使用有效的 SSO 访问（例如攻击者可以用他的 github account 进入）。
+- **Credentials**: Username+Pwd、personal tokens、ssh keys、Oauth tokens、cookies... 用户可以窃取的 token 类型很多，从而以某种方式访问 repo。
+- **Webhooks**: VCS platforms 允许生成 webhooks。如果它们 **没有使用不可见的 secrets 保护**，**攻击者就可以滥用它们**。
+- 如果没有 secret，攻击者可以滥用第三方 platform 的 webhook
+- 如果 secret 在 URL 中，同样会发生，而且攻击者也会拿到这个 secret
+- **Code compromise:** 如果恶意行为者对 repos 拥有某种 **write** 访问权限，他就可以尝试 **注入恶意 code**。为了成功，他可能需要 **绕过 branch protections**。这些行为可以出于不同目的进行：
+- Compromise 主 branch 以 **compromise production**。
+- Compromise main（或其他 branches）以 **compromise developers machines**（因为他们通常会在自己的机器上在 repo 内执行 test、terraform 或其他东西）。
+- **Compromise the pipeline**（查看下一节）
 
 ## Pipelines Pentesting Methodology
 
-定义 pipeline 最常见的方式，是使用**托管在仓库中的 CI 配置文件**来描述。该文件说明执行作业的顺序、影响流程的条件以及构建环境设置。\
-这些文件通常有统一的名称和格式，例如 — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI)，以及位于 .github/workflows 下的 GitHub Actions YAML 文件。当触发时，pipeline 作业会**从选定源（例如 commit / branch）拉取代码**，并**针对该代码运行 CI 配置文件中指定的命令**。
+定义 pipeline 最常见的方式，是使用一个 **托管在 pipeline 所构建的 repository 中的 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 拉取 code**（例如 commit / branch），并 **针对该 code 运行 CI configuration file 中指定的 commands**。
 
-因此，攻击者的最终目标是以某种方式**篡改这些配置文件**或它们**执行的命令**。
+因此，攻击者的最终目标就是设法 **compromise 这些 configuration files** 或它们执行的 **commands**。
 
 > [!TIP]
-> 一些托管的 builder 允许贡献者选择 Docker build context 和 Dockerfile 路径。如果 context 可被攻击者控制，你可以将其设置到仓库外（例如 ".."）以在构建期间读取主机文件并外泄 secrets。参见：
+> Some hosted builders let contributors choose the Docker build context and Dockerfile path. If the context is attacker-controlled, you may set it outside the repo (e.g., "..") to ingest host files during build and exfiltrate secrets. See:
 >
 >{{#ref}}
 >docker-build-context-abuse.md
@@ -58,57 +58,78 @@ CI/CD pipelines 使开发者能够**自动执行代码**以完成多种目的，
 
 ### PPE - Poisoned Pipeline Execution
 
-Poisoned Pipeline Execution (PPE) 路径利用 SCM 仓库中的权限来操纵 CI pipeline 并执行有害命令。拥有必要权限的用户可以修改 CI 配置文件或 pipeline 作业使用的其他文件以包含恶意命令。这会“污染”CI pipeline，导致这些恶意命令被执行。
+Poisoned Pipeline Execution (PPE) 路径利用 SCM repository 中的权限来操纵 CI pipeline 并执行有害 commands。拥有必要权限的用户可以修改 CI configuration files 或 pipeline job 使用的其他 files，将恶意 commands 包含进去。这会“poison” CI pipeline，从而导致这些恶意 commands 被执行。
 
-要成功执行 PPE 攻击，恶意行为者需要能够：
+要成功实施 PPE attack，恶意行为者需要能够：
 
-- 拥有对 VCS platform 的**写入访问**，因为通常 pipeline 在 push 或 pull request 时被触发。（查看 VCS pentesting methodology 了解获取访问权限的汇总方式）。
-- 注意有时**外部 PR 也会被视为“写入访问”**。
-- 即便他有写入权限，他也需要确保能**修改 CI 配置文件或配置所依赖的其他文件**。
-- 为此，他可能需要能够**绕过 branch protections**。
+- 拥有 **VCS platform 的 write access**，因为 pipelines 通常在 push 或 pull request 执行时被触发。（查看 VCS pentesting methodology 以总结获取访问的方法）。
+- 注意，有时 **external PR 也算作 "write access"**。
+- 即使他有 write permissions，他也需要确保自己可以 **修改 CI config file 或 config 所依赖的其他 files**。
+- 为此，他可能需要能够 **绕过 branch protections**。
 
-PPE 有 3 种变体：
+PPE 有 3 种形式：
 
-- **D-PPE**: **Direct PPE** 发生在攻击者直接**修改将被执行的 CI 配置**文件时。
-- **I-DDE**: **Indirect PPE** 发生在攻击者**修改 CI 配置所依赖的文件**（例如 make 文件或 terraform 配置）时。
-- **Public PPE or 3PE**: 在某些情况下，pipelines 可以被**没有仓库写入权限的用户触发**（这些用户可能甚至不是组织成员），因为他们可以发送 PR。
-- **3PE Command Injection**: 通常，CI/CD pipelines 会用**关于 PR 的信息设置环境变量**。如果该值可被攻击者控制（例如 PR 的标题）且被**用于危险的地方**（比如执行 sh 命令），攻击者可能在其中**注入命令**。
+- **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**: 在某些情况下，pipelines 可以被 **没有 repo write access 的用户触发**（甚至他们可能都不是 org 的成员），因为他们可以发送 PR。
+- **3PE Command Injection**: 通常，CI/CD pipelines 会将与 PR 有关的信息 **设置为 environment variables**。如果该值能被攻击者控制（例如 PR 的标题），并且被 **用于** 一个 **危险位置**（例如执行 **sh commands**），攻击者就可能在那里 **注入 commands**。
 
 ### Exploitation Benefits
 
-了解了三种污染 pipeline 的方式后，我们来看攻击者成功利用后可能获得的收益：
+了解 poison 一个 pipeline 的 3 种形式后，看看攻击者成功利用后能获得什么：
 
-- **Secrets**: 如前所述，pipeline 的作业需要获取特权（检索代码、构建、部署等），这些特权通常以 **secrets** 的形式存在。这些 secrets 通常可以通过 **env 变量或系统内的文件**访问。因此攻击者会尽可能外泄大量 secrets。
-- 根据 pipeline 平台的不同，攻击者**可能需要在配置中指定 secrets**。这意味着如果攻击者不能修改 CI 配置 pipeline（例如 I-PPE），他**只能外泄该 pipeline 所具有的 secrets**。
-- **Computation**: 代码在某处被执行，取决于执行位置，攻击者可能进一步横向移动。
-- **On-Premises**: 如果 pipelines 在本地执行，攻击者可能进入**内部网络并访问更多资源**。
-- **Cloud**: 攻击者可能访问云中的其他机器，也可能**外泄 IAM roles/service accounts 的 tokens**以获取云内的进一步访问。
-- **Platforms machine**: 有时作业会在 **pipelines platform 的机器**内执行，这些机器通常位于云中且没有更多权限。
-- **Select it:** 有时 **pipelines platform 配置了多种机器**，如果你能**修改 CI 配置文件**，你可以**指定要在哪台机器上运行恶意代码**。在这种情况下，攻击者可能会在每台可用机器上运行反向 shell 以尝试进一步利用。
-- **Compromise production**: 如果你在 pipeline 内部并且最终版本就是从这里构建和部署的，你可以**篡改将在生产中运行的代码**。
+- **Secrets**: 如前所述，pipelines 的 job 需要 **privileges**（检索 code、构建它、部署它...），而这些 privileges 通常 **以 secrets 的形式授予**。这些 secrets 通常可通过 **env variables 或系统内的 files** 访问。因此，攻击者总会尝试尽可能多地 exfiltrate secrets。
+- 根据 pipeline platform 的不同，攻击者 **可能需要在 config 中指定 secrets**。这意味着如果攻击者无法修改 CI configuration pipeline（例如 **I-PPE**），他就 **只能 exfiltrate 该 pipeline 拥有的 secrets**。
+- **Computation**: code 会在某处执行，取决于执行位置，攻击者可能进一步 pivot。
+- **On-Premises**: 如果 pipelines 在本地部署环境中执行，攻击者可能最终进入一个 **内部网络，并能访问更多资源**。
+- **Cloud**: 攻击者可以访问云中的 **其他机器**，也可以从中 **exfiltrate** IAM roles/service accounts **tokens**，以获得在云中的 **进一步访问**。
+- **Platforms machine**: 有时 jobs 会在 **pipelines platform machines** 内执行，这些机器通常位于云中，并且 **没有更多访问权限**。
+- **Select it:** 有时 **pipelines platform 会配置多台机器**，如果你可以 **修改 CI configuration file**，你就可以 **指定你希望恶意 code 运行在哪里**。在这种情况下，攻击者可能会在每台可能的机器上运行 reverse shell，以尝试进一步利用。
+- **Compromise production**: 如果你已经在 pipeline 中，并且最终版本是从那里构建和部署的，你就可以 **compromise 将在 production 中运行的 code**。
+
+### Dependency & Registry Supply-Chain Abuse
+
+Compromising a CI/CD pipeline or stealing credentials from it can let an attacker move from **pipeline execution** to **ecosystem-wide code execution** by backdooring dependencies or release tooling:
+
+- **Install-time code execution via package hooks**: publish a package version that adds `preinstall`, `postinstall`, `prepare`, or similar hooks so the payload runs automatically on developer workstations and CI runners during dependency installation.
+- **Secondary execution paths**: even if targets install with `--ignore-scripts`, a malicious package can still register a **common CLI name** in the `bin` field so the attacker-controlled wrapper is symlinked into `PATH` and executes later when the command is used.
+- **Runtime bootstrapping**: a small installer can download a second runtime or toolchain during installation (for example Bun or a packed interpreter) and then launch the main payload with it, avoiding local dependency requirements.
+- **Credential harvesting from build environments**: once code runs inside CI, check environment variables, `~/.npmrc`, `~/.git-credentials`, SSH keys, cloud CLI configs, and local tooling such as `gh auth token`. On GitHub Actions, also look for runner-specific secrets and artifacts.
+- **Workflow injection with stolen GitHub tokens**: a token with **`repo` + `workflow`** permissions is enough to create a branch, commit a malicious file inside `.github/workflows/`, trigger it, collect the produced artifacts/logs, and then delete the temporary branch/workflow run to reduce traces.
+- **Wormable registry propagation**: stolen npm tokens should be validated for **publish** permissions and whether they bypass 2FA. If they do, enumerate writable packages, download their tarballs, inject a loader such as `setup.mjs`, set `preinstall` to execute it, bump the patch version, and republish. This turns one CI compromise into downstream auto-execution in other environments.
+
+#### Practical checks during an assessment
+
+- Review release automation for package-manager hooks added to `package.json`, unexpected `bin` entries, or version bumps that only modify the release artifact.
+- Check whether CI stores long-lived registry credentials in plaintext files such as `~/.npmrc` instead of using short-lived OIDC or trusted publishing.
+- Verify whether GitHub tokens available in CI can write workflow files or create branches/tags.
+- If a compromised package is suspected, inspect the published tarball and not only the Git repository, because the malicious loader/runtime may exist only in the published artifact.
+- Hunt for unexpected package-manager execution inside CI such as `npm install` instead of `npm ci`, unexpected Bun downloads/execution, or new workflow artifacts generated from transient branches.
 
 ## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) 是一个开源工具，用于基于新的 [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf) 对你的软件供应链堆栈进行安全合规审计。审计关注整个 SDLC 过程，可以揭示从代码阶段到部署阶段的风险。
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is an open-source tool for auditing your software supply chain stack for security compliance based on a new [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). The auditing focuses on the entire SDLC process, where it can reveal risks from code time into deploy time.
 
 ### Top 10 CI/CD Security Risk
 
-查看 Cider 关于前十个 CI/CD 风险的有趣文章: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+Check this interesting article about the top 10 CI/CD risks according to Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
 ### Labs
 
-- 在每个平台的本地运行示例中，你会找到如何在本地启动它的说明，以便你可以按需配置来测试。
+- On each platform that you can run locally you will find how to launch it locally so you can configure it as you want to test it
 - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
 ### Automatic Tools
 
-- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** 是一个针对基础设施即代码的静态代码分析工具。
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** is a static code analysis tool for infrastructure-as-code.
 
 ## References
 
 - [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422)
+- [The npm Threat Landscape: Attack Surface and Mitigations](https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/)
+- [Checkmarx Security Update: April 22, 2026](https://checkmarx.com/blog/checkmarx-security-update-april-22/?p=108469)
 
 
 {{#include ../banners/hacktricks-training.md}}