Researchers warn that attackers have already started scanning for Jenkins servers that are vulnerable to a critical remote code execution flaw patched last week. Proof-of-concept (PoC) exploits for the vulnerability are already available, so the time window to patch before widespread attacks occur is quickly closing.
According to scans with the Shodan service, more than 75,000 Jenkins servers are exposed to the internet. Jenkins is an open-source automation server that’s commonly used as part of continuous integration and continuous delivery (CI/CD) pipelines because it allows the automation of code building, testing, and deployment. Jenkins has many integrations with other services and tools, which makes it a popular choice for all software development organizations having an estimated market share of around 44%.
The vulnerability, tracked as CVE-2024-23897, is rated as critical severity and is described as an arbitrary file read issue that attackers can exploit to read entire or partial binary files from the file system. This can allow them to extract secret keys that they can use to escalate their privileges to admin and execute malicious code. The issue was patched in Jenkins versions 2.442 and LTS 2.426.3 together with several other high- and medium-severity flaws.
Command-line argument parsing exposes file contents
The flaw stems from Jenkins’ use of the args4j library to parse command arguments and options when processing commands sent via the Jenkins command-line interface (CLI) feature. The parser replaces the @ character followed by a file path in a command argument with the file’s contents therefore potentially exposing secrets.
According to researchers from SonarSource, who found and reported the vulnerability, unauthenticated attackers can exploit this if they gain read authorization on the server. This can be achieved in multiple configurations: if the server has legacy mode authorization enabled, if the server is configured with âAllow anonymous read accessâ checked in the âlogged-in users can do anythingâ authorization mode, or if the signup feature is enabled that allows anyone to create an account on the server. Even if none of these conditions are true, unauthenticated users can still read the first few lines of files instead of their entire contents.
“One way an attacker could leverage this is to find a command that takes an arbitrary number of arguments and displays these back to the user,” the researchers said in a blog post. “Since the arguments are populated from the contents of the file, an attacker could leak the file contents this way. We found the command connect-to-node to be a good candidate: It receives a list of strings as an argument and tries to connect to each one. If it fails, an error message is generated with the name of the failed connected node.”
Some of the files on the server that could be of interest for an attacker could be SSH keys, the /etc/passwd file, the /etc/shadow file, project secrets and credentials, source code and build artifacts, and more.
The Jenkins security team documents several attack paths for achieving remote code execution and other secrets theft with this vulnerability. Some include abusing the ââ”Resource Root URL” functionality, forging “Remember me” cookies, inserting cross-site scripting attacks in build logs, forging cross-site request forgery protection tokens, decrypting binary secrets, and downloading a Java heap dump.
How to mitigate the Jenkins CI/CD server vulnerability
The patch involves disabling the command parser that exposes file contents. This could cause problems for some deployments, in which case a mechanism is available to undo it. However, its use is strongly discouraged on Jenkins instances that are accessible over the network by non-administrators. Another way to mitigate the threat is to disable access to the Jenkins CLI entirely until the patches can be applied.
Go to Source