cicd-pipeline-attack

Name: cicd-pipeline-attack
Author: wgpsec/AboutSecurity
$npx mdskill add wgpsec/AboutSecurity/cicd-pipeline-attack
Execute CI/CD pipeline attacks on GitHub Actions, Jenkins, and GitLab.
Test poisoned pipeline execution and supply chain compromise risks.
Integrates with GitHub Actions, Jenkins, GitLab CI, and Terraform.
Uses decision trees to select attack vectors based on platform.
Delivers actionable exploit paths for secrets theft and cloud access.
SKILL.md
.github/skills/cicd-pipeline-attackView on GitHub ↗
---
name: cicd-pipeline-attack
description: "CI/CD 流水线与供应链攻击方法论。当发现目标使用 GitHub Actions/Jenkins/GitLab CI/CircleCI/Terraform Cloud/Atlantis 等 CI/CD 系统、需要测试流水线安全性、或发现 .github/workflows/Jenkinsfile/.gitlab-ci.yml 等配置文件时使用。覆盖 PPE（Poisoned Pipeline Execution）三种攻击模式（D-PPE/I-PPE/3PE）、VCS 代码仓库攻击面（代码泄露/Webhook 滥用/分支保护绕过）、Pipeline Secrets 窃取与横向移动、以及从 CI/CD 到云环境的穿越路径"
metadata:
  tags: "cicd,pipeline,github-actions,jenkins,gitlab,terraform,atlantis,supply-chain,PPE,poisoned-pipeline,secrets,VCS,webhook,CI/CD攻击,供应链,流水线"
  category: "cloud"
---

# CI/CD 流水线与供应链攻击方法论

CI/CD 系统是现代软件工程的核心基础设施——它们拥有代码仓库的读写权限、持有云平台的部署凭据、能够直接修改生产环境。一旦攻陷流水线，攻击者可以同时获得代码控制权、Secrets 访问权和云环境穿透能力，其影响范围远超单台服务器的沦陷。

本技能以决策树形式组织 CI/CD 攻击方法论。各平台的详细技术手法请参阅对应的参考文档。

## 深入参考

识别到具体平台后，加载对应参考文档获取完整攻击技术细节：

- GitHub Actions 专项攻击手法 → 读 [references/github-actions-abuse.md](references/github-actions-abuse.md)
- Jenkins / Terraform / Atlantis / GitLab CI 等平台 → 读 [references/platform-specific.md](references/platform-specific.md)

## Phase 0: CI/CD 系统识别

在目标代码仓库或基础设施中发现以下标识文件时，可确定对应的 CI/CD 平台：

| 标识文件/特征 | CI/CD 平台 | 下一步 |
|---|---|---|
| `.github/workflows/*.yml` | GitHub Actions | → Phase 2 PPE + 参考 github-actions-abuse.md |
| `Jenkinsfile` 或 `/script` 控制台 | Jenkins | → Phase 4 Jenkins 专项 + 参考 platform-specific.md |
| `.gitlab-ci.yml` | GitLab CI | → Phase 2 PPE + 参考 platform-specific.md |
| `.circleci/config.yml` | CircleCI | → Phase 2 PPE + 参考 platform-specific.md |
| `atlantis.yaml` + Webhook | Atlantis | → Phase 4 Atlantis 专项 |
| `*.tf` + Terraform Cloud | Terraform Cloud | → Phase 4 Terraform 专项 |
| `serverless.yml` | Serverless Framework | → 参考 platform-specific.md |
| `docker-compose.yml` + CI 触发 | Docker Build | → 检查构建上下文泄露 |
| Airflow DAGs / Concourse pipeline | Airflow / Concourse | → 参考 platform-specific.md |

**快速识别技巧：**
- 克隆仓库后搜索配置文件：查找 `Jenkinsfile`、`.github/workflows`、`.gitlab-ci.yml`、`.circleci`、`atlantis.yaml`
- 检查 Webhook 配置：Webhook URL 暴露 CI/CD 服务类型和内网地址
- 枚举 CI/CD 服务端口：Jenkins 默认 8080，Atlantis 默认 4141，GitLab Runner 8093

## Phase 1: VCS 攻击面

在进入流水线攻击之前，VCS（版本控制系统）本身就是重要的攻击面。

### 1.1 代码泄露

代码仓库中常见的敏感信息来源：

- **Git 历史记录**：已删除的密钥/凭据可能仍在 commit 历史中（`git log -p` 搜索所有分支）
- **公开仓库**：使用 GitHub Dork 搜索组织名称 + 关键词（`password`、`secret`、`token`、`AWS_`）
- **已删除的 Fork 数据**：GitHub 上已删除的 fork 中的 commit 数据仍可通过 commit hash 访问
- **内部仓库暴露**：private 仓库变 public 前的 fork 数据可通过短 SHA-1 暴力枚举

### 1.2 分支保护绕过

分支保护是防止恶意代码合入的关键防线，但存在多种绕过方式：

| 绕过场景 | 条件 | 攻击方法 |
|---|---|---|
| 审批不足 | 控制多个账户 | 使用其他账户审批自己的 PR |
| GITHUB_TOKEN 自审批 | Actions 有写权限 | 通过 Actions 中的 GITHUB_TOKEN 审批 PR |
| 推送后审批未失效 | 未启用 "dismiss on push" | 先提交合法代码获得审批，再推送恶意代码 |
| CODEOWNERS 配置错误 | 文件格式有误 | GitHub 不报错但 CODEOWNERS 保护失效 |
| 新分支无保护 | 使用通配符 `*` 但有延迟 | 创建新分支时分支保护尚未生效，第一次 push 可触发 Actions |
| 管理员豁免 | 管理员未纳入规则 | 管理员可直接绕过所有分支保护 |
| PR 劫持 | 可修改他人 PR | 在他人的 PR 中注入恶意代码后自行审批合并 |

### 1.3 Webhook 滥用

- **无 Secret 验证**：攻击者可伪造 Webhook 请求触发流水线
- **Secret 暴露在 URL 中**：Secret 附在 URL 参数中，易被日志记录
- **IP 白名单绕过**：在 GitHub/GitLab 上创建账户配置 Webhook 即可向白名单内的 Jenkins/Atlantis 发送请求
- **Bitbucket Cloud**：不支持 Webhook Secret，只能依赖 IP 白名单

## Phase 2: PPE -- Poisoned Pipeline Execution

PPE 是 CI/CD 攻击的核心框架。攻击者通过修改 CI 配置文件或其依赖文件来"毒化"流水线，使其执行恶意命令。

### PPE 判定决策树

```
是否能写入/修改 CI 配置文件（workflow yml / Jenkinsfile / .gitlab-ci.yml）？
├── 是 → D-PPE（直接毒化）
│   ├── 能直接推送到触发分支 → 最简单路径
│   └── 需要 PR → 检查 PR 是否触发流水线
│
├── 否，但能修改 CI 配置依赖的文件？
│   ├── Makefile / build.sh / package.json / requirements.txt → I-PPE（间接毒化）
│   ├── Terraform .tf 文件 → I-PPE via external data source
│   └── Dockerfile → I-PPE via build context
│
└── 否，且无仓库写权限？
    └── 3PE（第三方毒化）
        ├── 能否提交外部 PR？ → pull_request 触发器
        ├── PR 标题/描述是否被注入到 shell 命令？ → Context Script Injection
        └── 能否通过 issue/comment 触发？ → issue_comment 触发器
```

### D-PPE（Direct PPE）

攻击者直接修改 CI 配置文件。这是最直接的攻击路径：

- **前提**：拥有仓库写权限，或能通过 PR 触发使用 PR 分支配置的流水线
- **目标文件**：`.github/workflows/*.yml`、`Jenkinsfile`、`.gitlab-ci.yml`、`.circleci/config.yml`
- **关键条件**：某些平台（如 GitHub Actions 的 `pull_request` 触发器）会使用 PR 提交者的 workflow 版本——这意味着攻击者的修改会被执行

### I-PPE（Indirect PPE）

攻击者不修改 CI 配置文件本身，而是修改 CI 配置所依赖的文件：

- **构建脚本**：`Makefile`、`build.sh`、`package.json` 的 `scripts` 字段
- **依赖文件**：`requirements.txt`、`package-lock.json`（供应链注入）
- **IaC 配置**：Terraform `.tf` 文件中的 `external` data source 或 `local-exec` provisioner
- **Docker 构建**：控制 Dockerfile 或构建上下文路径

I-PPE 的局限性在于攻击者只能访问流水线原本就加载的 Secrets，无法通过配置声明新的 Secret 引用。

### 3PE（Third-Party PPE / Public PPE）

无仓库写权限的外部攻击者通过以下方式触发流水线：

**Context Script Injection（最常见）：**

当 CI 配置使用 `${{ github.event.pull_request.title }}` 等用户可控表达式在 `run:` 步骤中拼接 shell 命令时，攻击者可通过 PR 标题注入命令。GitHub Actions 在执行前先渲染表达式，所以 shell 引号转义无法防御。

**危险触发器对比：**

| 触发器 | Secrets 访问 | 写权限 | 使用的代码版本 | 风险 |
|---|---|---|---|---|
| `pull_request` | 无（GITHUB_TOKEN 只读） | 无 | PR 分支 | 低（但可上传恶意 Artifact） |
| `pull_request_target` | 有 | 有 | 基础分支（默认安全） | 高（若 checkout PR 代码则极危险） |
| `workflow_run` | 有 | 有 | 取决于配置 | 高（常被链式利用） |
| `issue_comment` | 有 | 有 | 基础分支 | 高（结合 checkout PR ref 可 RCE） |

**`pull_request_target` 的致命误用：**

虽然 `pull_request_target` 在基础分支上下文运行（看似安全），但如果 workflow 中显式 checkout 了 PR 的代码（`ref: ${{ github.event.pull_request.head.sha }}`），则攻击者的代码会在拥有 Secrets 和写权限的环境中执行。

## Phase 3: Secrets 窃取与横向移动

成功毒化流水线后，核心目标是窃取 Secrets 并向外扩展。

### 3.1 Secrets 提取方法

**环境变量：**
- `env | base64` 导出所有环境变量（base64 编码可绕过 GitHub 的日志掩码）
- 双重 base64 编码进一步绕过掩码：`echo '${{ toJson(secrets) }}' | base64 -w0 | base64 -w0`

**文件系统：**
- 临时脚本文件：`/home/runner/work/_temp/*`（GitHub Actions 存储渲染后的脚本）
- 进程内存：`gcore` 或 `/proc/<pid>/mem` 读取 Runner.Worker/Runner.Listener 进程中的明文 Secrets

**无法直接外传时：**
- 使用 GITHUB_TOKEN 创建仓库/issue/comment 作为数据中转
- 将 Secrets 写入 Artifact 上传
- 写入 Actions 日志（注意掩码规则）

### 3.2 CI/CD 到云环境穿越

CI/CD Runner 通常拥有云平台凭据用于部署。这些凭据是从 CI/CD 穿越到云环境的桥梁：

| 凭据来源 | 位置 | 利用方式 |
|---|---|---|
| OIDC Token（GitHub → AWS/GCP/Azure） | `id-token: write` 权限 | 请求 OIDC Token → AssumeRoleWithWebIdentity |
| AWS 静态 AK/SK | 环境变量或 Secrets | 参考 `cloud-aksk-exploit` 技能 |
| GCP Service Account JSON | 文件或环境变量 | 参考 `gcp-pentesting` 技能 |
| Azure Service Principal | 环境变量 | 参考 `aws-pentesting` 技能中的 Azure 相关内容 |
| Terraform Cloud Runner 凭据 | `tfc-aws-*`/`tfc-gcp-*` 文件 | 直接使用 CLI 操作云资源 |
| Kubernetes kubeconfig | `~/.kube/config` 或挂载的 SA Token | 集群接管 |
| Docker Registry Token | `~/.docker/config.json` | 推送恶意镜像 |

**Self-hosted Runner 额外攻击面：**
- 云元数据服务（169.254.169.254）→ 获取实例绑定的 IAM 角色凭据
- 内网横向移动 → 访问内网其他服务
- Docker API（2375/tcp）→ 容器逃逸
- Kubernetes 集群访问 → DaemonSet 横向扩展

### 3.3 生产环境接管

如果流水线直接负责生产部署：

- **代码篡改**：在构建产物中注入后门代码
- **供应链攻击**：篡改 npm/PyPI 包发布流程（窃取 publish token → 发布恶意版本）
- **镜像投毒**：修改 Docker 镜像层注入恶意代码
- **IaC 篡改**：修改 Terraform/CloudFormation 配置创建后门资源

## Phase 4: 平台专项攻击

### 4.1 GitHub Actions

GitHub Actions 是最广泛使用的 CI/CD 平台之一，攻击面丰富：

- **Artifact Poisoning**：低权限 workflow 上传恶意 Artifact → 高权限 workflow 下载并执行
- **Cache Poisoning**：跨 workflow 共享的缓存无信任隔离 → 毒化缓存中的脚本/二进制文件
- **GITHUB_TOKEN 滥用**：合并 PR、审批 PR、创建 PR
- **Action Tag 劫持**：攻击者获取 Action 仓库写权限后 force-push 标签指向恶意 commit
- **AI Agent 注入**：CI 中的 LLM Agent（Gemini/Claude Code Action）可被 prompt injection 控制

→ 读 [references/github-actions-abuse.md](references/github-actions-abuse.md)

### 4.2 Jenkins

Jenkins 的高权限特性使其成为高价值目标：

- **Groovy Script Console**（`/script`）→ 直接 RCE
- **Pipeline 创建/修改** → 通过 Jenkinsfile 执行任意命令
- **凭据转储** → Groovy 脚本导出 credentials.xml 中的所有密钥
- **文件读取 → RCE** → 读取 `master.key` + `hudson.util.Secret` → 离线解密所有凭据 → 伪造 remember-me Cookie

→ 读 [references/platform-specific.md](references/platform-specific.md)

### 4.3 Terraform / Atlantis

IaC 工具的攻击核心在于代码即执行：

- **Terraform Plan RCE**：`external` data source 或恶意 Provider 在 `plan` 阶段即可执行代码
- **Terraform Apply RCE**：`local-exec` provisioner 在 `apply` 阶段执行
- **State 文件篡改**：写入 state 文件注入恶意 provider → 下次 plan/apply 触发 RCE
- **Atlantis Plan 注入**：PR 中修改 `.tf` 文件触发 `atlantis plan` → 在 Atlantis 服务器上 RCE
- **Atlantis Custom Workflow**：当 `allow_custom_workflows=true` 时，`atlantis.yaml` 可定义任意执行步骤
- **Terraform Cloud Speculative Plan**：窃取 TFC Token → 触发 speculative plan → 在 Runner 上执行代码 → 获取注入的云凭据

→ 读 [references/platform-specific.md](references/platform-specific.md)

### 4.4 其他平台速查

| 平台 | 关键攻击路径 | 详情 |
|---|---|---|
| GitLab CI | Runner Token 窃取、共享 Runner 逃逸、CI 变量注入 | → platform-specific.md |
| CircleCI | Context Secrets 窃取、SSH Rerun、项目变量导入 | → platform-specific.md |
| Serverless Framework | IAM Role 提权（默认 AdministratorAccess）、Plugin 投毒 | → platform-specific.md |
| CloudFlare | Workers 滥用、Zero Trust 绕过 | → platform-specific.md |
| Concourse / Airflow | 参考 platform-specific.md 快速参照表 | → platform-specific.md |

## 注意事项

**操作安全：**
- CI/CD 系统通常有完整的审计日志——PR 创建、workflow 执行、Secrets 访问都会被记录
- GitHub 上的 PR 即使删除账户后仍可能被 SIEM 捕获
- Self-hosted Runner 上的操作可能触发 EDR/HIDS 告警
- 在授权测试中应事先与客户确认 CI/CD 测试范围和影响

**Secrets 保护绕过：**
- GitHub Actions 日志掩码只保护渲染输出，进程内存中仍存在明文
- 使用 base64 编码或加密可绕过大多数自动掩码机制
- JWT 签名值等派生数据不会被掩码

**供应链攻击升级：**
- 窃取到 npm/PyPI publish token 后可发布恶意包版本
- npm 的 `preinstall`/`postinstall` hook 在安装时自动执行
- Python 的 `.pth` 文件在解释器启动时自动执行
- 单个 CI/CD 沦陷可能级联影响整个供应链（参考 tj-actions/Ultralytics 事件）