Overview
CVE-2024–23897 is a critical vulnerability discovered in Jenkins, with a high CVSS score of 9.8. This vulnerability allows the attacker to read files in the system through Command-Line Interface (CLI) for script and shell interaction, relying on the args4j library to parse commands. However, a vulnerability in this library permits unauthenticated users to read initial file lines and authenticated users to access entire files, putting many companies at risk. This is because Jenkins is an open-source solution that helps developers automate tasks. In this analysis, we will go through the steps and conditions for this vulnerability in detail.
Building the Testing Environment for Jenkins Vulnerability Analysis
1- Update and upgrade the system
Sudo apt-get update update; sudo apt-get upgrade
2- Installing docker
Sudo apt-get install docker.io
3- Pull the vulnerable docker images
Sudo docker pull jenkins/jenkins:2.426.2-jdk17
4- Run the docker image
Sudo docker run -e p 8080:8080 -p jenkins/jenkins:2.426.2-jdk17
Now visit 127.0.0.1:8080
And it’s already up, so after copying the provided admin password, you can continue the process
Choose “Install suggested plugins”. It’s okay to go with the default configuration
Wait until the installation is finished.
It’s now ready to start the analysis
Reproducing the Vulnerability
After downloading the CLI from /jnlpJars/jenkins-cli.jar ,
In caseAllow anonymous read access isdisabled, follow this.
After capturing the traffic through Wireshark, the request was as follows:
This is a simple POST request to the “/cli” endpoint with a remoting=false parameter with the session header and side, which is a custom header.
The response contained only one line of the /etc/passwd.
In case Allow anonymous read access is Enabled..
By running
In Wireshark
Also, attackers can read user passwords by reading the /var/jenkins_home/users/users.xml file which contains information about as shown in the following screengrab.
java -jar jenkins-cli.jar -s http://localhost:8080/ -http connect-node “@/var/jenkins_home/users/admin1_14933008246101305485/config.xml”
And then take the value from the passwordHash element.
After cracking it with John the ripper tool using rockyou.txt wordlist..
Patch diffing
After taking a look at the patch, we can see the file which was edited was CLICommand.java as shown below:
The patch disabled this feature and set the default value of AllowAtSyntax to false to avoid the file reading vulnerability.
The analysis
Simply by looking source code of Jenkins CLICommand.java, it can be seen that the code imports three methods from the args4j library
After cloning the args4j-site-2.33 and reviewing CmdLineParser method,
Note: I will go through only CmdLineParser, because other functions are not important to trace this vulnerability.
By taking a look at parseArgument..
This method is responsible for handling the input taken from the user. It checks if args contain SyntaxAt(@) and if it does, it passes the input to the expandAtFiles method.
So, let’s take a look at the expandAtFiles method.
Basically, the following code checks if the args start with @. It will read all the lines on the file and there is no authentication.
Conclusion:
As explained in the analysis, third parties play an important role in attack scenarios. As shown in this analysis, the main vector used an outdated library (args4j) to perform crucial functions like parsing command lines without checking authentication, leading to file reads. Therefore, we should consider that even third-party apps can be the main vector of vulnerabilities.
References:
https://github.com/jenkinsci/jenkins/commit/554f03782057c499c49bbb06575f0d28b5200edb
