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:
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.
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.
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.