Risk Vulnerability Assesment for list_storage_passwords

[Mitch_TA_Debug]

Does anyone know of a risk assessment done for apps like the Cisco SNA addon Cisco Secure Network Analytics (Stealthwatch) App for Splunk Enterprise | Splunkbase that require all users to have list_storage_passwords capability? 

Does this capability mean that users (once authenticated) could craft a request that would provide them with a sensitive password in plaintext?

Thanks

[effem]

list_storage_passwords is a capability. That means users with a role providing this capability will be able to show credentials in the credential-store for any app, where the have read-access to the credential-store.

In example.

If the app has this metadata/default.meta:

[]
access = read : [*], write : [admin]

Anyone can read the passwords/credentials in this app, if the user has the "list_storage_passwords" capability.

If an app has this default.meta

[]
access = read : [*], write : [admin]

[passwords]
access = read : [ trustworthy_role, admin ], write [admin]

Only users with the trustworthy role can see the credentials.

Make sure you restrict app-access to the people which need the access. That way you can give list_storage_credentials to roles with the risk of having people access credentials, which they are not supposed to access. 

You can also set the read/write access more granulary with [passwords/credential%3Arealmname%3Ausername%3A]

Read more here: https://dev.splunk.com/enterprise/docs/developapps/manageknowledge/secretstorage/secretstoragerbac

[Mitch_TA_Debug]

Thanks for the insight. Does this also mean that, once authenticated with hypothetically stolen account credentials, an attacker could retrieve plaintext passwords simply with REST commands?

[PickleRick]

1. Normally a non-admin user should not have this capability. This is normally used for maintaining credentials which are used for third party integrations (modular inputs, custom alert actions).

2. This works for credentials managed in the official Splunk way. If - for some reason - an addon developer decided to do something "their own way" (for example - decided that for each run of an input, it will pull credentials from a github project; no, that's not a real example but nothing is forbidding an addon author from inventing anything, no matter how stupid), that will most probably not be limited by this capability.

3. Obviously if there are credentials for access stored for use in automated way, you should have additional controls implemented on the destination system mitigating risk of abuse of those credentials. Their use of course should based on the rule of least required privilege and ideally they should be limited per IP. At the very least, if there is no other way, their use in the destination system should be monitored and reviewed regularly.

[effem]

Thats correct. Hence its important to secure your Splunk environment properly.
Use MFA and SAML in example.
For more:
https://docs.splunk.com/Documentation/Splunk/latest/Security/WhatyoucansecurewithSplunk