By David Fiser
Jenkins is a popular open-source automation server for software development teams. Used for managing the development side in DevOps, the main purpose of Jenkins is to perform tasks, called jobs, such that software project builds are automatically developed in the CI/CD process.
Jenkins has a distributed architecture: A master machine manages a group of agents (aka slaves), which are Java executables running on remote machines and that execute build jobs. Jenkins is also based on a modular architecture, and most of its features are implemented inside plugins that extend its core functionality, for example, post-build tasks.
The convenience offered by Jenkins also covers security aspects through its matrix-based model, not to mention how it’s easier to just pull an official Jenkins image from Docker Hub. However, working under default settings and enabling Jenkins’ matrix-based security might lead developers to assume that it’s already a secure setup. Unfortunately, we discovered that this can lead to potential security problems.
In our analysis, we observed that a user account with less privilege can gain administrator rights over the automation server if jobs are built on the master machine (i.e., the main Jenkins server), a setup enabled by default. An exploit for this can be easily written using shell spawn — a default build step. If an exploit is successfully deployed, an attacker can perform remote code execution (RCE) on the master, which can result to Jenkins being completely overwritten.
An unsecure or lax configuration of these ..
Support the originator by clicking the read the rest link below.
