CVE-2023-46231 - How a Logging Snafu in Splunk Add-on Builder Leaked User Session Tokens

Splunk is a powerhouse when it comes to ingesting and analyzing machine data, but like all complex systems, its add-ons and plugins need careful security attention. In late 2023, a critical vulnerability—CVE-2023-46231—was disclosed, revealing that Splunk Add-on Builder versions under 4.1.4 were carelessly logging sensitive session tokens. If you’re in an IT or security team using Splunk, this post will walk you through what happened, show you how the vulnerability works, and explain how to protect yourself.

What Is Splunk Add-on Builder?

Splunk Add-on Builder is a popular utility that helps Splunk admins develop, test, and package custom add-ons for Splunk. It offers a simple, web-based interface—eliminating much of the manual work but also introducing some new risks.

The Vulnerability in Plain English

CVE-2023-46231 affects *all versions of Splunk Add-on Builder before 4.1.4*. The bug: When users accessed the Add-on Builder, or built/edited a custom app or add-on, their Splunk session tokens were written into the app’s internal log files.

Session tokens are digital "badges" that identify an authenticated user. Whoever holds them can impersonate that user—making their exposure a big problem.

They ended up in log files within the Add-on Builder's local directory, for example

$SPLUNK_HOME/etc/apps/splunk-addon-builder/local/addon_builder.log

Here’s a simplified Python snippet resembling the original, faulty logging behavior

# Simplified example: BAD! Don't log sensitive data!
def authenticate(user_input):
    token = issue_session_token(user_input)  # Returns user session token
    logger.info(f"User '{user_input['username']}' got session token {token}")  # The leak

Every time authentication happened, the full session token would be dumped into addon_builder.log.

Attack Scenario

1. An attacker with *read access* to the Splunk filesystem (local, or sometimes via remote tools) grabs the addon_builder.log file.

The attacker pulls out valid session tokens from the logs.

3. Using the stolen tokens, the attacker can authenticate as other users via Splunk’s REST API, gaining whatever access those users had.

That means a single log file could be a master key for your Splunk environment if attackers were able to grab it.

Let’s try a rough way an attacker might extract tokens with a simple shell command

grep -Eo "session token [a-zA-Z-9\-]+" $SPLUNK_HOME/etc/apps/splunk-addon-builder/local/addon_builder.log

Or with Python

import re

with open('addon_builder.log') as f:
    log = f.read()

tokens = re.findall(r"session token ([a-zA-Z-9\-]+)", log)
print(tokens)

The vulnerability was responsibly disclosed, with details shared here

- Splunk Security Advisory - SPL-168571
- NVD Entry for CVE-2023-46231

The fix: Version 4.1.4 and above of Splunk Add-on Builder now strip session tokens before logging.

If you’re using Add-on Builder below 4.1.4, upgrade ASAP.

1. Patch

- Download the latest version (4.1.4+) of Splunk Add-on Builder and install it.

2. Scrub Logs

- Delete or securely archive and audit all addon_builder.log and similar files produced before the patch.

3. Revoke Compromised Tokens

- Force a logout for all users, or cycle session tokens, to invalidate any that may have accidentally been exposed.

Conclusion

The CVE-2023-46231 story is a classic logging mishap with serious consequences. It’s a good lesson: never log session tokens or other secrets—even in internal logs! If you use Splunk Add-on Builder, make sure to update and review any old logs for exposure.

For developers and system administrators: Always double-check what you’re logging, especially in highly privileged systems like Splunk.

References

- Splunk Advisory: SPL-168571
- NIST NVD: CVE-2023-46231
- Add-on Builder on Splunkbase: https://splunkbase.splunk.com/app/2962/

Timeline

Published on: 01/30/2024 17:15:10 UTC
Last modified on: 02/05/2024 20:59:05 UTC