Cicd Pipeline Attack

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

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

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

深入参考

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

• GitHub Actions 专项攻击手法 → 读 references/github-actions-abuse.md
• Jenkins / Terraform / Atlantis / GitLab CI / Azure DevOps / CircleCI / Drone / Buildkite 等平台 → 读 references/platform-specific.md
• 跨平台构建文件注入（package.json、setup.py、Makefile、Bazel、Maven/Gradle、csproj）→ 读 references/build-file-injection.md

Phase 0: CI/CD 系统识别

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

快速识别技巧：

• 克隆仓库后搜索配置文件：查找 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 分支保护绕过

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

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 引号转义无法防御。

危险触发器对比：

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 穿越到云环境的桥梁：

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

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

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

4.4 其他平台速查

注意事项

操作安全：

• 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 事件）