CI/CD Goat Easy Challenges

Introduction and setup

CI/CD Goat is a deliberately vulnerable CI/CD environment made to practice pentesting and learning common CI/CD vulnerabilities and misconfigurations. This walkthrough will provide directions and explanations for how to solve the easy challenges. Shoutout to Cider Security for creating such an awesome set of challenges. The details for the project can all be found in the Github repo, and I encourage you to check it out before beginning. Just a few notes: First of all, this walkthrough assumes you have a basic working knowledge of git. If you don’t, nothing here is too complicated, and can be easily learned with a quick google search. Second, This project creates the vulnerable environment through Docker, which must be installed on the system before continuing. Lastly, I’m running this inside my Kali VM, which is why all IP addresses are 127.0.0.1. You can run the project on your host machine, or on another PC, and the IP will be different. To get started, run the following to download the docker-compose.yml file, and bring the project up:

1
2

curl -o cicd-goat/docker-compose.yaml --create-dirs https://raw.githubusercontent.com/cider-security-research/cicd-goat/main/docker-compose.yaml
cd cicd-goat && docker compose up -d

Wait a minute for the pipeline to fully come up before starting. Log in to the CTFd dashboard at http://127.0.0.1:8000/challenges with the credentials alice:alice.

Easy Challenge #1: White Rabbit

White rabbit is a pretty basic challenge that is the base for a few of the future challenges. It involves modifying the jenkinsfile for the Wonderland/white-rabbit repo in order to pull secrets out of jenkins. Start by logging in to the Gitea server at http://127.0.0.1:3000/ with the credentials thealice:thealice, and cloning the white-rabbit repo. Before making any changes, create a new branch, as alice is not allowed to push changes to main. The following section can now be added to the jenkinsfile:

1
2
3
4
5
6
7
8
9

stage ('Hack all the things') {
    steps {
        withCredentials([string(credentialsId: 'flag1', variable: 'TOKEN')]) {
            sh '''
            echo $TOKEN | base64
            '''
        }
    }
}

The withCredentials tells jenkins to use a credential from the Jenkins credential store and assign it to a variable, which can be used in the command. In this case, we are base64 encoding it, because Jenkins will automatically mask credentials in build logs. After making the changes, push your new branch, and open a pull request in Gitea to merge your changes into main. This will kick off a jenkins build with the new malicious build step. Log into Jenkins at http://localhost:8080 with the credentials alice:alice, go to the build logs for your PR, and view the logs for the stage you added. It should look something like this:

Easy Challenge #2: Mad Hatter

Mad hatter is a similar challenge to the previous one, but with the twist that the jenkins file is stored in its own repository at http://127.0.0.1:3000/Wonderland/mad-hatter-pipeline, which we don’t have permission to modify. However, we can see that the following stage is included in the Jenkinsfile:

1
2
3
4
5
6
7

stage('make'){
    steps {
        withCredentials([usernamePassword(credentialsId: 'flag3', usernameVariable: 'USERNAME', passwordVariable: 'FLAG')]) {
        sh 'make || true'
        }
    }           
}

With this info, we can proceed to edit the Makefile in the mad-hatter repo to reveal Flag3. As in challenge 1, clone the mad-hatter repo, create a new branch, and change the file contents to the following:

1
2

whoami:
	echo ${FLAG} | base64

Open and merge a PR, and wait for the project to build. The flag will be in the logs for the “make” section.

Easy Challenge #3: Duchess

Challenge 3 is different from the first 2, as it doesn’t involve the jenkins pipeline at all. This challenge is a reminder to never commit secrets to git, and to fully scrub them from the history if you do. The challenge description implies there is a PyPi token to be found somewhere, and that somewhere is the git history. We can search the repo history for commits that mention pypi with the following command:

1

git log | grep 'pypi' -B 10

The results show the following:

1
2
3
4
5

commit 325953439a58589bc26b42f067179fb5227e1317
Author: Asaf <[email protected]>
Date:   Tue Nov 16 11:24:35 2021 +0200

    remove pypi token

We can retrieve the changes made in that commit by running the following:

1

git show 325953439a58589bc26b42f067179fb5227e1317

The flag is the full token.