Jenkins Arbitrary File Leak Vulnerability, CVE-2024-23897, Can Lead To RCE

AVINASH KUMAR, VISHAL AJAY SANGOLEKAR, VARUN SANDILA

February 06, 2024 - 4 分で読了

コンテンツ

Introduction
Affected Versions
Technical Details
Recommendations
Zscaler Coverage
References
おすすめのブログ

Introduction

Jenkins, a Java-based open-source automation server widely used by developers for application building, testing, and deployment, has issued an advisory about a critical vulnerability that could potentially enable remote code execution (RCE).

This vulnerability, identified as CVE-2024-23897, poses a high risk and affects Jenkins integrated command line interfaces (CLI). With a CVSS score of 9.8, unauthorized access to files through the CLI is possible, potentially leading to RCE.

In addition to file access, CVE-2024-23897 can be leveraged to access binary files that contain cryptographic keys utilized for various Jenkins functionalities, albeit with certain limitations. Unauthorized access to this sensitive information can result in:

RCE through the exploitation of resource root URLs
RCE by manipulating a "Remember me" cookie
RCE through stored cross-site scripting (XSS) attacks via build logs
RCE by bypassing CSRF protection
Decryption of stored secrets in Jenkins
Deletion of any item within Jenkins
The downloading of Java heap dumps

Affected Versions

The vulnerability affects Jenkins versions up to 2.441 and LTS (Long-Term Support) versions up to 2.426.2.

Technical Details

The vulnerability originates from Jenkins' use of the args4j library for parsing command arguments and options on the Jenkins controller during the processing of CLI commands. Originally intended to enhance usability, a specific feature within args4j that replaces a file path preceded by an "@" character with the file's contents has become a significant security issue. This feature is enabled by default and remains unchecked in versions up to 2.441 and LTS 2.426.2. Exploiting this vulnerability allows attackers to read any files on the Jenkins controller file system using the default character encoding of the Jenkins controller process. When Jenkins CLI tool arguments are prefixed with “@”, they are mistakenly interpreted as files that need to be opened to read the arguments. In certain scenarios, lines from these files are inadvertently included in error messages and transmitted to the CLI user.

Two Jenkins configuration options pose significant security risks by allowing unauthenticated attackers to impersonate authenticated users. The first option, “Allow users to register,” enables anyone with access to a Jenkins instance to register an account. Additionally, the “Enable anonymous read permission” option grants universal read permissions, allowing any Jenkins user to access and read the entire content of arbitrary files on the Jenkins server when these options are enabled.

Figure 1. Jenkins configuration options

Figure 1. Jenkins configuration options

The figure below is an example taking the first rows of the C:\Users\IEUser\AppData\Local\Temp\JenkinsTest.txt (a random file created on the Jenkins server for demonstration) file using the CLI help command.

Figure 2. A demonstration text file created on the Jenkins server

Figure 2. A demonstration text file created on the Jenkins server

There are two ways to invoke this vulnerability:

Using Jenkins-cli.jar: This common approach involves utilizing Jenkins-cli.jar, which operates through web sockets or SSH. Specifically, commands such as shutdown, enable-job, help, and connect-node from the Jenkins CLI tool are manipulated to illicitly access and read the content of files on the Jenkins server. The figure below shows the help command running on Jenkins CLI to read a file.

Figure 3. Running the help command with Jenkins CLI tool to read the file content on Jenkins Figure 3. Running the help command with Jenkins CLI tool to read the file content on Jenkins

The figure below shows the file content being read from the Jenkins server.

Figure 4: File content read from the Jenkins server

Sending POST requests: An alternative method is to send two POST requests to http://jenkins/cli?remoting=false. This technique requires the use of a downloader and an uploader. The downloader fetches the response of the CLI command, while the uploader executes a specified CLI command provided in the body of the request. The connection between the downloader and uploader is established by utilizing the UUID from the session header.

Figure 5. Attack workflow demonstrating malicious HTTP request Figure 5. Attack workflow demonstrating malicious HTTP request

Recommendations

To mitigate this vulnerability, upgrade to at least Jenkins versions 2.442 and LTS 2.426.3. This patch disables the command parser feature responsible for the vulnerability.

Those unable to immediately update to Jenkins 2.442 and LTS 2.426.3 should disable access to the Jenkins CLI, as this is expected to prevent exploitation.

For instructions, see the documentation for this workaround.