Confluence Pre-Auth Remote Code Execution via OGNL Injection (CVE-2022-26134)

on

This post was authored by Ahmad Shauqi.

Overview

On June 2, 2022, Atlassian issued a security advisory for it's Confluence Server and Data Center product, highlighting an unauthenticated remote code execution and CVE-2022-26134 was given a critical rating by Atlassian. The OGNL injection vulnerability allows an unauthenticated user to execute arbitrary code on a Confluence Server or Data Center instance. 

OGNL injection is not a new vulnerability, in fact, there was a CVE related to OGNL injection before which is CVE-2021-26084. This blog will go over technical analysis on the fundamental cause of the vulnerability. But first, let us take a closer look at Confluence's technology and OGNL to better understand how the exploit occurred in the first place.

Understanding the Technology

WebWork 2

Based on Atlassian, Atlassian Confluence is using webwork 2 as their MVC framework. If you understand the fundamental concepts of Java web apps such as servlets, you have the upper hand. If you are not familiar with Java servlets, basically they are components that come together to build web containers for hosting web applications on web servers and managing requests to Java apps.

Below you can see the general architecture of a WebWork 2 architecture.

Figure 1: WebWork 2 Architecture

Based on Figure 1, it shows that:
  1. Initial request goes to standard filter chain and includes the (optional) ActionContextCleanup filter, which are required if you wish to integrate in with technologies like SiteMesh.
  2. FilterDispatcher is then invoked, which consults the ActionMapper to see if the request should trigger an action. If it does, it will than delegates to the ActionProxy to consult Configuration Manager in order to read xwork.xml.
  3. ActionProxy creates an ActionInvocation, which is responsible for the command pattern implementation including invoking interceptors before finally invoking Action itself.
  4. Once action is returns, ActionInvocation is looking up proper result associated with the action result code mapped in xwork.xml and will be executed, which often (but always, as is the case for Action Chaining) involves a template written in JSP to be rendered.
  5. Finally, the interceptors are executed again, returning back through the filters configured in web.xml. If ActionContextCleanUp filter is present, FilterDispatcher will not clean up the ThreadLocal ActionContext. Otherwise, it will cleanup all ThreadLocals.

OGNL

WebWork 2 also provides a powerful language which is Object Graph Navigation Language (OGNL) and it is an open-source Expression Language for Java. The main purpose of OGNL is to get and set object properties: "Almost everything you can do in Java can be done in OGNL."

Based on a blog written by Ionut Popescu [1] the OGNL expressions are evaluated using %{code} and ${code} sequences. As mentioned in it's documentation, OGNL allows the following:
  • Access properties such as name or headline.text
  • Have simple variable scheme such as #var="something"
  • Call methods such as toCharArray()
  • Access elements from arrays such as listeners[0]
  • Or even combine them: name.toCharArray()[0].numericValue.toString()
Since OGNL can evaluate any object properties, what happen if we put something like this:

Figure 2: OGNL payload

Basically, what the payload on Figure 2 does is, it will assign a value to variable my_var and set a cookie named NBS_COOKIE with my_var as it value. If OGNL can create a cookie and control the value, can it perform remote code execution?

CVE-2022-26134 Root Cause

Figure 3: Attack Flow

As we all know CVE-2022-26134 is based on OGNL injection and Figure 3 is redesigned attack flow diagram from a tweet user named Maniesh Neupane. Based on documentation, it is possible to invoke OGNL expression via findValue() and findString() method from OgnlValueStack class. Both methods take any string as input and evaluate the expression against the stack. Next step is to find the entry point from HTTP request that can invoke findValue() method. Rapid7 [2] stated that any HTTP request method can be used including GET, POST, PUT or invalid ("BALH").

Based on Figure 1, it shows that any HTTP request will be going through xwork.xml. As an example, let us take a look at the xwork-default.xml's source code.

Figure 4: xwork-default.xml code

Line 3-5 based on Figure 4 shows that it has a result element and the type for result element is chain result and it will call ActionChainResult class. Normally chain result need actionName and namespace to be specified based on the documentation, but in this case, it will take anything as namespace and actionName. To have more understanding on this case, Figure 5 shows the position of namespace and actionName in url format.
 
Figure 5: namespace and action in url

Noted that string ${7+7} in the url http://localhost/${7+7}/login.action is called namespace, and login.action is called an action.
 
Figure 6: ActionChainResult.class code

ActionChainResult.class then will take namespace and pass to TextParseUtil.translateVariables() as parameter and call translateVariable method.
 
Figure 7: TextParseUtil.translateVariables code

As we see on Figure 7, TextParseUtil.translateVariables invokes OgnlValueStack.findValue, thus it will evaluate the expression. As a result, the URI provided by the attacker will be translated into a namespace, which will then be used to evaluate OGNL expressions.

PoC of Exploitation

In order to gain Remote Code Execution, a Github user named Nwqda mentioned a payload to execute remote code execution as shown on Figure 7.
 
Figure 8: OGNL RCE payload

This will give a response with custom header from previous payload which is id.

Figure 9: RCE Payload response

Remote code execution is successfully performed. Apart from performing RCE, it is also possible to create an admin account based on this tweet. 

Patch

The patch has already been released on Atlassian's advisory and we can analyze the patch version. After de-compile the jar file using jd-gui, some important changes have been made by Atlassian. Based on the investigation before, the root cause of this exploit is because of ActionChainResult.class is calling translateVariables method which invoke findValue method, and as the result OGNL expression evaluated. According to researcher from Rapid7 [2], the main and important changes that have been made is at com.opensymphony.xwork.ActionChainResult class specifically on assigning namespace and action variable.

Before:

Figure 10: Old ActionChainResult class code

After: 
Figure 11: Patch ActionChainResult class code
 

Mitigation

Atlassian released versions 7.4.17, 7.13.7, 7.14.3, 7.15.2, 7.16.4, 7.17.4, 7.18.1 which contain a fix for this issue in their advisory on 3rd June 2022. If you are unable to upgrade Confluence immediately, as a temporary workaround, you can mitigate the CVE-2022-26134 issue by updating the following files for the specific version of the product. Noted that this process must be manually applied. Full instructions are available in Atlassian's advisory.
 
Volexity [3] suggests the following to prevent this specific vulnerability :
  • Block related IOCs provided
  • Although the nature of RCE vulnerability allows infinite execution types, Volexity provides hunting rules here to identify related webshell activity, especially on Confluence Server system.
  • Review any recent alerts related to Confluence systems that you may have set up. 

 

Conclusion

In summary, the core vulnerability for CVE-2022-26134 is based on OGNL injection in ActionChainResult class. This vulnerability can be exploited without an authentication, thus the severity increase to critical which is 9.8. Affected version is recommended to migrate to latest version and apply some security detection mechanism such as WAF and detection rules.

Reference and Further Reading

  1. https://pentest-tools.com/blog/exploiting-ognl-injection-in-apache-struts
  2. https://www.rapid7.com/blog/post/2022/06/02/active-exploitation-of-confluence-cve-2022-26134/
  3. https://www.volexity.com/blog/2022/06/02/zero-day-exploitation-of-atlassian-confluence/