8.2 KiB
Pentesting CI/CD Methodology
{{#include ../banners/hacktricks-training.md}}
VCS
VCS stands for Version Control System, 该系统允许开发者去manage their source code。最常见的是 git，通常公司会在以下这些platforms之一使用它：
- Github
- Gitlab
- Bitbucket
- Gitea
- Gitblit
- Cloud providers (they offer their own VCS platforms)
CI/CD Pipelines
CI/CD pipelines 使开发者能够automate the execution of code，用于多种用途，包括构建、测试和部署应用程序。这些自动化工作流会被specific actions触发，例如 code pushes、pull requests 或定时任务。它们有助于简化从开发到生产的流程。
然而，这些系统需要在某处执行，而且通常需要privileged credentials to deploy code or access sensitive information。
VCS Pentesting Methodology
Note
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.
存放项目源代码的平台包含敏感信息，因此需要非常小心在该平台上授予的权限。以下是攻击者可能滥用的一些常见问题：
- Leaks: 如果你的代码在 commits 中包含 leaks，并且攻击者能够访问 repo（因为它是 public 或者他已有访问权限），他就可能发现这些 leaks。
- Access: 如果攻击者能访问 VCS platform 中的账号，他可能获得更多的可见性和权限。
- Register: 有些平台会允许外部用户直接创建账号。
- SSO: 有些平台不允许普通注册，但会允许任何拥有有效 SSO 的人访问（例如攻击者可以用他的 github 账号登录）。
- Credentials: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... 用户可能会被窃取各种类型的 tokens 来以某种方式访问 repo。
- Webhooks: VCS platforms 允许生成 webhooks。如果它们没有用不可见的 secrets 进行保护，attacker could abuse them。
- If no secret is in place, the attacker could abuse the webhook of the third party platform
- If the secret is in the URL, the same happens and the attacker also have the 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 最常见的方式是使用存放在仓库内的 CI configuration file。该文件描述了执行作业的顺序、影响流程的条件以及构建环境设置。
这些文件通常有一致的名称和格式，例如 — Jenkinsfile (Jenkins)、.gitlab-ci.yml (GitLab)、.circleci/config.yml (CircleCI)，以及位于 .github/workflows 的 GitHub Actions YAML 文件。被触发时，pipeline job 会pulls the code 从所选的 source（例如 commit / branch），并对该代码runs the commands specified in the CI configuration file。
因此攻击者的最终目标是以某种方式compromise those configuration files 或者compromise the commands they execute。
PPE - Poisoned Pipeline Execution
Poisoned Pipeline Execution (PPE) 路径利用 SCM 仓库中的权限来操纵 CI pipeline 并执行有害命令。拥有必要权限的用户可以修改 CI configuration files 或 pipeline job 所使用的其他文件以加入恶意命令。这会“poison” CI pipeline，导致这些恶意命令被执行。
要成功实施 PPE 攻击，恶意行为者需要能够：
- 拥有 write access to the VCS platform，因为 pipeline 通常在 push 或 pull request 时被触发。（查看 VCS pentesting methodology 以获取获取访问权限方式的汇总）。
- 注意有时一个external PR 就算作 “write access”。
- 即使拥有 write 权限，他也要确保能modify the CI config file 或其它 CI 配置依赖的文件。
- 为此，他可能需要能够bypass branch protections。
PPE 有 3 种变体：
- D-PPE: Direct PPE 发生在攻击者直接修改将被执行的 CI config 文件时。
- I-DDE: Indirect PPE 发生在攻击者修改 CI config 所依赖的文件（例如 make file 或 terraform config）时。
- Public PPE or 3PE: 在某些情况下，pipelines 可以被没有写权限的用户触发（这些用户可能甚至不是 org 的成员），因为他们可以发送 PR。
- 3PE Command Injection: 通常，CI/CD pipelines 会用关于 PR 的信息来set environment variables。如果这些值能被攻击者控制（例如 PR 的标题），并且被used 在危险位置（比如执行 sh commands），攻击者可能会inject commands。
Exploitation Benefits
了解了三种 poison pipeline 的方式后，来看攻击者在成功利用后可能获得的收益：
- Secrets: 如前所述，pipelines 的 jobs 需要privileges（检出代码、构建、部署等），这些权限通常以secrets 的形式授予。这些 secrets 通常可以通过 env variables 或系统内部的文件访问。因此攻击者会尽可能地尝试 exfiltrate 尽可能多的 secrets。
- 根据 pipeline 平台的不同，攻击者可能需要在配置中指定 secrets。这意味着如果攻击者无法修改 CI configuration pipeline（例如 I-PPE），他可能只能 exfiltrate 该 pipeline 所拥有的 secrets。
- Computation: 代码在某处被执行，攻击者可能据此 pivot 到更多目标。
- On-Premises: 如果 pipelines 在本地执行，攻击者可能会进入内部网络并访问更多资源。
- Cloud: 攻击者可能访问云中的其他机器，也可能exfiltrate IAM roles/service accounts tokens，以获得云内的进一步访问权限。
- Platforms machine: 有时作业会在 pipelines platform machines 内执行，这些机器通常位于云中且没有更多访问。
- Select it: 有时 pipelines platform 会配置多台机器，如果你能modify the CI configuration file，你可以指定想在哪里运行恶意代码。在这种情况下，攻击者可能会在每台可选机器上运行 reverse shell，尝试进一步利用。
- Compromise production: 如果你已经进入 pipeline，且最终版本由其构建并部署，你就可以compromise the code that is going to end running in production。
More relevant info
Tools & CIS Benchmark
- Chain-bench 是一个开源工具，用于根据新的 CIS Software Supply Chain benchmark 对你的软件供应链堆栈进行安全合规性审计。审计聚焦于整个 SDLC 流程，可以揭示从 code time 到 deploy time 的风险。
Top 10 CI/CD Security Risk
查看 Cider 关于前十个 CI/CD 风险的有趣文章： https://www.cidersecurity.io/top-10-cicd-security-risks/
Labs
- 在每个平台的本地运行版本中，你可以找到如何在本地启动以便按需配置和测试的说明
- Gitea + Jenkins lab: https://github.com/cider-security-research/cicd-goat
Automatic Tools
- Checkov: Checkov 是一个面向 infrastructure-as-code 的静态代码分析工具。
References
{{#include ../banners/hacktricks-training.md}}