Pentesting CI/CD Methodology
VCS
VCS代表版本控制系统，这些系统允许开发者管理他们的源代码。最常见的是git，你通常会发现公司在以下平台中使用它：
Github
Gitlab
Bitbucket
Gitea
云服务提供商（他们提供自己的VCS平台）
Pipelines
Pipelines允许开发者自动执行代码（用于构建、测试、部署等目的）在某些操作发生后：一个推送、一个PR、cron... 它们对于自动化从开发到生产的所有步骤非常有用。
然而，这些系统需要在某个地方执行，通常需要具有部署代码的特权凭证。
VCS Pentesting Methodology
即使一些VCS平台允许创建pipelines，但在本节中，我们将只分析对源代码控制的潜在攻击。
包含项目源代码的平台包含敏感信息，人们需要非常小心在这个平台内授予的权限。以下是VCS平台中常见的一些问题，攻击者可以利用：
泄露：如果您的代码在提交中包含泄露，并且攻击者可以访问仓库（因为它是公开的或因为他有访问权限），他可以发现泄露。
访问：如果攻击者可以访问VCS平台内的账户，他可以获得更多的可见性和权限。
注册：一些平台将允许外部用户创建账户。
SSO：一些平台不允许用户注册，但允许任何人使用有效的SSO访问（因此攻击者可以使用他的github账户进入，例如）。
凭证：用户名+密码、个人令牌、ssh密钥、Oauth令牌、cookies... 用户可以窃取多种类型的令牌以某种方式访问仓库。
Webhooks：VCS平台允许生成webhooks。如果它们没有用不可见的秘密保护，攻击者可以滥用它们。
如果没有设置秘密，攻击者可以滥用第三方平台的webhook
如果秘密在URL中，情况也是如此，攻击者还拥有秘密
代码妥协：如果恶意行为者对仓库有某种写权限，他可以尝试注入恶意代码。为了成功，他可能需要绕过分支保护。这些行动可以出于不同的目标进行：
妥协主分支以妥协生产。
妥协主分支（或其他分支）以妥协开发者的机器（因为他们通常在他们的机器上执行测试、terraform或仓库中的其他事情）。
妥协pipeline（查看下一节）
Pipelines Pentesting Methodology
定义pipeline的最常见方式是使用存储在仓库中的CI配置文件，pipeline构建。这个文件描述了执行作业的顺序、影响流程的条件和构建环境设置。 这些文件通常有一个一致的名称和格式，例如 - Jenkinsfile（Jenkins）、.gitlab-ci.yml（GitLab）、.circleci/config.yml（CircleCI）和位于.github/workflows下的GitHub Actions YAML文件。当触发时，pipeline作业从选定的源拉取代码（例如提交/分支），并对该代码运行CI配置文件中指定的命令。
因此，攻击者的终极目标是以某种方式妥协这些配置文件或它们执行的命令。
PPE - Poisoned Pipeline Execution
Poisoned Pipeline Execution（PPE）路径利用SCM仓库中的权限来操纵CI pipeline并执行有害命令。具有必要权限的用户可以修改CI配置文件或pipeline作业使用的其他文件，以包含恶意命令。这“毒化”了CI pipeline，导致这些恶意命令的执行。
要成功执行PPE攻击，恶意行为者需要能够：
拥有对VCS平台的写权限，因为通常当执行推送或拉取请求时会触发pipelines。（查看VCS渗透测试方法论以获取获取访问权限的总结）。
请注意，有时外部PR也算作“写权限”。
即使他拥有写权限，他还需要确保他可以修改CI配置文件或配置文件所依赖的其他文件。
为此，他可能需要能够绕过分支保护。
PPE有3种形式：
D-PPE：直接PPE攻击发生在行为者修改将要执行的CI配置文件时。
I-DDE：间接PPE攻击发生在行为者修改CI配置文件将要执行的依赖文件时（如make文件或terraform配置）。
公共PPE或3PE：在某些情况下，pipelines可以由没有仓库写权限的用户触发（他们甚至可能不是组织的一部分），因为他们可以发送PR。
3PE命令注入：通常，CI/CD pipelines会设置环境变量，其中包含关于PR的信息。如果攻击者可以控制该值（如PR的标题），并且在危险的地方使用（如执行sh命令），攻击者可能会在那里注入命令。
利用的好处
了解了毒化pipeline的3种方式，让我们检查攻击者在成功利用后可以获得什么：
秘密：如前所述，pipelines需要权限来执行它们的作业（检索代码、构建它、部署它...），这些权限通常是以秘密的形式授予的。这些秘密通常可以通过环境变量或系统内的文件访问。因此，攻击者将始终尝试尽可能多地窃取秘密。
根据pipeline平台，攻击者可能需要在配置中指定秘密。这意味着如果攻击者不能修改CI配置pipeline（例如I-PPE），他只能窃取该pipeline拥有的秘密。
计算：代码在某处执行，根据执行地点，攻击者可能能够进一步渗透。
本地：如果pipelines在本地执行，攻击者可能会结束在一个内部网络中，可以访问更多资源。
云：攻击者可以访问云中的其他机器，但也可以窃取IAM角色/服务账户令牌，以在云中获得进一步的访问权限。
平台机器：有时作业将在pipeline平台机器内执行，这些机器通常位于一个没有更多访问权限的云中。
选择它：有时pipeline平台将配置有几台机器，如果你可以修改CI配置文件，你可以指示你想在哪里运行恶意代码。在这种情况下，攻击者可能会在每台可能的机器上运行一个反向shell，以尝试进一步利用它。
妥协生产：如果你在pipeline内部，最终版本是从中构建和部署的，你可以妥协最终将在生产中运行的代码。
更多相关信息
工具 & CIS基准
Chain-bench 是一个开源工具，用于根据新的CIS软件供应链基准对您的软件供应链堆栈进行安全合规性审计。审计关注整个SDLC过程，可以揭示从代码时间到部署时间的风险。
前10名CI/CD安全风险
查看Cider根据Cider的说法前10名CI/CD风险的这篇有趣文章：https://www.cidersecurity.io/top-10-cicd-security-risks/
实验室
在每个你可以在本地运行的平台上，你会发现如何在本地启动它，这样你就可以根据你的需求配置它进行测试
Gitea + Jenkins实验室：https://github.com/cider-security-research/cicd-goat
自动化工具
Checkov：Checkov是一个用于基础设施即代码的静态代码分析工具。
参考资料
Last updated
