From 206b4c421d28c2009cf28730da2bcd720db1e1da Mon Sep 17 00:00:00 2001 From: Translator Date: Mon, 6 Jul 2026 15:54:39 +0000 Subject: [PATCH] Translated ['src/pentesting-ci-cd/argocd-security.md', 'src/pentesting-c --- src/pentesting-ci-cd/argocd-security.md | 219 ++++++++++++++++++ .../pentesting-ci-cd-methodology.md | 109 ++++----- 2 files changed, 274 insertions(+), 54 deletions(-) create mode 100644 src/pentesting-ci-cd/argocd-security.md diff --git a/src/pentesting-ci-cd/argocd-security.md b/src/pentesting-ci-cd/argocd-security.md new file mode 100644 index 000000000..272dfefa3 --- /dev/null +++ b/src/pentesting-ci-cd/argocd-security.md @@ -0,0 +1,219 @@ +# Argo CD Security + +{{#include ../banners/hacktricks-training.md}} + +## Basic Information + +[Argo CD](https://argo-cd.readthedocs.io/) 是一个面向 Kubernetes 的 GitOps continuous delivery platform。它会监视 Git repositories，使用 Helm、Kustomize、Jsonnet 或 config management plugins 等工具渲染 Kubernetes manifests，并将 live cluster state 与存储在 Git 中的 desired state 进行 reconcile。 + +从攻击者视角来看，应将 Argo CD 视为一个带有 Kubernetes credentials 的 **deployment engine**。一次有效的 Argo CD compromise 可能导致： + +- 访问 private Git repositories 和 repository credentials。 +- 访问 Argo CD 使用的 Kubernetes cluster secrets。 +- 在 `argocd-repo-server` 中执行 manifest generation code。 +- 通过 trusted Git repositories、Argo CD applications 或 cache manipulation 非授权部署 Kubernetes objects。 + +## Architecture & Interesting Components + +Common Kubernetes objects and services: +```bash +kubectl get pods,svc,endpoints,ingress -A | grep -iE 'argocd|argo-cd' +kubectl get applications,appprojects,applicationsets -A 2>/dev/null +kubectl get secrets,configmaps -n argocd 2>/dev/null +kubectl get networkpolicy -n argocd 2>/dev/null +``` +有趣的服务： + +- **`argocd-server`**: public API、web UI、CLI API、authentication 和 authorization。 +- **`argocd-application-controller`**: 比较 desired 和 live state，然后将 resources 应用到 Kubernetes。 +- **`argocd-repo-server`**: clones repositories，缓存 Git data，并运行 Helm/Kustomize/Jsonnet/plugins 以生成 manifests。默认 gRPC 端口是 **8081**。 +- **`argocd-redis`**: application、manifest 和 Git reference data 的 cache。默认 Redis 端口是 **6379**。 +- **`argocd-applicationset-controller`**: 从 Git、SCM、clusters 和 pull requests 等 generators 生成 Argo CD `Application` objects。 + +从被 compromise 的 pod 或 internal network segment 中，检查 internal reachability： +```bash +nc -vz 443 +nc -vz 8081 +nc -vz 6379 +``` +## Public API / UI 攻击 + +如果你有 Argo CD credentials 或一个暴露的 instance，先从 normal API surface 开始： +```bash +argocd login +argocd account get-user-info +argocd account list +argocd proj list +argocd app list +argocd repo list +argocd cluster list +argocd admin settings rbac can +``` +有用的 attack paths： + +- **Application write access**: 修改 `source.repoURL`、`source.path`、Helm values、Kustomize 选项、plugin settings 或 sync options，让 Argo CD 部署 attacker-controlled manifests。 +- **Project misconfiguration**: `AppProject` objects 可能允许过宽的 `sourceRepos`、过宽的 `destinations`、不安全的 `clusterResourceWhitelist`，或薄弱的 namespace restrictions。 +- **Repository credential abuse**: repository secrets、GitHub App credentials、SSH keys 和 tokens 可能允许向受信任的 repos 推送，或添加 malicious dependencies。 +- **Cluster credential abuse**: cluster secrets 可能包含 bearer tokens 或 exec-provider configuration，供 Argo CD 用于部署到 target clusters。 +- **Local admin / project tokens**: 长期有效的 Argo CD tokens 除非被 revoke 或 expired，否则可以通过 API 重用。 + +当你拥有 cluster read access 时，枚举 Kubernetes 中的配置： +```bash +kubectl get applications.argoproj.io -A -o yaml +kubectl get appprojects.argoproj.io -A -o yaml +kubectl get applicationsets.argoproj.io -A -o yaml +kubectl get secrets -n argocd -o yaml | grep -nE 'repoURL|sshPrivateKey|password|bearerToken|githubApp|tlsClientCertData|tlsClientCertKey' +kubectl get cm -n argocd argocd-cm argocd-rbac-cm argocd-cmd-params-cm -o yaml +``` +## Trusted Git Repository Abuse + +如果你可以 push 到一个被 Argo CD trusted 的 repository，你通常可以影响部署内容。影响取决于 `AppProject` 边界以及 application controller 使用的 service account 权限。 + +常见 payload 位置： + +- application path 下的原始 Kubernetes YAML。 +- Helm chart templates 和 `values.yaml`。 +- Kustomize overlays、remote bases 和 generators。 +- Jsonnet 或 config management plugin 输入。 +- 创建或更新 `Application` objects 的 ApplicationSet generator files。 + +检查 app 是否使用 automated sync、pruning、self-heal、sync windows 或 manual approvals： +```bash +kubectl get applications.argoproj.io -A \ +-o custom-columns='NS:.metadata.namespace,APP:.metadata.name,PROJECT:.spec.project,AUTOSYNC:.spec.syncPolicy.automated,REPO:.spec.source.repoURL,PATH:.spec.source.path,DEST:.spec.destination.server' +``` +## 直接滥用 `argocd-repo-server` + +不要假设公开的 Argo CD API 是唯一的攻击面。内部 Argo CD 组件通过 gRPC 与 `argocd-repo-server` 通信。若任意 pods 能够访问 repo-server，攻击者控制的内部请求可能绕过通常由 `argocd-server` 强制执行的检查。 + +实际检查： +```bash +kubectl get svc -n argocd argocd-repo-server -o yaml +kubectl get endpoints -n argocd argocd-repo-server -o wide +nc -vz 8081 +``` +Interesting signs: + +- repo-server gRPC endpoint 可从非 Argo CD pods 访问。 +- NetworkPolicies 缺失，或只允许 allow-list egress 但未拒绝 ingress。 +- repo-server 可访问自定义 config management plugins、decryption tools，或来自多个 tenant 的 repository content。 +- Redis 可从非 Argo CD pods 访问；如果 credentials 可用或不需要，就可能进行 cache inspection 或 tampering。 + +## 通过 Kustomize Options 实现未认证的 Repo-Server RCE + +在 2026 年 7 月，Synacktiv 披露了 Argo CD 的 `repo-server` 中一条未认证 code execution 链，当 attacker 能访问内部 gRPC service 时即可触发。该攻击滥用对 `/repository.RepoServerService/GenerateManifest` 的直接访问，以及 attacker-controlled 的 `KustomizeOptions`。 + +危险的 primitive 是强制 repo-server clone attacker-controlled repository content，并在启用 Helm support 的情况下运行 Kustomize： +```bash +kustomize build --enable-helm --helm-command ./payload.sh +``` +触发 Helm 处理所需的最小恶意 Kustomize 输入： +```yaml +helmCharts: +- name: pwn +version: 0.0.1 +``` +为什么这可行： + +- `argocd-repo-server` 会在渲染之前先 clone 该 repository。 +- `--helm-command ./payload.sh` 会相对于已 clone 的 repository 来解析。 +- 如果 attacker 能控制被渲染的 repository 和 Kustomize build options，就不需要 shell metacharacter injection 也能实现 Code execution。 + +在 Synacktiv 于 2026 年 7 月 1 日披露时，他们报告该问题没有官方修复或 CVE。应首先将其视为一个网络暴露问题：exploitation 需要能够访问内部的 repo-server gRPC 端口。 + +## Redis Cache Poisoning to Deploy Manifests + +在 `argocd-repo-server` 中实现 Code execution 后，或者在使用有效凭据直接访问 Redis 后，检查 Redis-backed cache entries。Argo CD 通常会存储 gzip-compressed JSON values。 + +有趣的 key prefixes： +```text +mfst|... # cached rendered manifests +git-refs|... # Git branch/ref to commit mappings +app|... # application resource/cache data +cluster|... # cluster cache information +``` +Synacktiv 描述的 cache poisoning attack 利用了两种状态： + +1. 修改相关的 `mfst|...` manifest cache entry，以包含攻击者控制的 Kubernetes manifest。 +2. 修改相关的 `git-refs|...` mapping，让 Argo CD 认为 branch 已移动，然后再回滚到缓存的 revision。 + +影响： + +- 启用 Auto Sync 时，Argo CD 可能会自动应用被污染的 cached manifest。 +- 未启用 Auto Sync 时，当用户手动 sync 该 application 时，payload 仍可能被应用。 +- 最终影响受目标 application 的 destination 以及 Argo CD 可用的 Kubernetes permissions 限制。 + +## ApplicationSet Attacks + +ApplicationSet 尤其敏感，因为它会根据 generator output 创建或更新 `Application` objects。 + +Review: +```bash +kubectl get applicationsets.argoproj.io -A -o yaml +kubectl get appprojects.argoproj.io -A -o yaml +``` +Interesting patterns: + +- Git generators reading attacker-writable files that control app names, paths, projects or destinations. +- Pull request generators for public repositories where untrusted contributors can influence generated applications. +- Template fields that allow broad destination clusters/namespaces. +- AppProjects that permit `sourceRepos: ["*"]` or broad `destinations`. +- Generated applications that inherit automated sync and pruning. + +## Post-Exploitation + +From an Argo CD pod shell, prioritize: +```bash +env +cat /proc/1/environ 2>/dev/null | tr '\0' '\n' +find /var/run/secrets /app/config -type f -maxdepth 4 2>/dev/null +mount | grep -E 'secret|token|config' +``` +有用的目标： + +- 窃取 `REDIS_PASSWORD` 或 Redis TLS/client 材料。 +- 从挂载的 secrets 或 Argo CD Kubernetes secrets 中提取 repository credentials。 +- 识别 Argo CD 使用的 cluster credentials。 +- 读取生成的 manifests 和可能包含注入 secrets 的 plugin output。 +- 检查 custom plugins、SOPS、Helm secrets、Vault plugins 或 cloud CLIs 是否暴露了 decryption keys 和 cloud credentials。 + +## 检测与加固 + +重要检查： + +- 通过 NetworkPolicies 限制 `argocd-repo-server` 端口 **8081** 和 Redis 端口 **6379**，确保只有预期的 Argo CD 组件可以访问它们。 +- 在 Helm deployments 中，确认 network policies 确实被创建。Argo CD Helm chart values 过去通常将组件 network policy creation 默认设为 disabled。 +- 将 `argocd-server` 保持为经过认证的入口点。内部服务不应能被任意 workloads 访问。 +- 禁用未使用的 config management tools 和 plugins。 +- 限制 `AppProject` 的 `sourceRepos`、`destinations`、namespace permissions 和 cluster-scoped resources。 +- 避免存储过于宽泛的 repository credentials，以免被低权限 Argo CD user 触发复用。 +- 监控 repo-server requests、Kustomize build options、plugin executions、Redis writes，以及对 `mfst|` / `git-refs|` keys 的异常访问。 +- 在发生 compromise 后，轮换 Argo CD local users、project tokens、repository credentials 和 cluster credentials。 + +有用的命令： +```bash +kubectl get networkpolicy -n argocd +kubectl get networkpolicy -A | grep -i argocd +kubectl describe networkpolicy -n argocd argocd-repo-server-network-policy 2>/dev/null +kubectl describe networkpolicy -n argocd argocd-redis-network-policy 2>/dev/null +``` +## Static Analysis Note: Typed API Requests in CodeQL + +对于使用 gRPC/REST handlers 的 Go services，默认的 CodeQL remote sources 可能会在原始输入被 unmarshaled 成 typed request objects 之后漏掉 flows。对 Argo CD 风格的 services，一个有用的 model 是： + +- Receiver type 例如 `Server` 或 `Service`。 +- 第一个参数是 `context.Context`。 +- 第二个参数是 typed request object。 + +把这个第二个参数建模为 remote source，并为 `exec.Command` / `exec.CommandContext` arguments 添加 custom sinks。这有助于发现从内部 API request fields 到 command execution helpers 的 flows。 + +## References + +- [Synacktiv - Caught in the Octopus Trap: Unauthenticated RCE in Argo CD with CodeQL](https://www.synacktiv.com/en/publications/caught-in-the-octopus-trap-unauthenticated-rce-in-argo-cd-with-codeql) +- [Argo CD docs - Security considerations](https://argo-cd.readthedocs.io/en/stable/operator-manual/security/) +- [Argo CD docs - High Availability](https://argo-cd.readthedocs.io/en/stable/operator-manual/high_availability/) +- [Argo CD docs - repo-server command reference](https://argo-cd.readthedocs.io/en/stable/operator-manual/server-commands/argocd-repo-server/) +- [Argo CD - repo-server NetworkPolicy manifest](https://github.com/argoproj/argo-cd/blob/master/manifests/base/repo-server/argocd-repo-server-network-policy.yaml) +- [Argo CD docs - metrics](https://argo-cd.readthedocs.io/en/latest/operator-manual/metrics/) +- [Argo Helm - chart values reference](https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/README.md) +- [Kustomize - Helm chart generator example](https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md) diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index 8d8428a38..0f72dc42d 100644 --- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md +++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md @@ -6,51 +6,51 @@ ## VCS -VCS 代表 **Version Control System**，这个系统允许开发者 **管理他们的源代码**。最常见的是 **git**，你通常会发现公司在以下 **platforms** 之一中使用它： +VCS 代表 **Version Control System**，这个系统允许开发者 **管理他们的源代码**。最常见的是 **git**，你通常会发现公司在以下 **platforms** 中使用它： - Github - Gitlab - Bitbucket - Gitea - Gitblit -- Cloud providers (they offer their own VCS platforms) +- Cloud providers (他们提供自己的 VCS platforms) ## CI/CD Pipelines -CI/CD pipelines 使开发者能够为各种目的 **自动执行代码**，包括构建、测试和部署应用程序。这些自动化工作流会被**特定操作触发**，例如代码 push、pull requests 或计划任务。它们有助于简化从开发到生产的流程。 +CI/CD pipelines 使开发者能够为各种目的 **自动执行代码**，包括构建、测试和部署应用程序。这些自动化工作流会被 **特定操作触发**，例如代码推送、pull requests，或定时任务。它们有助于简化从开发到生产的流程。 -然而，这些系统需要在某个地方**执行**，而且通常需要使用**特权凭证来部署代码或访问敏感信息**。 +然而，这些系统需要在 **某个地方执行**，而且通常需要 **特权凭证** 来部署代码或访问敏感信息。 ## VCS Pentesting Methodology > [!NOTE] -> 即使某些 VCS platforms 允许为这一节创建 pipelines，我们这里也只分析对源代码控制的潜在攻击。 +> 即使某些 VCS platforms 允许创建 pipelines，我们在这一部分也只分析对源代码控制的潜在攻击。 -包含项目源代码的平台包含敏感信息，且人们需要非常谨慎地管理在这个平台内授予的权限。以下是 attacker 可能利用的 VCS platforms 中一些常见问题： +包含项目源代码的平台会包含敏感信息，因此人们必须非常谨慎地管理授予该平台内的权限。以下是攻击者可能利用的一些常见 VCS platform 问题： -- **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**（查看下一节） +- **Leaks**: 如果你的代码在 commits 中包含 leaks，并且攻击者能够访问 repo（因为它是公开的，或者因为他有访问权限），他就可以发现这些 leaks。 +- **Access**: 如果攻击者能够 **访问 VCS platform 中的一个账户**，他就可能获得 **更多可见性和权限**。 +- **Register**: 某些 platforms 允许外部用户直接创建账户。 +- **SSO**: 某些 platforms 不允许用户注册，但会允许任何拥有有效 SSO 的人访问（例如攻击者可以用他的 github 账户进入）。 +- **Credentials**: Username+Pwd、personal tokens、ssh keys、Oauth tokens、cookies... 有多种 token，用户可能会窃取这些 token 以某种方式访问 repo。 +- **Webhooks**: VCS platforms 允许生成 webhooks。如果它们 **没有** 使用不可见的 secrets 进行保护，**攻击者就可以滥用它们**。 +- 如果没有设置 secret，攻击者就可以滥用第三方 platform 的 webhook +- 如果 secret 在 URL 中，情况也一样，而且攻击者还能拿到该 secret +- **Code compromise:** 如果恶意行为者对 repos 拥有某种 **write** 访问，他可能会尝试 **注入恶意代码**。为了成功，他可能需要 **绕过 branch protections**。这些操作可能出于不同目的： +- 破坏 main branch 以 **破坏生产环境**。 +- 破坏 main（或其他 branches）以 **破坏开发者机器**（因为他们通常会在自己的机器上在 repo 内执行测试、terraform 或其他内容）。 +- **破坏 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**。 +定义 pipeline 最常见的方法，是使用一个 **托管在 pipeline 构建的 repository 中的 CI configuration file**。这个文件描述已执行 jobs 的顺序、影响流程的条件，以及构建环境设置。\ +这些文件通常具有一致的名称和格式，例如 — 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**。 +因此，攻击者的最终目标是以某种方式 **破坏这些 configuration files** 或 **它们执行的 commands**。 > [!TIP] -> 一些 hosted builders 允许贡献者选择 Docker build context 和 Dockerfile path。如果 context 可由 attacker 控制，你可以将其设置到 repo 之外（例如 ".."），从而在 build 过程中提取 host files 并 exfiltrate 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,67 +58,68 @@ CI/CD pipelines 使开发者能够为各种目的 **自动执行代码**，包 ### PPE - Poisoned Pipeline Execution -Poisoned Pipeline Execution (PPE) 路径利用 SCM repository 中的权限来操纵 CI pipeline 并执行恶意 commands。具有必要权限的用户可以修改 CI configuration files 或 pipeline job 使用的其他文件，以包含恶意 commands。这样就会“poison” CI pipeline，并导致这些恶意 commands 被执行。 +Poisoned Pipeline Execution (PPE) 路径利用 SCM repository 中的权限来操纵 CI pipeline 并执行有害 commands。拥有必要权限的用户可以修改 CI configuration files 或 pipeline job 使用的其他 files，以包含恶意 commands。这样就“污染”了 CI pipeline，导致这些恶意 commands 被执行。 要成功执行 PPE attack，恶意行为者需要能够： -- 拥有对 VCS platform 的 **write access**，因为 pipeline 通常在 push 或 pull request 执行时触发。（查看 VCS pentesting methodology 以总结获取访问权限的方法）。 +- 在 VCS platform 上拥有 **write access**，因为通常 pipelines 会在 push 或 pull request 被执行时触发。（查看 VCS pentesting methodology 以了解获取访问权限的方式总结）。 - 注意，有时 **external PR 也算作 "write access"**。 -- 即使他有 write permissions，他也需要确保自己能 **modify CI config file 或 config 依赖的其他文件**。 -- 为此，他可能需要能够 **bypass branch protections**。 +- 即使他有 write permissions，他也需要确保自己能够 **修改 CI config file 或 config 依赖的其他 files**。 +- 为此，他可能需要能够 **绕过 branch protections**。 -PPE 有 3 种变体： +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**。 +- **D-PPE**: 当行为者 **修改** 将要执行的 CI config 文件时，会发生 **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 会 **设置 environment variables**，其中包含有关 PR 的 **信息**。如果该值可被攻击者控制（例如 PR 的标题），并且在 **危险位置** 被 **使用**（例如执行 **sh commands**），攻击者可能会在其中 **注入 commands**。 ### Exploitation Benefits -了解 poison pipeline 的 3 种变体后，看看成功利用后 attacker 能得到什么： +了解污染 pipeline 的 3 种形式后，接下来看看攻击者在成功利用后可以获得什么： -- **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 中运行的代码**。 +- **Secrets**: 如前所述，pipelines 的 jobs 需要 **权限**（检索代码、构建、部署等），而这些权限通常以 **secrets** 形式授予。这些 secrets 通常可以通过 **env variables 或系统内的 files** 访问。因此，攻击者总会尝试尽可能多地外传 secrets。 +- 根据 pipeline platform 的不同，攻击者 **可能需要在 config 中指定 secrets**。这意味着如果攻击者无法修改 CI configuration pipeline（例如 **I-PPE**），他就 **只能外传该 pipeline 已有的 secrets**。 +- **Computation**: 代码会在某处执行，根据执行位置，攻击者可能能够进一步 pivot。 +- **On-Premises**: 如果 pipelines 在本地环境执行，攻击者可能最终进入一个 **内部网络，并访问更多资源**。 +- **Cloud**: 攻击者不仅可以访问 cloud 中的 **其他 machines**，还可以从中 **外传** IAM roles/service accounts **tokens**，以获得 cloud 内部的进一步访问权限。 +- **Platforms machine**: 有时 jobs 会在 **pipelines platform machines** 内执行，这些机器通常位于一个 cloud 中，并且 **没有更多访问权限**。 +- **Select it:** 有时 **pipelines platform 会配置多台 machines**，如果你能 **修改 CI configuration file**，你就可以 **指定想要在哪台机器上运行恶意代码**。在这种情况下，攻击者很可能会在每一台可能的机器上运行 reverse shell，以尝试进一步利用它。 +- **Compromise production**: 如果你在 pipeline 中，并且最终版本是从那里构建和部署的，你就可以 **破坏最终会在 production 中运行的代码**。 ### Dependency & Registry Supply-Chain Abuse -攻陷 CI/CD pipeline 或从中窃取凭证，可能让 attacker 从 **pipeline execution** 进一步走向 **ecosystem-wide code execution**，方法是对 dependencies 或 release tooling 做后门植入： +破坏 CI/CD pipeline 或从中窃取凭证，可能让攻击者通过后门化 dependencies 或 release tooling，从 **pipeline execution** 转向 **ecosystem-wide code execution**： -- **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 变成其他环境中的下游自动执行。 +- **Install-time code execution via package hooks**: 发布一个 package version，添加 `preinstall`、`postinstall`、`prepare` 或类似 hooks，使 payload 在 dependency installation 期间自动在开发者工作站和 CI runners 上运行。 +- **Secondary execution paths**: 即使目标使用 `--ignore-scripts` 安装，恶意 package 仍可在 `bin` 字段中注册一个 **common CLI name**，从而将攻击者控制的 wrapper 通过 symlink 放入 `PATH`，并在之后命令被使用时执行。 +- **Runtime bootstrapping**: 一个小型 installer 可以在安装期间下载第二个 runtime 或 toolchain（例如 Bun 或一个打包好的 interpreter），然后用它启动主 payload，从而避免本地依赖要求。 +- **Credential harvesting from build environments**: 一旦 code 在 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`** permissions 的 token 足以创建一个 branch，在 `.github/workflows/` 中提交一个恶意文件，触发它，收集生成的 artifacts/logs，然后删除临时 branch/workflow run 以减少痕迹。 +- **Wormable registry propagation**: 被窃取的 npm tokens 应验证是否具有 **publish** 权限以及是否绕过 2FA。如果可以，枚举可写 packages，下载它们的 tarballs，注入一个类似 `setup.mjs` 的 loader，将 `preinstall` 设为执行它，提升 patch version，并重新发布。这样就会把一次 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。 +- 审查 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。 +- 如果怀疑某个 package 已被 compromise，请检查已发布的 tarball，而不仅仅是 Git repository，因为恶意 loader/runtime 可能只存在于已发布的 artifact 中。 +- 在 CI 中排查意外的 package-manager execution，例如使用 `npm install` 而不是 `npm ci`、意外的 Bun downloads/execution，或由临时 branches 生成的新 workflow artifacts。 +- 也要将 GitOps deployment engines 视为 CI/CD targets。Argo CD-specific enumeration、repo-server abuse 和 Redis cache poisoning attacks 在 [Argo CD Security](argocd-security.md) 中有介绍。 ## 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) 审计软件 supply chain stack 的安全合规性。该审计关注整个 SDLC process，可揭示从 code time 到 deploy time 的风险。 +- [**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) 审计你的 software 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/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) +查看这篇有趣的文章，了解 Cider 评出的 CI/CD top 10 risks: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) ### Labs -- 在每个平台上，如果你可以本地运行，你都会找到如何在本地启动它，以便你按需配置并测试它 +- 在每个平台上，如果你可以在本地运行，你都会找到如何在本地启动它的方法，这样你就可以按需配置它来进行测试 - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat) ### Automatic Tools