Thousands of instances still vulnerable to Apache Struts-like flaw
UPDATED The Jenkins project says it has fallen prey to widespread attacks targeting a critical vulnerability in Confluence, Atlassian’s team collaboration software.
Attackers compromised Jenkins’ deprecated Confluence service last week, revealed the team behind the eponymous open source automation server on September 4.
“We responded immediately by taking the affected server offline while we investigated the potential impact,” the Jenkins team said in a blog post.
“At this time we have no reason to believe that any Jenkins releases, plugins, or source code have been affected.”
Patches ‘cannot wait’
Attackers abused an Open Graph Navigation Library (OGNL) injection flaw – the same vulnerability type involved in the notorious 2017 Equifax hack – capable of leading to remote code execution (RCE) in Confluence Server and Data Center instances.
“Mass exploitation of Atlassian Confluence CVE-2021-26084 is ongoing and expected to accelerate,” the agency warned. “Please patch immediately if you haven’t already – this cannot wait until after the weekend.”
In a blog post tracking the issue, infosec firm Censys revealed how many customers were heeding such warnings, observing a drop in the number of vulnerable Confluence instances from 14,562 on August 25 to 8,597 on September 5.
Road to RCE
After finally having his disclosure request approved, security researcher Benny Jacob shared a write-up of the flaw, which he discovered, on October 5.
“When a Webwork tag with a Value attribute that has a $ is encountered an initial evaluation happens in the parsing of Velocity template,” he explains in a GitHub post.
“This evaluated value is then passed to the Webwork tag which further evaluates the value as an OGNL expression.
“If the action class exposes a setter function for the parameter used in the value attribute then this parameter can be set from the URL by using URL params. So by crafting a URL with an OGNL payload an attacker can perform remote code execution.”
There has previously been controversy over another proof-of-concept for the vulnerability, with VMware refuting accusations that it had leaked an exploit that independent security researchers had specifically crafted for one of their endpoints.
The Jenkins Project said attackers managed to install what it believed was a Monero miner in a container running an affected Confluence instance.
However, “from there an attacker would not be able to access much of our other infrastructure”, it said.
Nevertheless, Jenkins is “assuming the worst” and halting releases “until we re-establish a chain of trust with our developer community”.
Although Jenkins said there was no indication that developer credentials were stolen during the attack, it has applied a universal password reset to its integrated identity system, with which Confluence is integrated.
The compromised Confluence service, which was switched to read-only mode in 2019 as Jenkins began migrating documentation and changelogs to GitHub repositories, has now been “permanently disabled”.
Jenkins has also “rotated privileged credentials and taken proactive measures to further reduce the scope of access across our infrastructure”.
The team added: “We are working closely with our colleagues at the Linux Foundation and the Continuous Delivery Foundation to ensure that infrastructure which is not directly managed by the Jenkins project is also scrutinized.”
Updates and workaround
The vulnerability was addressed in on-premise Confluence versions 6.13.23, 7.4.11, 7.11.6, 7.12.5, and 7.13.0. Most previous versions are vulnerable to the flaw.
Atlassian has provided a script that serves as a temporary workaround if updates cannot be applied immediately.
Confluence Cloud customers are not affected.
This article was updated on October 6 in order to reference a write-up for the CVE by Benny Jacob.