Zscaler Blog

Get the latest Zscaler blog updates in your inbox

Subscribe
Security Research

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

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 serverFigure 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 requestFigure 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.

Zscaler Coverage

The Zscaler ThreatLabZ team has deployed protection.

Zscaler Advanced Threat Protection:

  • APP.EXPLOIT.CVE-2024-23897
form submtited
Thank you for reading

Was this post useful?

Get the latest Zscaler blog updates in your inbox

By submitting the form, you are agreeing to our privacy policy.