8,000+ Confluence Servers Still Vulnerable to Atlassian Flaw
3rd Party Risk Management
,
Application Security
,
Breach Notification
Server Taken Offline Following Exploitation of Vulnerability
Last weekend’s confirmed attack on the Jenkins project – an open-source automation server used in software development – using a recently discovered vulnerability in the Atlassian Confluence service, could be the tip of the iceberg, suggests Mark Ellzey, a senior security researcher at cybersecurity company Censys, who says thousands of Confluence servers remain vulnerable.
The Jenkins project reported that it was attacked through the recently discovered CVE-2021-26084 vulnerability in the Atlassian Confluence service. The organization said that it has quarantined and taken the affected server offline to study the impact of the attack.
The company sought to assure users, saying that “we have no reason to believe that any Jenkins releases, plugins, or source code have been affected.” But Ellzey, who has been closely tracking the details and the number of vulnerable servers affected by the Confluence vulnerability, noted in an initial search before the data was made public, that: “The internet had over 14,637 exposed and vulnerable Confluence servers.” Hence there is a significant opportunity for further attacks.
Ellzey adds that a week after the public disclosure of the flaw, the number of exposed and vulnerable Confluence servers came down to 11,689, and dropped further to 8,597, as of Sunday. But in an updated blog post from Sunday, he writes: “There is no way to put this lightly, this is bad. Initially, Atlassian stated this was only exploitable if a user had a valid account on the system; this was found to be incorrect and the advisory was updated today to reflect the new information.”
See Also: Beginners Guide to Observability
The initial Jenkins announcement of the attack was made on Saturday, just a day after the U.S. Cyber Command and the U.S. Cybersecurity and Infrastructure Security Agency issued alerts warning users of ongoing “mass exploitation” of the vulnerability (see: Atlassian Vulnerability Being Exploited in the Wild).
Cyber Command tweeted on Saturday morning: “[The exploitation is] expected to accelerate. Please patch immediately if you haven’t already – this cannot wait until after the weekend.”
Our Confluence service was successfully exploited using the recently disclosed CVE 2021-26084. We have taken numerous steps to limit impact to our infrastructure and preserve your trust in Jenkins releases. Learn more at https://t.co/tRRzaR06nj
— Jenkins (@jenkinsci) September 4, 2021
CVE-2021-26084 is an object-graph navigation language -also known as OGNL – injection vulnerability with a CVSS score of 9.8. When exploited, this vulnerability allows an authenticated user, and in some instances even an unauthenticated user, to execute arbitrary code on a Confluence Server or Data Center instance. A security advisory issued by Atlassian warns, “All versions of Confluence Server and Data Center prior to the fixed versions affected by this vulnerability.”
Jenkins Incident Update
Clarifying the cause of the attack, Jenkins says, “We have learned that the Confluence CVE-2021-26084 exploit was used to install what we believe was a Monero miner in the container running the service.” Talking about the impact that this miner could have on its platform, however, Jenkins reassures users that “the attacker would not be able to access much of our other infrastructure. [Also,] we do not have any indication that developer credentials were exfiltrated during the attack.”
Another reason why Jenkins claims nominal damages is that it has deprecated the Confluence service since October 2019. Consequently, it has assigned read-only rights “effectively deprecating it for day-to-day use within the project,” says Jenkins. The company further confirms that the migration of documents and changelogs from wiki to GitHub repositories has been initiated and is an ongoing process.
But the Confluence service is still integrated with Jenkins’ identity system that controls and collaborates with Jira, Artifactory and numerous other services. Therefore, to avoid taking any further risks, Jenkins confirms that it has reset passwords for all accounts in the integrated identity system, rotated privileged credentials and taken other proactive measures to minimize malicious access across its infrastructure.
