A critical remote execution flaw has been identified in Jenkins servers, prompting a warning from researchers about the potential risks to organizations using this open-source automation server. The vulnerability, known as CVE-2024-23897, has been classified as critical and allows attackers to exploit an arbitrary file read issue, potentially leading to the extraction of secret keys and the execution of malicious code. Proof-of-concept exploits for this vulnerability have already been developed and are readily available, heightening the urgency for organizations to patch their systems before widespread attacks occur.

Shodan service scans have revealed that more than 75,000 Jenkins servers are currently exposed to the internet, thereby increasing the potential threat posed by this vulnerability. Jenkins is widely used in continuous integration and continuous delivery (CI/CD) pipelines, making it an attractive target for attackers seeking to compromise the automation of code building, testing, and deployment processes. The extensive integrations with other services and tools further contribute to Jenkins’ popularity, with an estimated market share of around 44%.

The flaw in Jenkins’ vulnerability stems from the use of the args4j library to parse command arguments and options when processing commands sent via the Jenkins command-line interface (CLI) feature. This method of parsing command arguments has raised security concerns, as the parser is susceptible to replacing the @ character followed by a file path with the file’s contents, thus exposing potential secrets. Researchers from SonarSource, who discovered and reported the vulnerability, highlighted the risk posed by unauthenticated attackers exploiting the flaw to gain unauthorized access to the server.

The attack can be executed through multiple configurations, including scenarios where legacy mode authorization is enabled, the server is configured with “Allow anonymous read access” in the “logged-in users can do anything” authorization mode, or the signup feature allows anyone to create an account on the server. Even if these conditions are not met, unauthenticated users can still read the first few lines of files instead of their entire contents. SonarSource researchers emphasized the severity of this vulnerability, noting that it could be leveraged by attackers to access sensitive information and potentially compromise the overall security of the Jenkins server.

In light of the critical nature of this vulnerability, Jenkins promptly released patches for the affected versions, including Jenkins versions 2.442 and LTS 2.426.3. These patches aim to address the high- and medium-severity flaws present in the system, providing organizations with a potential solution to mitigate the inherent risks associated with the vulnerability. However, the urgency to apply these patches remains paramount, as the availability of proof-of-concept exploits increases the likelihood of widespread attacks against vulnerable Jenkins servers.

The researchers at SonarSource emphasized the potential impact of the vulnerability, explaining how an attacker could exploit this flaw to access sensitive files by manipulating command arguments. By exploiting a command that takes arbitrary arguments and displays them back to the user, an attacker could leak the contents of files, potentially leading to the compromise of secret keys or other critical information. The discoverers of the vulnerability highlighted the command “connect-to-node” as a prime candidate for exploitation, as it receives a list of strings as an argument and attempts to connect to each one. In the event of a failed connection, an error message is generated, revealing the name of the failed connected node and potentially exposing sensitive information.

Overall, the discovery of this critical vulnerability in Jenkins servers presents a significant security concern for organizations relying on this open-source automation server for their CI/CD pipelines. The availability of proof-of-concept exploits, combined with the large number of exposed Jenkins servers, increases the urgency for organizations to apply the necessary patches and safeguards to mitigate the potential risks. Failure to address this vulnerability in a timely manner could lead to widespread attacks and compromise the security and integrity of Jenkins-based automation processes.

Source link