Cатсн²² (in)sесuяitу / ChrisJohnRiley

It’s been a while since my last update… with a mixture of neck issues (resulting in a forced absence from computer use) and preparation for a number of talks I’m doing, it’s been hard to fit things in. To ease back into things I’ve got a quick tip about Nessus sudo/su/sudo+su functions that I’m sure will come in handy for people somewhere down the road… or at the very least save somebody a few hours of searching through code to find a solution.

Background:

Nessus provides a couple of interesting functions for local scans and audit checks. In order to use these local checks you’re required to provide SSH or Windows credentials that allow the scanner to access a target machine remotely and run commands locally. Due to the type of checks made (things like the CIS audit checks) some of these commands need access to areas and commands that are restricted. As a result the results of your local scans can be affected if you provide non-administrative access.

Due to the way *nix based systems handle SSH access (i.e. root SSH is blocked, at least it SHOULD be) the nice folks over at Tenable have provided a few options. Those options are :

• Sudo
• su
• Sudo + su

That seems to cover the bases right! You provide it with a normal user account that has sudo permissions, or su (with a given password), so that the administrative commands and checks can be made without a problem.

The problem:

We all know long beard *nix types are a little crazy (in a good way obviously)… you never can tell what you’re going to get when you ask for sudo or su permissions. Maybe it’s a shell script you run that then runs the command on your behalf, maybe it’s some crazy LDAP authentication that needs a special key, cert, option,. The diversity and flexibility of *nix is both wondrous and painful. So what’s a tester to do when you get instructions on how to run your local checks and realise this is never going to fit into the Sudo, su, Sudo+su functionality provided….

The Code:

Looking around in the depths of Nessus code you find a few interesting things.

nessus/run/lib/nessus/plugins/ssh_func.inc (snippet)

  if (su == SU_SUDO)
    cmd = string('sudo -u root -p Password: sh ', cmd);
  else if (su == SU_SU)
    cmd = string('su root ', cmd);
  else if (su == SU_SU_AND_SUDO && ! isnull(sulogin) )
    cmd = string('su ', sulogin, ' -c "sudo -u root -p Password: sh ', chomp(cmd), '"\n');

Pretty simple to understand even for a non-programmer like myself… the bits that get filled in automatically at time of running like “cmd” and “Password:” aren’t really a problem for us here (at least that’s my understanding based on a few minutes with the code). The \n in this case represents a new line (just consider it you pressing enter if you were running these commands at the terminal). Handy for those cases when you need multiple commands run one after the other.

The solution?

As we have to stay within the constraints of how Nessus works (mostly) we can’t just add another option, we’re going to need to change one of the existing options.

As an example we’ll change the SU_SU match so that it runs something other than “su root”

original code from ssh_func.inc

  else if (su == SU_SU)
    cmd = string('su root ', cmd);

altered code

  else if (su == SU_SU)
    cmd = string('su admuser\n/usr/bin/authenticate.sh\n ', cmd);

Pretty simple really.. but we’re not done yet. As a security measure Tenable put hash checking in place for all plugins (check line 1 of your plugins for the line that says #TRUSTED followed by a hash value). Good plan, but this means the hash isn’t going to match for this file anymore. For this to work we’re going to need to change a configuration option in nessusd.conf.

original configuration from nessusd.conf

# Should consider all the NASL scripts as being signed ? (unsafe if set to 'yes')
nasl_no_signature_check = no

altered configuration

# Should consider all the NASL scripts as being signed ? (unsafe if set to 'yes')
nasl_no_signature_check = yes

Right now you’re thinking the same as I was…. “but it say that’s unsafe”. Yep it is… no don’t leave it like that! From what I know it’s not possible to have a single file excluded from the check. It’s all or nothing here. So keep a backup of the original trusted ssh_func.inc and only rotate your edited version in when needed!

Before you’re ready to roll you’re going to need to run one final command to reload the nessus plugins. Drop to a command prompt, navigate to your nessus bin directory and run nessusd -R to force it to reload the altered plugin from disk… that’s it, you’re ready to deal with even the oddest *nix admin!

Thanks to Paul Asadoorian for his help getting things running… thanks Paul!