On May 31, 2022, a critical vulnerability in Atlassian Confluence Server and Confluence Data Center was disclosed by Volexity. While conducting an incident response investigation involving internet-facing servers with the Confluence server installed, Volexity determined that the servers were compromised and attackers were launching successful remote code execution (RCE) exploits. After replicating the attack, they notified Atlassian about the vulnerability and CVE-2022-26134 was assigned to track it.
Atlassian later released a security advisory to address this unauthenticated RCE vulnerability, stating that this attack affected all supported Confluence Server and Data Center products. Atlassian also stated that the vulnerability was being actively exploited.
The exploit takes advantage of an Object-Graph Navigation Language (OGNL) injection vulnerability in the Confluence Server. Datadog Security Research can confirm active exploitation of this vulnerability from information-sharing partners as early as May 2022.
Key points and observations
- May 30, 2022: Volexity identifies and validates the vulnerability and exploit payload.
- May 31, 2022: Volexity contacts Atlassian, who then confirms the vulnerability and assigns CVE-2022-26134.
- June 2, 2022: The initial security advisory on CVE-2022-26134 is released by Atlassian.
- June 3, 2022: Atlassian advises on using a web application firewall (WAF) to block OGNL injection attempts and releases a workaround fix by replacing some JAR files before releasing comprehensive fixed versions. Proofs of concept (PoCs) begin emerging on code-sharing websites, social media, and paste sites.
Next, we’ll look at how to check if your services are vulnerable and cover methods to secure them.
Check if your application is vulnerable
Atlassian confirmed that all supported versions of Confluence Server and Data Center were affected. Any version prior to the following versions—which were released by Atlassian on June 3 to address the issue—is considered vulnerable.
Remediate affected systems
To remediate the vulnerability, ensure your deployments of Confluence Server are equal to or greater than the following versions:
- 7.4.17, 7.13.7, 7.14.3, 7.15.2, 7.16.4, 7.17.4, and 7.18.1
If you are not able to upgrade, we suggest applying Atlassian’s recommended workaround from their security advisory—under “Mitigation”—to mitigate the risk of an exploit.
How the vulnerability works
An OGNL injection is an infamous attack that targets Object-Graph Navigation Language (OGNL), an open source expression language used in many popular Java applications and frameworks including WebWork and Apache Struts 2. Because OGNL has the ability to change executable code, it can be used to introduce security flaws to applications and frameworks that use it.
Below is a sample attack payload:
curl -v http://localhost:8090/%24%7B%40java.lang.Runtime%40getRuntime%28%29.exec%28%22touch%20/tmp/pwned%22%29%7D/This is just an encoding for an OGNL expression including java.lang.Runtime to execute a system command: touch /tmp/pwned.
{@java.lang.Runtime@getRuntime().exec(“touch /tmp/pwned”)}Confluence parses the URL and maps it to a namespace and action in order to determine what action the user wants to do in which namespace. In the above attack, /%24%7B%40java.lang.Runtime%40getRuntime%28%29.exec%28%22touch%20/tmp/pwned%22%29%7D/ in the URL is parsed by Confluence as namespace. Then the code uses translateVariables (part of the text-parsing utilities in Confluence) on this namespace. Because translateVariables uses OGNL, the attack will be parsed and evaluated.
Atlassian provided a workaround fix by replacing some JAR files and classes. The main updates are in xwork-1.0.3-atlassian-10.jar; inside this JAR file, we can see that ActionChainResult.java has been updated to address the problem.
In the fix, the Atlassian team removed the TextParseUtil usage from ActionChainResult.java, blocking the URI from directly passing into the OGNL expression evaluation.
If you want to replicate the attack on a vulnerable environment, we have a ready-to-use environment with the PoC in our Security Labs PoC repo.
How Datadog can help
Datadog Cloud Workload Security (CWS) customers can detect CVE-2022-26134 exploitation and post-exploitation through out-of-the-box (OOTB) rules that look for Java or web application processes spawning an unusual shell or system utility. Our team recently added a new case that detects Confluence servers potentially spawning shells. By combining our OOTB Java and WebApp shell process rules with the ability to look at common environment variables known to be affiliated with Confluence server installs, customers can get higher fidelity and more contextual signals.
Datadog recommends looking for “Java process spawned shell/utility” on your Confluence workloads, and investigating any post-exploitation activity on these servers using the standard out-of-the-box ruleset. The new Host Investigation dashboard allows you to isolate hosts to perform security triage in the case of a shell being spawned on one of your Confluence servers.
CWS customers with Datadog Network Performance Monitoring (NPM) enabled can also inspect outgoing traffic from their Confluence servers to risky domains.
In this example, NPM picked up our exploit using a reverse shell going to 4.tcp.ngrok.io. You can monitor for risky domains by looking at uncommon connections, such as this workload going to ngrok.io, to identify potential exploitation of this vulnerability.
Conclusion
The high-impact Confluence vulnerability lets attackers easily exploit production environments that use unprotected versions of Confluence. In this post, we discussed some detection and prevention strategies for CVE-2022-26134, and we showcased detection capabilities of the Datadog Cloud Security Platform against PoC attacks. Datadog customers can enable Cloud Workload Security (CWS) and Network Performance Monitoring (NPM) today to take advantage of our detection capabilities against this vulnerability.
Acknowledgements
Thank you Nick Davis, Jimmy Vo, Ryan Simon, and Will Roper, all of whom contributed to the making of this post.
