topic Re: Splunk 5.0 Vulnerability in Splunk Search

Splunk 5.0 Vulnerability

yap — Mon, 31 Dec 2012 08:46:03 GMT

I've encountered with this finding at Packetstorm website. May I know whether Splunk already verified and acknowledge on the finding as we plan to upgrade our Splunk to that latest version.

http://packetstormsecurity.com/files/118697/Splunk-5.0-Custom-App-Remote-Code-Execution.html

Re: Splunk 5.0 Vulnerability

Drainy — Mon, 31 Dec 2012 08:54:49 GMT

Well, this one has been floating around a while and I don't personally consider it a vulnerability.

Basically, it depends on you installing Splunk, not changing the default password (which it asks you to do on the first login), running it as root - which is not "default" as the vuln page says. Its generally something silly people do to make reading /var/log easier.

Run it as the "splunk" user that the install package creates, change the admin password, create your own account and delete the admin user - nothing to worry about.

If you were to call this a vuln then it technically affects 4.2 and 4.3 as they all have the same script execution behaviour 😉

EDIT: FYI, The Splunk Security portal can be found here; http://www.splunk.com/page/securityportal

Re: Splunk 5.0 Vulnerability

dwaddle — Mon, 31 Dec 2012 21:18:56 GMT

I agree w/ Drainy here. The ability to run scripts from Splunk is a feature - those scripts will run under whatever operating system authority you start Splunk as. The ability to upload apps (which can contain scripts) is also a feature, and is only available to users who have authenticated to Splunk and have the proper access within Splunk.

If your Splunk environment is properly configured and hardened, then your exposure to this vulnerability is limited to "how well can I trust my users with Splunk admin rights?"

In a potentially hostile environment, many good practices apply, including:

Change the 'admin' password, and/or delete the 'admin' account
Minimize the set of users with admin-equivalent access
Don't run Splunkd or Splunkweb as root
Firewall the Splunkd / Splunkweb TCP ports as appropriate
Establish and enforce a change management policy for app installs / updates
Use Splunk itself to search/alert upon logged events around app changes
Use a file change monitor to look for changes to the scripts within permitted Splunk apps

If this cannot provide you with sufficient risk mitigation, it may be possible to completely disable scripted inputs and other script-calling features within Splunk. You would do so, however, at a great functionality cost. If this is the route you wish to take, I would recommend opening a support case and documenting your concerns and asking for help with configuring Splunk to remove as much script-calling functionality as possible. (Again, you will probably not be happy with this decision functionality-wise)