As part of the more than 17,000 plugins available in the Nessus Direct and Registered plugin feeds, many of these look for common user name and password combinations. They will attempt to find administrator accounts without passwords, simple passwords and vendor defaults. Although these checks aren't performing an exhaustive brute force password audit, they may cause enough login failures to "lock out" operational accounts.
Tenable's research group recently introduced logic into the body of the Nessus plugin checks to prevent guessing of accounts. If auditors are running Nessus in a sensitive environment, they can now easily disable the types of plugins which could result in login failures on Windows and Unix systems.
This blog entry discusses account "lock outs", how the new plugin changes work, and what sort of security vulnerabilities might not be checked with this setting enabled.
Understanding Account Lock Outs
As part of hardening a system, users should choose strong passwords that are complex enough to avoid brute force guess attempts. In some cases though, an organization may feel the need to further secure a system by limiting the number of times an account can be accessed unsuccessfully. This can limit the ability for a hacker or insider to try many combinations of user names and passwords to gain access to a system.
A problem that can occur with this type of security is that scanning for a common list of default backdoors, vendor accounts or simple passwords can render the account locked. A locked account could require a certain amount of time before it can be accessed again or it could require some other types of administrator action to "unlock" it.
In an operational environment, we'd like to avoid any type of impact to the availability of the systems that are being scanned. For example, having a Windows 2003 server with its administrator account locked out could prevent a help desk from performing their job. In sensitive environments, some organizations require every login failure to be investigated.
Auditing Password Policy With the Direct Feed and Security Center
Nessus Direct Feed and Security Center users can audit remote UNIX and Windows systems for poor password policies in seconds. Rather than testing 100s, 1000s or even more different username and password combinations, a remote operating system can be audited to see if its password policy is complex enough.
For example, password policies can specify a minimum password length and how often it should be changed. These variables are obtained performing direct queries against the operating system and have no side effects. Testing against a policy is more efficient than testing against a list of 1000s or more of known potential passwords. These audit policy tests require remote credentials to audit the systems.
These types of checks are included in many of the audit policies Tenable has produced to meet NIST SCAP, PCI and Center for Internet Security standards.
Performing Tests With This Setting
Under the current set of plugins being distributed as of November 1st, 2007, there is a new plugin preference variable. Its name is 'Do not log in with user accounts not specified in the policy'.
To access this under the Nessus Client, create a new policy and view the option under the 'Global variable settings' drop down option under the 'Advanced' tab as shown below:
|
If this setting is checked, then Nessus will not attempt to log into a remote host with anything other than the accounts specified in the Credentials section of the scan policy.
If you have not updated your plugins since November 1st, this setting will not be available. These checks have been made available to both the Direct Feed and Registered Feed customers. Also, if you are using the new Nessus Client, you must create a new policy for this item to be available in the user interface.
Knowing When to Use This Setting
The focus of this plugin change is to prevent unintentional use of plugins that attempt a login vis SMB for Windows systems or SSH for UNIX systems.
There are several "vulnerability" plugins which look for common user name and password combinations. For example, attempting to see if a Windows 2003 server has a blank administrator password is a great security check, but the act of measuring it may cause a login failure.
If you have manually installed Hydra on your Nessus scanner and you also select those plugins for execution, Hydra will run unaffected by this setting.
For More Information
Information about the Direct Feed is available here. We've blogged in the past about how password auditing is accomplished much more efficiently buy auditing a policy than trying to brute force a password. Combining this new feature of not testing for user accounts specified with the scan policy along with the configuration auditing features of the Direct Feed is an excellent way to efficiently test your system configurations without impact.
If you are a Nessus 3.0.6 Windows user, the client distributed with along with the Nessus scanner does not support this new scan option. Instead, users should upgrade to the new Nessus Client 3.0.
