Tools Resources Plans

Supply Chain Security

Weaponizing the Utility of Jenkins Script Consoles

Rami H.

Friday, Sep 15th, 2023

Jenkins misconfigurations can have far-reaching consequences; Cisco Panoptica’s attack surface scanner can detect such misconfigurations.

Jenkins is a widely used tool for continuous integration and continuous delivery and deployment (CI/CD). It allows enterprise developers to automate application delivery easily, either through an enterprise-hosted or a third-party hosted Jenkins service. DevOps teams provide Jenkins with configurations and scripts to handle the building, testing, and deployment of customer applications seamlessly and Jenkins does the rest.

Unfortunately, Jenkins misconfigurations can happen. Some of these misconfigurations could lead to serious consequences, like hackers gaining access to valuable credentials, source code, pipelines, and the injection of malicious code into pipeline builds. Given that these assets are crucial for cloud-based or on-premises applications and form the heart of many businesses, it's vital to avoid such mishaps.

That's where automatic scanning comes into play. It's essential to scan Jenkins and other CI/CD pipelines regularly to catch misconfigurations before they cause trouble. Even though mistakes are easy to make, they can be tricky to spot. Scanning helps security teams identify and fix issues early, preventing them from turning into major problems down the line.

In this blog, we address a common Jenkins misconfiguration problem and explore how automatic cloud attack-surface scans can be used to ensure your systems are safe from such misconfigurations and their potential consequences. It's all about keeping your applications and data secure while streamlining your development process.

Introduction

Continuous Integration/Continuous Delivery/Deployment (CI/CD) pipelines are sets of practices, tools, and workflows designed to automate the build, test, and deployment stages of software applications. These facilitate an integration between code repositories, and deployment environments, enabling a software development lifecycle (SDLC). CI focuses on integrating code changes from multiple contributors into a shared codebase, while CD encompasses the automated progress of stages of the pipeline.

One popular CI/CD pipeline tools is Jenkins, widely used by developers and DevOps teams. Jenkins offers a wide range of plugins and features, allowing for flexibility and automation in deploying complex software systems. Whether it is for deployment, staging, or production, Jenkins pipelines make continuous updates possible, providing DevOps teams with the agility they need.

Since Jenkins manages critical assets for enterprises and handles application deployments, it requires access to various credentials, like hyperscaler keys, Git, SSH keys, and more. To protect this sensitive information, Jenkins stores these credentials in a secure repository, often facilitated through the “Credentials Plugin”, accessible only through a management interface or the Jenkins pipelines themselves. However, if hackers manage to gain access to these interfaces, they can wreak havoc by tampering with software, misusing keys, stealing data, and more. Utmost vigilance is required to prevent unauthorized access to these interfaces.

One specific area of concern is the Groovy script console in Jenkins. It is a powerful console where Groovy, a Java-like language, Jenkins scripts can be executed. While it allows for intent-based operations, it also opens the door for complex pipeline scenarios using Groovy scripts. Proper protection of this interface is crucial. Unfortunately, some Jenkins deployments are exposed on the open Internet and are misconfigured, making them vulnerable to misuse. To address this, Cisco developed a scan utility to check if enterprises are susceptible to exploits through the Groovy script console misconfiguration.

In the following sections, we delve deeper into Jenkins and the security configuration issue, and then introduce Cisco Outshift’s attack surface scanner. This scanner is designed to assess an enterprise’s security posture helping you to stay ahead of potential threats and keep your Jenkins environment secure.

Jenkins and CI/CD chains

Jenkins serves as an orchestrator for user defined tasks and workflows created by developers and DevOps teams. These teams configure Jenkins by setting up jobs that define various aspects of the CI/CD process. They specify where to access source code repositories, which tools to utilize, the testing frameworks to initiate, and the deployment targets to store the built artifacts.

When certain events occur, such as code commits or scheduled events, Jenkins triggers the execution of these jobs. It retrieves the relevant source code, initiates the build process, and then proceeds to execute the defined steps in the job. In this way, Jenkins automates the entire CI/CD chain, streamlining the process of building, testing, and deploying software applications.

Jenkins consists out of several core components that are essential to setting up a Jenkins CI/CD environment.

Jenkins Controller
Jenkins Agents
Jenkinsfile (instruction file)
Pipeline
Jenkins Script Console

Jenkins operates on a controller-worker architecture, where the controller takes charge of scheduling jobs, assigning workers (also known as Jenkins Agents), and sending build executions to these workers. The workers can be deployed as containers or virtual machines, and the controller manages them, orchestrating their tasks and scheduling jobs accordingly.

The controller instructs workers to execute the instructions defined in the Jenkinsfile. This file contains the necessary instructions to ensure that the source code is available for the pipeline's commands, as well as the various stages, steps, and configuration settings for your CI/CD pipeline.

Jenkins agents are responsible for executing the tasks in a job. When jobs are triggered by the Jenkins Controller, they are assigned to these agents. Each job comprises a set of tasks defined in the Jenkinsfile, and the agents carry out these tasks sequentially.

A Jenkins pipeline represents a series of automated steps that outline the entire CI/CD process for a software application. It encompasses all the events from the moment code changes are made to when those changes are deployed to production.

We differentiate between two primary tools through which a user can interact with Jenkins and its pipelines.

The Jenkins Web interface is the primary method of interaction, for configurations, manual executions, and monitoring of pipeline jobs.
The Script Console in Jenkins is a tool that allows administrators and authorized users to execute Groovy scripts directly on the Jenkins server. This console runs scripts with Jenkins' access privileges, giving it elevated permissions.

In The Jenkins Script Console, the Groovy scripting language is used to create sub-processes and executive commands on the Jenkins controller and agents, allowing the reading of files on host paths (like /etc/passwd).

A Groovy Script that reads data and credentials using the Jenkins Script Console is shown below. By following the steps, you can make it execute the program:

Go to the Jenkins dashboard.

Click on "Manage Jenkins" in the left-hand menu.

From the options, click on "Script Console."

Execute a Groovy code, following the pattern of the following example.

com.cloudbees.plugins.credentials.SystemCredentialsProvider.getInstance().getCredentials().forEach{println it.dump().replace(' ', ' ')}

Security Misconfigurations in Jenkins

The security impact of misconfigurations can be serious: misconfigurations are one of the major causes of today’s system breaches. In Jenkins, one concern for misconfigurations is connected to the protection of the script console.

Securing a Jenkins pipeline involves various measures, and Jenkins provides a security management system to define granular security rules. Per security best-practice, it is necessary to implement the available security tooling with a deny access by default setting. Credentials and secrets are used for various authentication and authorization purposes, using Jenkins’ credential management system.

Jenkins can manage customer credentials and secrets. This is essential to avoid hardcoding sensitive information (e.g., passwords, API keys) directly into pipeline scripts. Various credential types are supported, such as username/password, secret text, or SSH key pairs. These credentials can then be used with plugins or the CI/CD pipeline configurations to securely access external systems without compromising their confidentiality.

Jenkins offers an access control mechanism for managing access to Jenkins and its tools, encompassing both authentication and authorization mechanisms. Authentication mechanisms involve Jenkins users providing proof of their identity, which is then used to establish user identities and group affiliations. Authorization mechanisms determine the actions users are allowed to perform and are governed by an authorization strategy. This strategy determines whether a Jenkins user, either directly or through group memberships, possesses the necessary permissions.

When configuring authentication and authorization procedures in Jenkins, administrators can accidentally misconfigure users/roles and assign more access than intended to account configurations. One notable misconfiguration is improper access control to the Jenkins Script Console. While the script console offers capabilities that make Jenkins a potent CI/CD tool, it can also be misused by attackers to compromise the infrastructure and gain unauthorized access to systems when Jenkins is not properly configured.

If unauthorized access is obtained, it becomes possible to view credentials in clear text, obtain GitHub, GitLab, AWS, Azure tokens, allowing further system intrusion, the ability to plant backdoors, and establish a persistent reverse shell that will remain even after the Jenkins permission issue has been resolved. In the hands of malicious actors, such access has significant damaging outcomes.

Unfortunately, granular access control is not as commonly implemented as it should be. In the Common Weakness Enumeration (CWE) standard, those relevant to the Jenkins Script Console misconfigurations are:

Improper Access Control (CWE-284) & Improper Privilege Management (CWE-269) 

Exploiting Jenkins Script Consoles can lead to unauthorized access to Jenkins and potentially other connected systems. Attackers could use the console to manipulate Jenkins objects, bypass security measures, and gain administrative privileges. Once inside, they can infiltrate the CI/CD pipeline, inject malicious code into builds, or tamper with critical configurations, leading to data breaches or the introduction of vulnerabilities into production environments.

It is paramount for the security of your Jenkins workspace to avoid running the Jenkins server and its agents as the root user. If and when Script Console access has been obtained by a malicious actor, they can work towards escalated access privileges, breaching the integrity and confidentiality of CI/CD pipelines and potentially disrupting the availability of systems, resulting in significant financial and reputational damage. Addressing this risk requires maintaining an up-to-date Jenkins environment, implementing strict access controls following a least-privilege strategy based on allow-lists, and combining it with extensive action-based monitoring that isolates threats upon detection, thus limiting the time window for attackers.

a. Private Repositories Access 

An attacker can gain access to private source repositories that are integrated with Jenkins and by that gain clear text passwords, keys, credentials, connection strings and tokens that were used in private repositories (Common scenario when the developers think that their code in on premise and “cannot be reached”). 

b. Deployment Environment Credentials 

An attacker can access all the deployment credentials that integrated with Jenkins including private keys, usernames, JWT tokens, Git Tokens, passwords, AWS access / secret tokens and more. 

Preventing Jenkins Misconfigurations

Unfortunately, and even though the Jenkins Script Console misconfiguration has been known for a while, we find there are instances of faulty deployments. It is important to periodically scan for such misconfigurations.

The security configuration of Jenkins is managed via the Jenkins interface (“Manage Jenkins → Security”). The configuration page allows for five access-control modes:

Anyone can do anything – In this configuration, any user that has access to the Jenkins service has unrestricted access and can perform any action within the Jenkins environment.

Legacy mode – if a user has the “admin” role, they will be granted full control over the system, and otherwise (including anonymous users) will only have the read access.

Logged-in users can do anything – every logged-in user has full control of Jenkins.

Matrix-based security – This authorization scheme allows for granular control over which users and groups can perform which actions in the Jenkins environment.

Project-based Matrix Authorization Strategy – This authorization scheme is an extension to Matrix-based security which allows additional access control lists (ACLs) to be defined for each project separately in the Project configuration screen.

To help secure the Script Console, Jenkins administrators can take steps such as:

Enabling authentication and authorization: By enabling authentication and authorization in Jenkins, administrators can ensure that only authorized users have access to the Script Console.

Using role-based access control (RBAC): RBAC allows administrators to assign specific roles and permissions to users or groups, enabling them to control who has access to the Script Console, using an allow-listing approach. This strategy follows a matrix-based allow-list approach, using role rather than user-based privilege assigning.

Make the Jenkins private - only registered users can view the jobs and access the management panel.

Restricting access to the Script Console: Access to the Script Console should be restricted to a limited number of trusted users. Ideally, access should only be granted to users who require it for their job responsibilities. If setting the Jenkins server to private is not an option, it is possible to limit access to the script console by only configuring known and trusted users, and never allowing Anonymous to access it (nor should you ever allow “Logged-in user can do anything” in your server).

Monitoring access and usage: Administrators must monitor access to the Script Console and review logs regularly to detect any unauthorized access or unusual activity.

By taking these measures, Jenkins administrators can help prevent unauthorized access to the Script Console and minimize the risk of security breaches. Following a least-privilege allow-listing based strategy addresses the misconfiguration problem, as it enables access control model around access to Jenkins features, such as the Script Console.

Detecting Jenkins misconfigurations

Cisco’s External Attack Surface solution enables security personnel to scan the attack surface of their enterprise. A Jenkins misconfiguration scanner has been added to the External Attack Surface solution to find the earlier described misconfigurations in publicly hosted Jenkins services. Cisco’s External Attack Surface checks your cloud-based Jenkins pipeline for misconfigurations and alerts enterprises in case actors can misuse your cloud deployment, and get access to the enterprise assets.

Cisco’s External Attack Surface is an agentless solution that scans all your cloud assets and presents your attack surface. With this new Jenkins misconfiguration analysis feature in the External Attack Surface, enterprises can better scan this attack surface and know if the enterprise application assets are at risk due to a Jenkins misconfiguration. 

Outshift by Cisco presents Panoptica, a SaaS (Software as a Service) security product for finding vulnerabilities and attack paths in applications. This toolset scans the applications and cloud’s attack service and combines these into attack paths. Panoptica’s attack-path detection is a graph-based technology providing deep and cohesive visibility reducing the list of non-critical security findings to instead make the right connections between risks and map the critical attack paths that attackers can take to compromise applications and their cloud environments.

Scan your own domain now for free on recon.cloud!