Jenkins jitters as 45,000 servers still vulnerable to RCE attacks after patch released – Source: go.theregister.com

The number of public-facing installs of Jenkins servers vulnerable to a recently disclosed critical vulnerability is in the tens of thousands.

Scans from internet security data company Shadowserver indicate roughly 45,000 instances of the hugely popular CI/CD automation server are vulnerable to CVE-2024-23897, the critical flaw disclosed on January 24.

The vast majority of exposures are contained to the US and China, with 15,806 and 11,955 vulnerable servers respectively. Trailing them are India (3,572), Germany (3,487), Republic of Korea (2,204), France (1,482), and the UK (1,179).

The revelation of the vast attack surface comes days after multiple exploits were made public on January 26 – themselves released just two days after the coordinated disclosure from Jenkins and Yaniv Nizry, the researcher at Sonar who first discovered the vulnerability.

It means nearly a week has passed and admins are still failing to patch against a critical vulnerability that Jenkins has warned could lead to remote code execution (RCE).

While there is no hard evidence to suggest active exploitation is under way, leaving a week-long window for attackers to target vulnerable servers, all while proof-of-concept exploits are publicly available, could result in successful attacks eventually.

CVE-2024-23897 is the critical vulnerability disclosed by Sonar and the main reason for Jenkins attracting so much attention from the infosec community of late, although a separate high-severity flaw was also disclosed.

With a 9.8 severity score, CVE-2024-23897 is certainly serious. It takes advantage of a feature of Jenkins’ built-in command line interface (CLI) that’s enabled by default in Jenkins 2.441 and earlier.

The CLI uses the args4j library to parse command arguments and options on the Jenkins controller. Per the expandAtFiles feature, when an @ character is followed by a file path in an argument, the command parser automatically replaces it with the file’s contents.

Exploiting this allows attackers to read arbitrary files, according to Jenkins’ advisory.

“As of publication of this advisory, the Jenkins security team has found ways to read the first three lines of files in recent releases of Jenkins without having any plugins installed, and has not identified any plugins that would increase this line count,” the advisory reads.

The Jenkins team went on to detail the various different types of feasible attacks that could play out if the vulnerability was exploited, each resulting in different types of sensitive data being exposed. According to Jenkins and Sonar, these include:

• SSH keys

• Binary secrets

• Credentials

• Source code

• Build artifacts

When it comes to reading binary files via an exploit of CVE-2024-23897, there are limitations, the Jenkins team said. This is because of the way the vulnerable feature attempts to read the files as strings using its default character encoding.

• Atlassian Confluence Server RCE attacks underway from 600+ IPs
• Ivanti and Juniper Networks accused of bending the rules with CVE assignments
• Two more Citrix NetScaler bugs exploited in the wild
• Patch now: Critical VMware, Atlassian flaws found

The problem with this is that different character-encoding algorithms will determine the proportion of bytes that can be read. UTF-8, for example, will replace roughly half the file’s bytes with a placeholder for an illegal value.

Jenkins commonly uses 32-byte random binary secrets meaning attackers would need to correctly guess 16 bytes, which the developers said is “unfeasible.”

“In contrast, with the encoding Windows-1252, only five out of 256 possible values are illegal and would be replaced with a placeholder. This is a significantly lower number of bytes to guess in a binary secret on average, as well as fewer possible options for each byte.”

The team’s telemetry for versions 2.437 and later indicates that more than 90 percent of instances use UTF-8 as the default character encoding. Almost all Linux and macOS instances use UTF-8, although those that run on Windows “are more likely than not” to use encoding that allows for feasible reading of binary secrets, such as Windows-1252.

This means that attackers targeting Windows instances could have a greater degree of success when trying to reconstruct secrets from binary files.

“This is significant because the hudson.util.Secret file is a small binary file that contains an encrypted key used to encrypt other secrets,” said Naveen Sunkavally, chief architect at Horizon3, in a blog.

For those unable to apply the patches, disabling the CLI until they can is strongly recommended. This prevents exploitation completely, and doesn’t require a Jenkins restart either.

In the meantime, admins should also ensure that three key configuration settings aren’t enabled to prevent giving all unauthenticated users read permissions.

Having the “Allow anonymous read access” option ticked while the authorization mode is set to “logged-in users can do anything” gives any unauthenticated attacker the overall/read permission, allowing them to read files at will. The same would apply in legacy mode.

The “Allow users to sign up” option also allows anyone who can access the Jenkins instance to create an account, although there is a clear warning when this tick box is checked, informing the admin of the security risks. ®