New proof-of-concept (PoC) exploits are circulating for a widely targeted flaw in Atlassian Confluence Data Center and Confluence Server. New attack vectors could allow an attacker to stealthily execute arbitrary code within Confluence memory without touching the file system.
VulnCheck researchers have been tracking exploits for the Remote Code Execution (RCE) Vulnerability CVE-2023-22527, which was announced in January. Since then, they noted, the CVE has become a “hotbed of malicious activity,” with VulnCheck currently monitoring 30 in-the-wild exploits unique to the vulnerability, including the most recent options.
Most attacks against Confluence charge the “infamous” Godzilla Web Shell. Godzilla allows attackers to remotely control the compromised server, execute arbitrary commands, upload and download files, manipulate databases, and perform other malicious activities.
A new approach, however, uses an in-memory payload. After identifying PoCs in the wild using this technique, VulnCheck researchers developed three PoCs to probe the limits of the in-memory approach.
The flurry of activity shouldn’t surprise anyone: VulnCheck CTO Jacob Baines says he thinks so attackers love to target Confluence due to the wealth of business information available within the application, making it a “good hub” in an internal network.
“By leveraging this, you get an on-premise version with business-specific logic,” he says. “It’s pretty interesting especially for ransomware attackers.”
In-memory web shell for Atlassian Confluence exploits
AS VulnCheck blog post details: “There is more than one way to reach Rome. More stealthy routes generate different indicators. Of particular interest is the in-memory Web shell, which had a pre-existing variant… that appears to have been implemented in the wild.”
Baines explains that one of the company’s PoCs details the critical first step of loading arbitrary Java into memory, a popular exploit approach but one that can easily be discovered with endpoint detection.
“This is a very obvious and easy to spot method for leveraging Confluence,” he says. “But loading arbitrary Java into memory is helpful to know how to do, because the next step, the web shell part, relies on that.”
VulnCheck’s other two proofs of concept for CVE-2023-22527 in Confluence detail how attackers could exploit the Confluence vulnerability by directly loading a web shell into memory to gain unauthorized access to web servers.
Loading and running code from Confluence’s memory is a much more stealthy and weaponized approach to attacking Confluence and is less likely to be detected by defenders, Baines says.
“Many systems only detect adversaries on the system by scanning files that are dropped on disk,” he says, adding that there is no great way to scan Java in memory for web shells because of the way it is structured: the real solution is in detecting it on the network.
“This presents its challenges, as everything is encrypted and you have to distribute certificates to clients,” he says. “The long-term answer is to get everything you can out of the Internet.”
Baines points out that Confluence now has multiple different CVEs on VulCheck’s Known Exploited Vulnerabilities (KEV) list.
“It’s definitely time to start integrating this with a VPN,” he says. “Ultimately, attack surface management is the way to help mitigate these more advanced issues.”
OGNL risk not limited to confluence
Baines says the risk of compromise is extremely high for organizations that have not yet installed patches for Confluence, given the ongoing mass exploitation efforts.
“We noticed that the attackers used this web shell in memory – this is not a theoretical attack,” he says. “It’s something that’s happening, so defenders need to be aware of it and that it’s a high risk at the moment.”
Baines adds that the risk from the in-memory approach is not just limited to Confluence, as it is related to Object-Graph Navigation Language (OGNL) expressions, which allow developers to perform various operations on Java objects using simple and concise syntax .
“This affects a variety of different products with similar vulnerabilities – you could use exactly the same technique against those other products,” he says. “Organizations need to evolve a step to start catching this kind of thing, such as network-based detection or scanning Java memory for malicious web shells.”