Critical Jenkins Vulnerabilities CVE-2024-23897 and CVE-2024-23898 - An Advisory

On January 24, 2024, the Jenkins project team published a security advisory notifying users of two critical vulnerabilities, CVE-2024-23897 and CVE-2024-23898, affecting versions of Jenkins prior to Jenkins 2.441 and earlier, LTS 2.426.2. These vulnerabilities could allow unauthenticated remote attackers to execute arbitrary code on Jenkins servers.

Jenkins is one of the most popular open-source automation servers, with over 2 million installs globally. It enables developers to reliably build, test and deploy their software projects through continuous integration (CI) and continuous delivery (CD) workflows.

Jenkins supports integration with source code management tools like Git and repositories like GitHub, as well as build tools like Maven and Gradle. Additionally, various plugins allow expanding Jenkins' capabilities for tasks like deployment, testing, monitoring and more.

Given its feature-rich functionality and flexibility through plugins, Jenkins sees deployment across a wide range of organizations as their CI/CD backbone. This includes companies of all sizes from small startups to Fortune 500 firms across industries like banking, retail, media and more. Furthermore, many Jenkins installations manage infrastructure that could be business or mission-critical. Therefore, vulnerabilities in Jenkins' core functionality pose a significant risk that must be addressed promptly by all administrators.

CVE-2024-23897

Description

CVE-2024-23897 is a command injection vulnerability present in Jenkins before versions 2.442 and 2.426.2 LTS, with a CVSS score of 9.8. It affects the built-in command line interface (CLI) that allows interacting with Jenkins from scripts or a shell environment.

Specifically, the issue lies in how Jenkins processes arguments containing '@' characters when passed to the CLI. By default, it replaces an '@' followed by a file path with the contents of that file, a feature intended to allow executing CI jobs defined in external files. However, this "file expansion" behavior is not restricted and allows injecting any file on the Jenkins controller file system.

Impact

With this vulnerability, unauthenticated attackers can read arbitrary files on the Jenkins controller by specifying their path after the '@' character. The amount of file contents readable depends on the CLI command used:

• Attackers with Overall/Read access can read entire files.
• Attackers without those permissions can typically read the first few lines, around 3 lines worth of data as of current research.

Additionally, Jenkins stores cryptographic keys and secrets in some binary configuration files. While the file contents can't be read in full, enough data may be obtainable through statistical analysis to enable further attacks. These include ransomware encryption, stored XSS in build logs, and CSRF vulnerabilities.

Attack Vectors

There are a few ways this vulnerability could be exploited:

• Through Jenkins' default exposed CLI port (8080/TCP) if not firewalled. An attacker could connect and pass crafted arguments.
• If the CLI accepts commands over other channels like SSH, attacking those entry points. For example, plugins integrating with source control systems.
• Leveraging CVE-2024-23898 (discussed next) to bypass authentication via cross-site WebSocket hijacking.

CVE-2024-23898

Description

CVE-2024-23898 is a cross-site WebSocket hijacking (CSWSH) issue in Jenkins before versions 2.442 and 2.426.3 LTS.

Since Jenkins 2.217, one way to communicate with the CLI is through a built-in WebSocket endpoint at port 8080. However, Jenkins fails to validate the WebSocket origin. Additionally, Jenkins session cookies do not have the "SameSite" attribute, allowing them to be used cross-site.

By hijacking a user's WebSocket connection, an attacker could bypass Jenkins' authentication and execute CLI commands as that user via the WebSockets endpoint, gaining their permissions.

Impact

This vulnerability on its own could allow compromised commands execution under a victim's privileges, such as deleting items or downloading Java heap dumps.

However, its worst impact stems from chaining it with CVE-2024-23897. By connecting over the hijacked WebSocket, an attacker could read arbitrary controller files through the CLI, without any Jenkins access of their own.

Attack Vectors

To exploit this, the attacker would need to perform a cross-site WebSocket hijacking on a Jenkins user, such as via:

• Malicious browser extensions/plugins
• Compromised sites with Jenkins credentials stored
• XSS on domains sharing the same cookies
• Man-in-the-middle attacks if connecting without TLS

Once the WebSocket is hijacked, CVE-2024-23898 provides a way to connect and authenticate to Jenkins as the victim, enabling the file reading attacks from CVE-2024-23897.

Technical Analysis and Root Cause

Both issues stem from configuration and design flaws in Jenkins' CLI command parsing and WebSocket endpoint handling.

CVE-2024-23897

Jenkins uses the Apache Commons CLI library to parse CLI arguments. By default, it enables environment variable and file expansion of '@' prefixed arguments without restrictions.

This well-intentioned feature, meant to simplify scripting, was left exposed without input sanitization. It allows injecting any files or directories reachable by the Jenkins process.

CVE-2024-23898

The Jenkins WebSocket endpoint relied on the container's authentication setup, without validating the client's origin. Additionally, Jenkins failed to set the "SameSite" attribute for session cookies.

This led to cookies being available for use across different origins, allowing the CLI authentication tokens to be hijacked. Combined with file read access from CVE-2024-23897, this bypasses would-be authorization requirements.

In both cases, the core issues were configuration errors and lack of input validation, exposing unintended attack surfaces. Proper sanitization and encapsulation could have prevented them.

Plugin-Specific Vulnerabilities

In addition to issues in Jenkins core, Jenkins project team published a security advisory vulnerabilities affecting several plugins:

Git Server Plugin Arbitrary File Reading

Like the CLI, the Git Server Plugin is vulnerable to file reading via its argument parser (SECURITY-3319). Overall/Read access is required.

Fix: Updated to disable file parsing, and admins can disable the SSH server as a workaround.

Matrix Project Path Traversal

The Matrix Project Plugin did not sanitize axes names, allowing path traversal attacks (SECURITY-3289). Impact is writing to files with Item/Configure permission.

Fix: version 822.824.v14451b_c0fd42.

GitLab Branch Source Plugin Issues

• It unconditionally discovered shared projects (SECURITY-3040).
• It lacked CSRF protection on a form (SECURITY-3251).
• It had a timing side-channel in token validation (SECURITY-2871).

All were addressed in version 688.v5fa_356ee8520, and shared project discovery now requires an opt-in trait.

Qualys Plugin Stored XSS and XXE

The Qualys Plugin reflected untrusted input and allowed XXE (SECURITY-3006, SECURITY-3005). It also had permission check issues (SECURITY-3007).

Version 1.0.6 fixed reflected XSS, disabled external entities, and enforced permissions.

Red Hat Dependency Analytics Plugin CSP Bypass

It incorrectly disabled CSP for directories like workspaces (SECURITY-3322). This was resolved in version 0.9.0.

Log Command Plugin File Reading

Like other plugins, it is vulnerable to file reading through its argument parser (SECURITY-3334). As there is no fix yet, Jenkins will continue working with maintainers.

All of these plugin issues highlight the importance of input validation, secure configuration, and access controls. Developers must consider these fundamental aspects of security.

IoC and Detection Methods

While the typical indicators of compromise may not apply due to lack of unique artifacts, some detection avenues exist:

• Monitor Jenkins/container logs for unusual API requests or file system access patterns
• Inspect job configurations, build artifacts for signs of tampering
• Search backed-up configuration files for private data leaks
• Monitor browser storage/extensions for Jenkins credentials
• Review recent CLI/SSH session records for anomalies
• Cross-reference known Jenkins webhook, SSH targets and IPs for reconnaissance
• Setting up a Sysmon type of endpoint detection on Jenkins VM

Presence of files or items with random/unexpected names may indicate credential theft or ransomware deployment as well. Proactive hunting via logs and assets is key to detecting any exploitation.

Mitigations and Remediation

The following steps can help secure Jenkins instances until patches are applied:

• Apply Jenkins versions 2.442/2.426.3 or later containing fixes
• Restrict CLI/WebSocket access only to trusted authorized networks
• Rotate any credentials stored in Jenkins files
• Enable secure authentication like OIDC/MFA where possible
• Firewall Jenkins listen ports (8080/TCP,50000/TCP default) except for authorized IPs
• Audit plugins and build jobs for signs of recent compromise
• Limit user access privileges only to required items
• Enable config restrictions to block plugin/job modifications
• Consider re-imaging Jenkins controller host as a precaution

Additionally, some configurations like disabling file expansion for CLI and adding "samesite" attributes for cookies could help reduce risk.