Nessus Spotlight: su+sudo Feature

With the release of Nessus 4.2.2 a new method of credential elevation has been included for Unix-based hosts that have sudo installed: “su+sudo.” This method allows you to provide credentials for an account that does not have sudo permissions, su to a user account that does, and then issue the sudo command. 

This configuration provides greater security for your credentials during scanning, and satisfies compliance requirements for many organizations.

To enable this feature, simply select “su+sudo” in the “Elevate privileges with” section under the credentials/SSH settings as shown in the following screen shot:

Under the “SSH user name”, and “SSH password” tabs, enter the credentials that do not have sudo privileges. In the example above, the user account is “raven.” From the “Elevate privileges with” pull-down menu, select “su+sudo.” Under the “su login” and “su/sudo password” tabs enter the user name and password that do have privileged credentials, in this example “sumi.”

No other scan policy changes are required.

Important Note Regarding sudo

Some Unix-based configurations have a requirement that sudo-initiated commands be performed from tty sessions. To determine if this is the case for your Unix distribution, enter the following command as root on the system you will be scanning:

This presumes that the sudo configuration file is located in the /etc directory. If you are not sure, check your system documentation for the location of sudo. 

If you see a line in the /etc/sudoers similar to the following, follow the sudo configuration change instructions below:

sudo Configuration Change Instructions

The “requiretty” line in the sudoers configuration file specifies that all commands issued via sudo be performed from a tty session. Nessus vulnerability scans performed with the "su+sudo" option do not match that requirement. If you are using the “su+sudo” option you will need to create an exception on the target system. 

Edit the /etc/sudoers file and add an exception after ‘requiretty” line as follows:

Note that {userid} is the user name that will be used to execute the “sudo” command (the “su login” field in the credentials/SSH section of your policy). Also, make sure you have the following line in your sudoers file:

Again, {userid} is the user name that will be used to execute the “sudo” command (the “su login” field in the credentials/SSH section of your policy). These changes will allow your su+sudo credentials to provide an accurate vulnerability scan.