CVE-2023-46214 - Critical RCE Flaw in Splunk Enterprise XSLT Processing—Simple Breakdown, Exploit Demo, and Resources

Splunk is a powerful tool loved by organizations needing to manage, search, and analyze big data. But even seasoned tools can slip up, especially when it comes to handling user-supplied input. In late 2023, security researchers discovered a major vulnerability—CVE-2023-46214—in Splunk Enterprise (versions below 9..7 and 9.1.2), related to how it processes XSLT files. Here’s a deep dive into the issue, how it works, and a practical demonstration of exploitation.

What’s CVE-2023-46214 All About?

XSLT (Extensible Stylesheet Language Transformations) is a language for transforming XML documents into other formats. Splunk Enterprise lets users upload XSLT for custom data transformations. The problem? Splunk was *not* safely sanitizing that XSLT input.

Splunk Enterprise before 9.1.2

*If you’re running an affected version, you’re at risk!*

How Does the Vulnerability Work?

The root cause is that XSLT, when processed by Splunk, was able to run dangerous extensions—especially XSLT’s ability to call system functions, or execute shell commands.

Malicious code could be inserted via a crafted XSLT file, then uploaded through the Splunk interface or an API endpoint.

The XSLT processor (usually libxslt or equivalent) has extension functions like xsl:document() or, in some setups, full-blown system call capabilities. Attackers exploit these to make Splunk run arbitrary commands.

Exploiting CVE-2023-46214—Example Attack in Plain English

Here's a basic XSLT file that, when processed, tries to run a system command (for example, creating a file called hacked.txt):

<?xml version="1." encoding="UTF-8"?>
<xsl:stylesheet version="1."
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
  xmlns:rt="http://xml.apache.org/xalan/java/java.lang.Runtime";
  xmlns:ob="http://xml.apache.org/xalan/java/java.lang.Object">;
  <xsl:template match="/">
    <xsl:variable name="rtObj" select="rt:getRuntime()"/>
    <xsl:variable name="process" select="rt:exec($rtObj, 'touch /tmp/hacked.txt')"/>
    <xsl:variable name="wait" select="ob:wait($process, 100)"/>
  </xsl:template>
</xsl:stylesheet>

What this does

- Calls Java’s Runtime.getRuntime().exec() method to execute the shell command: touch /tmp/hacked.txt (which creates a file).
- An attacker could instead run any command they like. That could mean installing backdoors, exfiltrating files, etc.

Real-Life Impact

- Remote Code Execution: Unauthenticated attackers (or anyone with upload rights) can get full control of the Splunk server.

Persistence: Attackers can drop shells or malware.

- Data Theft: Since Splunk handles sensitive log data, an attacker could exfiltrate internal logs and info.

Mitigation

Upgrade now:

Splunk Enterprise 9..7 and 9.1.2 patch this issue.

- Splunk 9..7 release notes
- Splunk 9.1.2 release notes

Short-term workarounds:

References

- Splunk Security Advisory (SA-Engine-2023-12)
- MITRE CVE-2023-46214 Entry
- Splunk Docs—Upgrading Splunk Enterprise

TL;DR

If you use Splunk Enterprise older than 9..7/9.1.2, your server can be taken over due to improper sanitization of user-supplied XSLT. Attackers can upload malicious XSLT to run any command on your server.

PATCH NOW—this is a critical RCE!

Stay secure, and always keep your Splunk (and other core infra) up to date. If in doubt, check your XSLT settings and who has permissions to upload custom transformations.

Timeline

Published on: 11/16/2023 21:15:08 UTC
Last modified on: 12/12/2023 16:15:08 UTC