========================================
Click the Above Photo to View the Answers — — |
========================================
One of the main reasons for acquiring AntarctiCrafts was for their crafty automation in gift-giving, wrapping, and crafting. After securing their automation, they discovered other parts of their CI/CD environment that are used to build and extend their pipeline. An attacker can abuse these build systems to indirectly poison the previously secured pipeline.
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.
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.
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.
git clone http://MACHINE-IP:3000/McHoneyBell/gift-wrapper.git
nano Makefile
and change the command to uname -a
git add .
git commit -m "Message"
git push
http://MACHINE-IP:8080/
admin:admin
======================================================
Ans: Use your Skills and try to find this answer,
If you are unable to do so,
use the video below to find the answer
=======================================================
Similarly, change the below command in the Makefile and find the Value
Ans: 90e748eafdd2af4746a5ef7941e63272f24f1e33a2882f614ebfa6742e772ba7