Updated Reporting for Scan Permissions Issues

How does a Nessus scan report when a permission denied issue prevents the detection of an asset or a service or the presence of a vulnerability? Today those issues are reported by plugin 110385 as "insufficient privilege". This can be misleading and frustrating for customers who know they are scanning with full privilege escalation or as superuser.

Summary

We have updated the way Nessus scans report permission denied errors so that when these errors occur while scanning with the highest privilege they are not reported as insufficient privilege. A new plugin has been created to report when a scan encounters permissions problems when operating at the highest privilege level of the target. The new plugin presents the issues and discusses possible environmental causes.

Plugin 110385 will continue to report information about insufficient privileges for scan accounts that are not superuser or administrator level accounts. 

Implementation

Different targets present different ways to determine what privilege level the scan is running at. For Linux and other Unix-like systems maximum privilege is achieved with uid=0. On some of these systems it is possible to achieve high privilege levels by adding users to special groups (root or wheel), but the actual root user (uid=0) still has higher privileges.  

On Windows systems the terrain is far more complicated. For these systems, the best test available is whether a user has access to a local system's administrative shares (c$, admin$, ipc$, etc). Access to these is granted by the system itself and only to users with local administrator privileges. A Nessus scan is considered to be operating with the highest possible privilege if access to those shares is available.

Windows systems also possess special accounts with higher privileges than local administrator such as SYSTEM, LOCAL SERVICE, and others. However, those accounts and privileges are not required or used by Nessus to detect assets, systems and vulnerabilities.  

Impacts

Some customers may experience a reduction in the number of plugin 110385 reports. This could happen because the scan is being performed with maximum privilege, either by using a superuser credential directly or through privilege escalation. The reports are not gone, instead they will appear in the output of the new plugin, which is designed to report permission denied issues under these more specific conditions.

Remediation

Going forward, customers will be able to address scans that trigger a plugin 110385 report either by adding privilege escalation to their scan credentials or by scanning as root or a local administrator.

Scans that trigger the new plugin reports are already scanning at the highest privilege level possible. Permission denied issues with these scans require more careful analysis to determine the root cause. It may be that access to a resource that Nessus requires is restricted even from the most privileged users.   

Affected Plugins

110385 -Target Credential Issues by Authentication Protocol - Insufficient Privilege

150799 -Target Access Problems by Authentication Protocol - Maximum Privilege Account Used in Scan  

Estimated Release

7/12/2021