Splunk Universal Forwarder Hijacking

Background

Splunk Universal Forwarder includes a management service that is listening on TCP port 8089 and is used for managing the forwarder. By default it accepts remote connections, but doesn’t allow remote connections with default credentials (admin/changeme). The exploit described below can be used in the following ways:

• Local privilege escalation to the user that the forwarder is running under, if the default password is not changed.
• Remote command execution (with the privileges that the forwarder is running under) if the default password has been changed and is known to the attacker.

Please note, this does not necessarily qualify as a vulnerability in the product, though running a management service on the forwarder is not a good architectural decision in my opinion as it increases the attack surface unnecessarily. Not running the service, or forcing to change the default admin password on install, would’ve been better options. The forwarder does not have any account lockout mechanism in place, so admin password brute forcing is feasible.

How Does It Work

1. Connect to the Splunk Universal Forwarder management port, authenticate with provided or default credentials, and configure the forwarder to use the attacker controlled machine as the deployment server.
2. The forwarder then connects to the attacker machine and requests deployment applications.
3. The exploit responds to the request with a fake application containing a script input instructing the forwarder to run the script.
4. After a delay, the exploit connects again to the forwarder management port and reverts the deployment server configuration.

The Exploit

The code can be found here: https://github.com/airman604/splunk_whisperer

Exploit parameters (review and change within the .py script):

RHOST — target machine, 127.0.0.1 for local privilege escalation. Default Splunk credentials are only accepted for local connections.

RPORT — management port of the Splunk Universal Forwarder, 8089 by default.

LHOST — attacker’s IP where the for

LPORT — port number to run the fake deployment server on.

SPLUNK_USER/SPLUNK_PASSWORD — credentials to authenticate to the forwarder.

SCRIPT — path to the script to be sent to the forwarder for execution.

Mitigation

Option 1: use “UF password changer” app from splunkbase (https://splunkbase.splunk.com/app/2722/) to set random admin password on all of your Universal Forwarders.

Option 2: disable management network port on the forwarder by adding the following to $SPLUNK_HOME/etc/system/local/system.conf:

[httpServer]
disableDefaultPort = true

This can be done remotely from the deployment server: https://answers.splunk.com/answers/434029/how-to-disable-the-universal-forwarder-default-man.html

Note: this might not be a supported configuration, and some CLI commands will stop working (for example, splunk show deploy-poll) as they use the management service.