Tenable Allows Least Privilege SSH Scans
Credentialed scans have long been encouraged as the quickest and most accurate way to perform a vulnerability assessment against any network. However, customer always run into problems which are related to users or process which need to be followed.
Usually when the discussion of credentials become topic of a conversation, further questions are asked; who? why? what? Nevertheless, from a business perspective these are legitimate questions which should be rightly asked. This then causes many conversations between the people involved and then meaning polices and procedures have to be created. Eventually a final decision will be made either to grant access for the credentials; denied or not the correct privileges which was initially discussed.
To help solve this problem, Tenable provided transparency around which commands are run by a Nessus® scan, what privileges are required to run the commands and if the commands failed, which Nessus plugins would fail as a result.
- Nessus 6.11 or later, either standalone or managed by Tenable.io Vulnerability Management or SecurityCenter
- Scan Target Operating System
- CentOS, Redhat, Amazon Linux, SuSE, Ubuntu, Debian, HP-UX, Scientific Linux, AIX, Oracle Linux, Gentoo.
At a high level, the process can be summarised in five simple steps:
- Configure a scan account to run with sudo privileges
- Enable ‘Attempt Least Privilege’ preference in scan policy
- Review plugin output of Nessus plugin IDs #102094 and #102095
- Update /etc/sudoers file based on results on plugin #102094
- Repeat Step 4, until commands which run with higher privileges are accounted in /etc/sudoers file
Step 1: Configure user to run commands via sudo
Log in to the system as the root user and create a normal user account. Run visudo to edit the /etc/sudoers file, and add the commands the user is allowed to run with sudo. In the example below I created a user ‘nessus_scan_account’ assigned it SUDOER User_Alias who can run the ‘/usr/bin/dmidecode’ command which requires root privileges to run.
Step 2: Enable ‘Attempt Least Privilege’ checkbox in scan policy
Follow the below steps to enable ‘‘Attempt Least Privilege’ preference in the scan policy.
Tenable.io Vulnerability Management & Nessus
Click Scans -> New Scan -> Advanced Scan -> Credentials -> SSH -> Attempt Least Privilege
When this preference is enabled, Nessus plugins attempt to execute commands with least privileges (i.e. without privilege escalation), and if the initial attempt fails, it retries executing the command with privilege escalation. It also logs commands which failed and succeeded with privilege escalation and reports the information in two plugins (#102094, #102095) which will be discussed in the next steps. As a result of running the same command twice, customers should note the scans could run 10-30 percent slower according to our lab tests.
For Security Center, follow the below screens to enable the preference.
Click Scans -> Policies -> Add -> Advanced Scan -> Authentication -> Attempt Least Privilege
Step 3 : Review Plugin Outputs
Once the scan finishes, review output of plugins #102094 and #102095 to determine which plugins successfully ran with privilege escalation and which plugins failed due to insufficient privileges.
SSH Commands Ran With Privilege Escalation (#102095)
Plugin #102095 reports all plugins which ran with escalated privileges. The plugin output is in YAML, and includes information about the account used, plugin file name, id, name and the command it ran. This plugin will help users verify only authorized commands are run with sudo privileges.
SSH Commands Require Privilege Escalation (#102094)
Plugin #102094 reports all plugins which failed to run with escalated privileges due to insufficient privileges. As was the case in the previous plugin, the plugin output is in YAML to facilitate easier creation of /etc/sudoers file. It includes information about the account used, plugin file name, id, name, and the command it ran.
Customers should review the output of this plugin to fine tune the commands which can be run with the sudo account. Note the command ‘cat /etc/shadow’ failed in the below example. We will resolve this issue in the next step.
Step 4 : Update /etc/sudoers file
In the previous step, plugin #102094 reported execution of command ‘cat /etc/shadow’ failed due to privilege escalation failure. We can easily resolve this by adding ‘/bin/cat /etc/shadow’ as an allowed command to the SUDOER alias we created earlier in /etc/sudoer file, which will allow the next scan to run this command successfully with escalated privileges. You could also continue to block certain privileged commands from running by not updating the /etc/sudoers file and accepting the risk of certain vulnerabilities not being detected due to incomplete information.
Step 5 : Repeat
To perform an accurate authenticated scan, repeat step four such that commands that fail are accounted in the /etc/sudoers file.
At this point, one might wonder, “Why not just share a static list of ssh commands with customers?” The reason is two-fold. First, we routinely add new commands to our plugins, so there is a risk of a static file going stale. And second, we don’t always know if a command will require admin privileges across a wide variety of operating systems.
In this blog post, we demonstrated how a user can create a tailored Nessus scan account to perform authenticated scans over SSH with the least privileges required to perform the scan. Currently, the feature is supported on a limited number of OSs, and we expect to roll out support for additional OSs over the next few months. If you have feedback about the feature, please reach out to us here, we would love to hear from you.