A new critical vulnerability in Jenkins has surfaced. The vulnerability in an open source automation server allows unauthorized attackers to perform remote code execution (RCE) attacks. As Jenkins is a rather popular basis for a server infrastructure all around the world, a lot of companies and organizations are at risk.
Jenkins RCE Vulnerabilities Exploitable
Jenkins is a popular open-source automation server widely used for building, deploying, and automating software projects. With Jenkins, developers can automate various aspects of the software development lifecycle, including building, testing, and deploying applications. And with such a popularity, the attention to any cybersecurity aspect of the product is obvious.
Jenkins RCE vulnerabilities involve an arbitrary file read flaw via the built-in command line interface, allowing attackers to access and read files on the Jenkins’ controller file system. This could potentially lead to remote code execution if exploited successfully. Another high-severity issue related to Jenkins includes cross-site WebSocket hijacking, which could compromise the integrity of Jenkins instances by hijacking authenticated sessions.
RDE vulnerabilities almost always get a lot of attention, mainly due to their severity. We recently wrote about a similar RCE vulnerability discovered in Atlassian.
Jenkins Critical RCE Exploit – CVE-2024-23897
The critical flaw, CVE-2024-23897, stems from an arbitrary file read vulnerability within Jenkins’ built-in command line interface (CLI). This vulnerability enables attackers with Overall/Read permission to read arbitrary files on the Jenkins controller file system. In scenarios where attackers lack such permissions, they can still access the first few lines of files, potentially exposing sensitive data.
The vulnerability arises from Jenkins’ use of the args4j library for parsing command arguments and options on the controller. The args4j library’s feature, which replaces an “@” character followed by a file path in an argument with the file’s contents, is at the heart of this security flaw. This feature, while intended to simplify command execution, inadvertently opens a door for attackers to exploit.
There is one more vulnerability, CVE-2024-23898, found in the WebSocket CLI feature. In this case attackers could execute arbitrary CLI commands. This vulnerability can lead to Cross-Site WebSocket Hijacking (CSWSH). An attacker could use this vulnerability by sending a malicious link to the victim.
Example of Cross-Site WebSocket Hijacking (CSWSH)
Although some web browsers have a “lax by default” policy that could potentially protect users, certain widely used browsers like Safari and Firefox do not strictly enforce this policy. This, coupled with risks of potential bypass techniques or users using outdated browsers, makes the severity classification for this another vulnerability as High.
That is not the first time Jenkins’ software hits the newsletter titles due to the vulnerability concerns. Earlier, we wrote about vulnerabilities in plugins for Jenkins – give it a shot.
The Exploitation Risk
The exploitation of vulnerabilities carries severe consequences. Attackers can leverage this vulnerability to perform a capacity of malicious activities, including but not limited to:
- Remote code execution via various vectors such as Resource Root URLs, “Remember me” cookies, and stored cross-site scripting (XSS) attacks.
- Decryption of secrets stored within Jenkins, potentially exposing sensitive information.
- Deletion of any item in Jenkins, leading to data loss or disruption of services.
- Downloading a Java heap dump, which could reveal further vulnerabilities or sensitive information stored in memory.
Patches Available
In response to the discovery of CVE-2024-23897, Jenkins has released patches in versions 2.442 and LTS 2.426.3, which disable the vulnerable command parser feature.
CVE-2024-23898 was fixed by adding an origin verification to the WebSocket endpoint. The ALLOW parameter has been added as an option for administrators to override the updated default behavior. This allows them to consistently permit or deny access to the WS CLI, regardless of the Origin.
Patch with “ALLOW” parameter
Security Recommendations
In addition to applying the immediate patches, organizations should adopt comprehensive security measures to protect against future vulnerabilities. These practices include:
- Implementing robust access controls and permissions management to minimize potential attack vectors.
- Conducting regular security audits and vulnerability assessments to identify and address security gaps.
- Regularly updating and patching software to ensure protection against known vulnerabilities.
- Deploy advanced EDR or XDR solutions that can provide real-time monitoring and detection of threats across endpoints, networks, and cloud environments.
