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)
... View more
