XWiki Remote Code Execution Vulnerability

Overview

The SonicWall Capture Labs threat research team became aware of CVE-2024-31984, which is a code injection vulnerability in XWiki's management of space titles and has a critical CVSS score of 9.9. After assessing the impact, we developed mitigation measures to address the vulnerability. This vulnerability, originating from insufficient input validation, allows remote, authenticated attackers to execute arbitrary code on the target server by creating documents with maliciously crafted titles. The team's efforts have focused on understanding the severity of the risk and ensuring that users can securely manage and operate their XWiki platforms without compromise.

The versions of XWiki Platform impacted by the remote code execution vulnerability encompass a broad range of releases. Specifically, the vulnerability affects all versions starting from 7.2-rc-1 up to, but not including the patched versions 14.10.20, 15.5.4 and 15.10-rc-1. This wide span of versions includes any builds prior to 4.10.20, making it imperative for users operating on these versions to update their systems. The vulnerability has been effectively addressed in the newer versions 14.10.20, 15.5.4 and 15.10-rc-1. For those unable to immediately upgrade, a manual patch is available for the Main.SolrSpaceFacet page (Figure 1) to mitigate the risk temporarily until an upgrade can be implemented. This patch is crucial as it prevents the execution of arbitrary Groovy code, which could compromise the confidentiality, integrity and availability of the XWiki installation.

Figure 1: Patch

Technical Overview

XWiki's scripting capabilities form a core component of its architecture, allowing users to craft both simple and complex web applications directly within the XWiki interface without the conventional requisites of compiling code or deploying software components. This functionality is facilitated through an advanced scripting feature set that is embedded in the content of an XWiki page, alongside traditional wiki markup. XWiki supports a variety of scripting languages such as Velocity, Groovy, and Python, which are enabled by default, thus offering versatility and power to developers. The platform utilizes the JSR-223 scripting framework to evaluate script code seamlessly. This is executed via the script macro, which follows the syntax {{script language="<script engine name>"}}<some code>{{/script}}, allowing for direct embedding of code in pages. Specific languages can be declared directly, for example, Groovy code is written within {{groovy}}<some code>{{/groovy}} blocks, enabling immediate and accessible scripting without leaving the XWiki page environment.

Regarding its content organization, XWiki uses a hierarchical structure termed as "Wiki", "Space", and "Page", or alternatively, "Page" and "Child Page". Historically, spaces functioned similarly to folders in a file system, designed to house a collection of pages. However, in more recent updates, XWiki has eliminated the distinction between a page and a space, streamlining its structure. Despite these advancements, a significant vulnerability has been identified within this framework. The issue arises from inadequate input validation of the title fields in XWiki Spaces. Specifically, when a user attempts to create or update a page using actions like "save" or "saveandcontinue", the user-supplied title is stored without neutralizing special characters, potentially leading to code injection risks. This vulnerability extends to the rendering process of the space's title in the "Main.SolrSpaceFacet" on the "Main.SolrSearchConfig" page, where script elements within space titles are executed due to the lack of special character neutralization, posing a critical security risk to the integrity and security of the XWiki installation.

Triggering the Vulnerability

The four main triggers of the vulnerability in XWiki, allowing remote code execution via the Solr-based search mechanism, can be detailed as follows:

Crafted Document Titles: The vulnerability is triggered by creating a document with a specially crafted title. For instance, using the title structure {{/html}}{{async}}{{groovy}}println("Hello from Groovy Title!"){{/groovy}}{{/async}} which contains embedded Groovy code allows arbitrary code execution when the document is processed or indexed by the Solr search engine.
User Rights and Permissions: Any user with the ability to edit titles of a space, which by default is every user, can exploit this vulnerability. This broad default permission setting significantly widens the potential for exploitation.
Search UI Interaction: The crafted code in the document title is executed when interacting with the XWiki search interface. Specifically, after the maliciously titled document is indexed, searching for this document and engaging with facets such as deploying the Location facet can lead to the execution of the embedded Groovy script.
Insufficient Input Sanitization: The underlying issue of inadequate input validation and neutralization of special characters in the XWiki Spaces' title field is a critical trigger. This allows embedded scripts in document titles to be executed without any filtering, directly compromising the application’s security.

Exploitation

The exploitation process targets the XWiki system by leveraging the ability to execute arbitrary code remotely. This process involves an automated script that uses five specific HTTP requests to interact with the XWiki installation:

Login Page Request: Fetches the CSRF token necessary for session authenticity.

URL: loginPageURL = baseURL + 'xwiki/bin/login/XWiki/XWikiLogin?loginLink=1'

Figure 2: Login Request

Login Submission Request: Submits login credentials and the CSRF token.

URL: loginURL = baseURL + 'xwiki/bin/loginsubmit/XWiki/XWikiLogin'

Figure 3: CSRF Token Post Request

Document Edit Page Request: Accesses the document edit page to fetch another CSRF token and check document availability.

URL (Initial attempt):
- baseDocURL = baseURL + "xwiki/bin/edit/"
- newDocURL = baseDocURL + targetDoc

Document Save/Preview Request: Submits a malicious script embedded in the document’s title for preview and execution.

URL: saveDocURL = baseURL + "xwiki/bin/preview/" + targetDoc

Figure 4: Malicious Script, Document Upload

Document Search Request: Searches for the modified document to trigger attacker execution.

URL: searchURL = baseURL + "xwiki/bin/view/Main/Search?text=test"

The attacker configures a client with the server’s URL, username and password, and begins the exploitation by requesting the XWiki login page to obtain a CSRF token (Figure 5). This token is extracted from the HTML content and used alongside the login credentials to authenticate successfully.

Figure 5: CSRF Form Token

After authentication, the attacker searches for an editable document. If unavailable, the document name is modified iteratively until one is found. Another CSRF token is then retrieved from the document editing page. The attack vector is a script embedded in the document’s title, using XWiki’s syntax to embed Groovy code that executes shell commands. The payload — containing the CSRF token, malicious title, and shell command—is submitted to the document's preview URL for processing (Figure 4).

Finally, the attacker initiates a search query to ensure the Solr search engine processes the modified document, confirming the execution of the embedded command. The script concludes by reporting the success of the exploit, demonstrating how the XWiki system can be compromised by using crafted document titles to execute code remotely.

SonicWall Protections

To ensure SonicWall customers are prepared for any exploitation that may occur due to this vulnerability, the following signatures have been released:

IPS: 4408 XWiki Platform SolrSpaceFacet Remote Code Execution

Remediation Recommendations

The risks posed by this vulnerability can be mitigated or eliminated by:

Applying the vendor-supplied patch to eliminate this vulnerability.
Utilizing up-to-date IPS signatures to filter network traffic.
Configure the vulnerable product to allow access to trusted clients only.

Relevant Links

Share This Article

An Article By

Security News

The SonicWall Capture Labs Threat Research Team gathers, analyzes and vets cross-vector threat information from the SonicWall Capture Threat network, consisting of global devices and resources, including more than 1 million security sensors in nearly 200 countries and territories. The research team identifies, analyzes, and mitigates critical vulnerabilities and malware daily through in-depth research, which drives protection for all SonicWall customers. In addition to safeguarding networks globally, the research team supports the larger threat intelligence community by releasing weekly deep technical analyses of the most critical threats to small businesses, providing critical knowledge that defenders need to protect their networks.