Protection From Atlassian Confluence OGNL Injection Vulnerability

Our Security Research Team has built and deployed a rule to help protect customers of our next-gen WAF against the recently announced CVE-2021-26084, an Atlassian Confluence OGNL injection vulnerability that allows for the execution of arbitrary code on a Confluence Server or Data Center instance. Mass exploitation of the vulnerability is ongoing and expected to accelerate, so it’s worth your attention if you’re a self-managed Confluence customer. 

What’s the impact?

Only self-managed Confluence instances are vulnerable; cloud-hosted (“Confluence Cloud”) instances are not affected. A non-administrator user or unauthenticated user can gain full access to self-managed Confluence instances if the “Allow people to sign up to create their account” function is enabled. 

Attackers do not need local access before exploiting this vulnerability, making it a compelling option in attack campaigns. By gaining remote control over the Confluence instance, attackers can do whatever they want on the system — such as migrating to other production servers that process customer data, installing a cryptominer, or implanting a backdoor to guarantee future access. 

Digging deeper

This issue is an Object-Graph Navigation Language (OGNL) injection vulnerability. OGNL is an expression language for getting and setting properties of Java objects and therefore is able to create or change executable code by design (which is why OGNL injection attacks are infamous, especially in the context of Apache Struts).

The intent of OGNL was to offer limiting formatting capability that could do conditional formatting of text based on a template — but what they actually got was the ability to run arbitrary code because they accidentally exposed part of the Java runtime for loading executable code. 

The goal of any injection attack is to inject code into expected user input that would be evaluated and executed by the application out of context. In this case, the vulnerability is specifically triggered through a template injection attack in Velocity (a Java template engine by the Apache Foundation). Attackers can include command line (bash) commands in their input that are then executed on the operating system.

Exploitation involves a clever bypass of the isSafeExpression method, which checks if anything malicious is being called inside an OGNL expression. By using unicode characters, attackers can craft input that bypasses validation; so, rather than input like #{3*33}, an attacker can instead craft the input as the string \u0027%2b#{3*33}%2b\u0027 to end up with the result of 99. To dig even deeper, read the exploit writeup.

What should you do now?

This is definitely worth addressing immediately. Proof-of-concept exploit code has been publicly available since Aug. 31, 2021, and our Security Research Team has observed active exploitation.

We strongly suggest that customers using our next-gen WAF in front of their self-managed Confluence instances enable this rule as soon as possible and configure it to block requests if the signal is observed. Customers can navigate to Site Rules →  Templated Rules →  then under "Category" select "CVE" and the rule will appear in the list of CVE rules released for customers.

Additionally, we recommend that you follow all guidance from Atlassian to patch affected Confluence instances. The vulnerability in question is being actively exploited globally and can have severe impact if attackers use it to remotely execute code on vulnerable servers.

Further reading

If you would like to dig deeper into the technical details of this chain of attacks, please see this post by CSO Online. Please refer to our documentation for details on how to enable templated rules.