PoC Exploits Increase Risks Around Critical New Jenkins Vuln

Approximately 45,000 Internet-exposed Jenkins servers remain unpatched against a recently disclosed critical arbitrary file read vulnerability, for which proof-of-concept exploit code is now publicly available.

CVE-2024-23897 affects the integrated Jenkins command line interface (CLI) and can lead to remote code execution on affected systems. The Jenkins infrastructure team disclosed the vulnerability and released the updated version of the software on January 24.

Proof-of-Concept Exploit

Since, proof-of-concept (PoC) exploits. the code for the flaw has become available and there are some reports of attackers actively trying to exploit It. On January 29, the nonprofit organization ShadowServer, which monitors the Internet for malicious activity, reported observing approximately 45,000 Jenkins instances exposed on the Internet that are vulnerable to CVE-2024-23897. Nearly 12,000 of the vulnerable cases are in the United States; According to ShadowServer data, China has almost as many vulnerable systems.

Many enterprise software development teams use Jenkins to build, test, and deploy applications. Jenkins allows organizations to automate repetitive tasks during software development, such as testing, code quality checks, security scanning, and deployment, throughout the software development process. Jenkins is also often used in continuous integration and continuous deployment environments.

Developers use the Jenkins CLI to access and manage Jenkins from a script or shell environment. CVE-2024-23897 is present in a CLI command parsing feature that is enabled by default on Jenkins versions 2.441 and earlier and Jenkins LTS 2.426.2 and earlier.

“This allows attackers to read arbitrary files on the Jenkins controller file system using the default character encoding of the Jenkins controller process,” the Jenkins team said in Notice dated January 24th. The flaw allows an attacker with General/Read permission, something most Jenkins users would require, to read entire files. An attacker without such permission would still be able to read the first few lines of the files, the Jenkins team said in the advisory.

More carriers for RCE

The vulnerability also puts at risk binary files containing cryptographic keys used for various Jenkins features, such as credential storage, artifact signing, encryption and decryption, and secure communications. In situations where an attacker could exploit the vulnerability to obtain cryptographic keys from binary files, multiple attacks are possible, the Jenkins advisory warns. These include Remote Code Execution (RCE) attacks when the Resource Root URL feature is enabled; RCE via the “Remember me” cookie; RCE through cross-site scripting attacks; and remote code attacks that bypass protections against cross-site request forgery, the advisory states.

When attackers can access cryptographic keys in binary files via CVE-2024-23897, they can also decrypt secrets stored in Jenkins, delete data, or download a Java heap dump, the Jenkins team said.

SonarSource researchers discovered the vulnerability and reported it to the Jenkins team described the vulnerability even allowing unauthenticated users to at least have read permission on Jenkins under certain conditions. This may include enabling legacy mode authorization or if the server is configured to allow anonymous read access or when logging functionality is enabled.

Yaniv Nizry, the Sonar security researcher who discovered the vulnerability, confirms that other researchers were able to reproduce the flaw and have a working PoC.

“Because it is possible to exploit the vulnerability without being authenticated, to some extent it is very easy to discover vulnerable systems,” Nizry notes. “As for exploitation, if an attacker is interested in escalating arbitrary file reading to code execution, it would require a deeper understanding of Jenkins and the specific instance. The complexity of the escalation depends on the context.”

The new Jenkins versions 2.442 and LTS version 2.426.3 resolve the vulnerability. Organizations that cannot immediately upgrade should disable access to the CLI to prevent abuse, the advisory states. “This is highly recommended for administrators who are unable to immediately upgrade to Jenkins 2.442, LTS 2.426.3. Applying this workaround does not require a restart of Jenkins.”

Patch now

Sarah Jones, cyber threat intelligence research analyst at Critical Start, says organizations using Jenkins would be wise not to ignore the vulnerability. “Risks include data theft, system compromise, disrupted pipelines, and the possibility of compromised software releases,” says Jones.

One area of ​​concern is that DevOps tools like Jenkins can often contain critical and sensitive data that developers may import from production environments when building or developing new applications. A case in point occurred last year when a security researcher found a document containing 1.5 million people on the TSA no-fly list sitting unprotected on a Jenkins server, belonging to Ohio-based CommuteAir.

“Immediate patching is critical; updating to Jenkins versions 2.442 or later (non-LTS) or 2.427 or later (LTS) addresses CVE-2024-23897,” Jones says. As a general practice, he recommends that development organizations implement a least privilege model to limit access and also perform vulnerability scanning and continuous monitoring for suspicious activity. Jones adds, “Additionally, promoting security awareness among developers and administrators strengthens the overall approach to security.”



Source link

Leave a Reply

Your email address will not be published. Required fields are marked *