Mint Security

Splunk vulnerability analysis – CVE-2024-29946 & CVE-2024-29945

31.03.2024
10:39
Splunk

Thomas

The author works at and owns Mint Security, a mean and lean security company founded in 2015. No fuzz (literally - we do not fuzz, there are companies better equipped to do that).

The scope of this post

This blog post is a quick analysis of select Splunk advisories containing a set of guiding ideas on how to approach mitigation based on risk.

DISCLAIMER – The author of this blog shall not be held responsible for any negative outcomes that may occur as a result of following advice given in this blog. Caveat emptor – use advice and ideas presented in this blog at your own risk.

All Splunk advisories can be found here: https://advisory.splunk.com/

The threat model used as a base in this blog is explained in more detail here: Trust boundaries and threat actors within the Splunk Enterprise ecosystem

Risky command safeguards bypass in Dashboard Examples Hub (CVE-2024-29946)

Overview

https://advisory.splunk.com/advisories/SVD-2024-0302
In Splunk Enterprise versions below 9.2.1, 9.1.4, and 9.0.9 and Splunk Cloud Platform versions below 9.1.2312.100, the Dashboard Examples Hub in the Splunk Dashboard Studio app lacks protections for risky SPL commands.

Threat analysis

The threat falls into zones N4 and N5. These zones have both admins as well as end-users accessing Search Heads.

Threat 1: A user gets phished and thus tricked into clicking a link that would trigger running bad or “risky” SPL
Threat 2: A rogue internal user would use this for his or her own benefit

Solutions

If you have a zone similar to N5
- If you are not using the Dashboard Studio App – disable it permanently and patch when convenient
- If you are using the Dashboard Studio App – disable the app immediately, until you have time to patch
If you only have a zone similar to N4
- If you are not using the Dashboard Studio App – disable it permanently and patch when convenient
- If you are using the Dashboard Studio App, assess the risk of users getting phished (most likely spearfished) in relation to your Splunk environment – if the risk is high, disable the app immediately, until you have time to patch
- Assess the risk of rogue users abusing this vulnerability (size of userbase is a good starting point) – if the risk is high, disable the app immediately, until you have time to patch

Finally, make sure you are only running the splunkweb process on servers that really need it – removing unnecessary splunkwebs from your infrastructure is part of good hardening practice.

Splunk Authentication Token Exposure in Debug Log in Splunk Enterprise (CVE-2024-29945)

Overview

https://advisory.splunk.com/advisories/SVD-2024-0301
In Splunk Enterprise versions below 9.2.1, 9.1.4, and 9.0.9, the software potentially exposes authentication tokens during the token validation process. Normally, Splunk Enterprise runs with debug mode and token authentication turned off.

Analysis

This vulnerability covers corner cases, where defaults in Splunk Enterprise have been deliberately changed for the worse.

The threat falls into zones N4 and N5. These zones have both admins as well as end-users accessing Search Heads – but exploiting this vulnerability requires administrator level privileges (or a heavily misconfigured Splunk instance).

Threat 1: A rogue Splunk administrator can find the token in the internal indexes and misuse it
Threat 2: A rogue OS administrator can find the token in the log files on the server

Solutions

If you are not running Splunk Search Heads in debug mode, patch when convenient.
If you ARE running Splunk Search Heads in debug mode, first ask your self why. If there is a true reason for doing that, assess the risk of your admins going rogue, then potentially stop the debugging to patch your system, and then finalize your debugging.

Finally, make sure you are only running the splunkweb process on servers that really need it – removing unnecessary splunkwebs from your infrastructure is part of good hardening practice.