Jenkins Path Traversal Vulnerability

Since January 2024 the popular open-source automation platform Jenkins has been plagued by a critical path traversal vulnerability that allows unauthenticated attackers to read arbitrary files on the underlying machine.

Despite a fix for the vulnerability being deployed on the same day as the publication of Jenkins’ security advisory on the matter, over 40 thousand exposed devices have been found to still use vulnerable versions of the software. Combining such a huge number of potential victims with an exploit that is relatively easy to carry out has resulted in several documented cases of this vulnerability being actively used in cyber attacks. Because of this, the Cybersecurity and Infrastructure Security Agency (CISA) has added the path traversal vulnerability, tracked as CVE-2024-23897, to its list of Known Exploited Vulnerabilities.

Figure 1: There are over 40 thousand devices still running vulnerable Jenkins versions.

This vulnerability’s addition to CISA’s infamous database comes shortly after the ransomware group RansomEXX was able to cause the shutdown of over 300 banks in India by using the vulnerability to steal sensitive credentials held by a supplier of the National Payments Corporation of India. However this was not the first time the bug has been used in attacks; The threat actor IntelBroker was found exploiting it to breach the IT provider BORN Group in July 2024, and the Russian state-affiliated threat actor APT29 is known to have utilised this vulnerability.

CVE-2024-23897 is a path traversal vulnerability, stemming from the fact that Jenkins uses external input to create a path name to a file or directory without properly sanitising it first. In this case, Jenkins has failed to disable part of its command parser feature that assumes any string after an ‘@’ symbol is a file path. This critical vulnerability allows attackers to use this feature without credentials, although unauthenticated attackers are only able to read the first three lines of a file’s contents. However, they still have the ability to run code on the system.

The Perfect Vulnerability Storm

Although CVE-2024-23897 is an impressive and highly critical flaw in its own right, the vulnerability’s discovery did not happen in isolation. A second overlooked bug, CVE-2024-23898, was discovered alongside CVE-2024-23897 and creates a perfect storm for hackers to attack vulnerable Jenkins command-line interface (CLI) clients.

The Jenkins CLI should only be able to be accessed through SSH or through the official Jenkins CLI clients, which uses basic HTTP authentication alongside session cookies and API tokens. The issue with Jenkins’ implementation is a failure to confirm that new connection requests actually originated from official CLI WebSocket endpoints, therefore allowing attackers to perform cross-site WebSocket hijacking (CSWSH). In addition to this, the vulnerability highlighted the fact that Jenkins does not automatically set the ‘SameSite’ attribute for session cookies, which tells browsers how to handle a cookie if it comes from another site.

By setting nothing, Jenkins is at the mercy of the user’s browser’s behaviour. The majority of modern browsers now automatically set ‘SameSite’ cookies to Lax if they are not specified. The exception to this is Firefox and Safari, two highly popular browsers, which do not.

Standalone, this CSWSH vulnerability does not let attackers get far into a properly configured Jenkins system. If Jenkins’ CLI enforces authentication (and the attacker does not have any login details) then an attacker is only able to execute the ‘who-am-i’ command. The issue arises when a Jenkins server is set to allow “Anyone to do anything” – a setting that is fully supported by all versions of Jenkins! This security option needs no explanation as to what an attacker would be allowed to do, and so perhaps they should rename it to “A hacker can do anything”.

The unfortunate perfect storm of exploitation potential is created by the discovery of the CSWSH vulnerability alongside CVE-2024-23897. Failure to carry out origin validation for incoming packets means the exploit for CVE-2024-23897 does not require attackers to first get valid credentials, instead allowing any unauthenticated user to read arbitrary files within the Jenkins controller file system.

Exploiting CVE-2024-23897

The earliest exploits for CVE-2024-23897 were published shortly after the vulnerability was first publicized in January 2024. Many of these exploits are written in Python and do not require much expertise to run. Looking at one of the earliest available scripts, published on PacketStorm, it is possible to identify the flow of this vulnerability’s exploit.

Figure 2: A Python script to automate the exploit of CVE-2024-23987.

The two main functions of the script, ‘rec1()’ and ‘rec2()’ initiate the exploit by concurrently sending two POST packets to the URL ‘http://jenkins/cli?remoting=false’, as discovered by SonarSource. When requesting the the ‘/cli’ directory, Jenkins uses the Java library Args4j as a command parser. When parsing a new argument, the library calls a function named ‘expandAtFiles()’ which treats any string after a ‘@’ symbol as a file path. Therefore, the vulnerability is exploited by an attacker accessing the ‘/cli’ directory and including the name of a file within the body of their POST packet. Figure 3 shows a simplified version of the flow of the exploit for this vulnerability.

Figure 3: A flowchart depicting a simplified method of exploitation for CVE-2024-23897.

As any file can be accessed by any user, the results of this attack is not just limited to read entire file’s contents but also executing them, therefore allowing unauthenticated attackers to potentially deepen their reach into a compromised system by running preexisting CLI commands.

Jenkins acknowledges this in their security advisories detailing the vulnerability, and helpfully (for attackers and developers alike) lists some of the potential risks and possible attacks available to a hacker exploiting CVE-2024-23897. These include creating a backdoor by forging a cookie for an administrator account, decrypting credentials, API keys, or other sensitive information to get into other systems connected to a Jenkins server, and causing general chaos by deleting any item in the Jenkins controller file system. The exploit also allows for remote code execution, including through stored cross site scripting.

As mentioned previously, the scale of vulnerable Jenkins systems still operating on affected versions is huge. However, this number may have been made much smaller had CVE-2024-23898, the cross-site WebSockets hijacking bug, not been present. The exploit for CVE-2024-23897 would be somewhat more complicated if the attacker first needed to spoof the origin of the two POST packets or had to steal a valid cross-site request forgery (CSRF) token from users.

Jenkins’ Role In Supply Chain Attacks

Jenkins at its core is built to integrate with other software-development programs. The program boasts how easily developers can utilise Jenkins to automate running their existing building, testing, and deployment programs. As a result, almost all Jenkins services will usually be connected to several key development or testing platforms, such as GitHub, Selenium, and even Slack.

With CVE-2024-23897 allowing access to any file on Jenkins instances, threat actors quickly began using it to gain access to other systems that trust Jenkins. Cybersecurity researchers at CloudSek discovered that one group, IntelBroker, exploited CVE-2024-23897 to dump login details stored in the ‘credentials.xml’ file. As a result, IntelBroker was able to access and clone private repositories. This gave the attackers access to hard coded keys within the compromised organisation’s code which in turn gave them access to other third-party organisations using the compromised repositories. It is thought that this attack resulted in the ransomware attack on Indian banks that is mentioned at the beginning of this article, as it is possible that IntelBroker sold SSH keys and GitHub access tokens to a RansomEXX for further exploitation.

Signs of Compromise

Just weeks after the Jenkins’ vulnerabilities were made public, researchers at Splunk had already captured numerous attempts from attackers to exploit CVE-2024-23897. They found that malicious payloads often sought for files on the Jenkins system that included high-value credentials and sensitive data, such as ‘/etc/passwd’ and ‘/var/jenkins_home/secrets/initialAdminPassword’.

Figure 4: Malicious HTTP requests spotted in-the-wild by Splunk.

Searching for logged exploit attempts for this vulnerability can be easily done. Search queries for typical logging systems can simply look for successful (where the status is 200) HTTP POST packets that request the directory ‘/cli?remoting=false’ within the URL. Additionally, searching for long strings of URL-encoded binary sequences (which are usually uncommon in HTTP bodies) such as the ones in Figure 4 can be easily done through the use of tools like RegEx.

Vulnerability Fixes and Mitigations

Preventing your Jenkins instance from being vulnerable to the exploits listed in this article can be simply done by updating Jenkins to the latest version. If that is not possible, Jenkins has listed some workarounds that prevent exploits from being successful.

For mitigating the exploitation of CVE-2024-23897, disabling access to the CLI is recommended as a short-term workaround until other preventative measures can be put in place. Jenkins recommends this for administrators who cannot immediately update their Jenkins version. Documentation on how to disable the Jenkins CLI can be found here.

Mitigating CVE-2024-23898 can be done by either disabling CLI access or preventing WebSocket access using a reverse proxy. Jenkins highlights that if a Jenkins server is only accessible through a reverse proxy, then the proxy should be configured to prevent access to the CLI via WebSockets by not upgrading requests.

Finally, SonarSource researchers noted that Jenkins patched CVE-2024-23897 by disabling the vulnerable ‘expandAtFiles()’ feature (shown in Figure 5), and that CVE-2024-23898 was patched by adding origin verification to the WebSocket endpoint.

Figure 5: Updated Jenkins code that patches CVE-2024-23897.

Source 1 : https://www.shodan.io/search?query=vuln%3ACVE-2024-23897

Source 2 : https://packetstormsecurity.com/files/176840/Jenkins-2.441-LTS-2.426.3-Arbitrary-File-Read.html

Source 3 : https://www.splunk.com/en_us/blog/security/security-insights-jenkins-cve-2024-23897-rce.html