Recently, Tenable’s Research group added the ability for Nessus credentialed scans to automatically start and stop the Windows Remote Registry service. This blog entry discusses the technical and political ramifications of this new feature.
Scanning Systems without the Remote Registry service running
The Remote Registry service allows remote computers with credentials to access the registry of the computer being audited. If the service is not running, reading keys and values from the registry won’t be possible, even with full credentials.
Here is a screen shot of a Windows 2003 server that does not have the Remote Registry running:
You can see that although it is "Automatic" and should be running at boot, for some reason, it has not been started. When scanning this Windows 2003 server with a credentialed Nessus scan policy, plugin #26917 will generate a warning that the registry could not be read:
This can be an issue when scanning Vista workstations, as Vista disables the registry service by default.
Nessus is usually very accurate because it performs file level checks for patch auditing However, the registry is a vital part to performing a complete audit as many vulnerability checks in the Tenable Home and Professional Feeds leverage registry access to determine the remote version of the Windows system, the location of system files, etc.
You can enable the Remote Registry service during the scan
Recently, Tenable added the ability to start the Remote Registry service during a credentialed scan. This requires auditing Windows servers with an Administrator account. Note that this feature is disabled by default.
To configure a Nessus scan policy, enable the four plugins in the “Settings” plugin family that start and stop the Remote Registry service and determine if the service was started or stopped correctly. A screen shot of these plugins (#35703, #35704, #35705 and #35706) is shown below:
Enabling these plugins is not enough. A scan preference is also required and is available under the Advanced scan policy tab as shown below:
If the plugins are enabled and the scan preference is also set, then Nessus will attempt to start the Remote Registry service (if it’s not running already) before attempting a credentialed audit of the Windows computer.
All Windows OSes (Windows XP, 2003, Vista and 2008) are supported by these plugins.
Political and Audit Ramifications
There are several non-technical issues to consider when using these new plugins in your infrastructure.
Is this secure?
If your organization has a policy that restricts running the Remote Registry service on Windows platforms, this new functionality provides the option to keep this service disabled.
The concern over running this service could come from external sources. There are many public and government regulations that recommend that the Remote Registry service be disabled. Some organizations turn these recommendations into required baseline configurations.
If leaving the Remote Registry service running in your organization is considered a security risk, these new plugins provide the ability to only run it for a few minutes during an audit and then turning it off. This enables you to get the essential information while limiting the security risk of leaving the Remote Registry service running all the time. Note that starting and stopping the Remote Registry service may come under your organization’s Change Management Policy.
Also note that if Nessus has the privileges to start the registry service remotely, any attacker with the same privileges could do the same.
Is this compliant with my security policy?
If you are using Nessus to perform FDCC, DISA STIG or Center for Internet Security Windows configuration audits, it is very likely that these policies will test to ensure that the Remote Registry service is not running. If this is the case the audit will fail during the scan.
However, the results of the scan will show the following two informational vulnerabilities:
These records show that the service was stopped before the scan was completed.
If this did not meet the criteria for a particular type of audit, you could follow up this scan with a second scan that showed the registry service was indeed disabled.
How Does This Impact IT?
As with all things in IT, it is strongly recommended that you test this functionality in your environment. Tenable performed extensive testing of this technology prior to releasing it, but there are many issues to be considered:
- Starting and stopping the Remote Registry service generates Windows event logs. If you run a SIM or log management tool that can detect change purely through log analysis, inform your security monitoring team about this new type of audit so they do not become alarmed.
- If your IT group has any third party tools that continuously monitor and “force” the registry off, the Nessus scans will still run, but at some point when the registry gets disabled, the scan results that require registry access won’t run.
- If you perform a scan and lose connectivity in the middle of an audit, or if you manually stop the scan in the middle of an audit, you could end up leaving the Remote Registry Service running on the scanned server.
- If you are auditing servers that are extremely short on available CPU, memory or disk I/O, starting the Remote Registry service could take long.
Typically though, the impact on IT from performing these types of audits is very low. The screen shot below shows a full patch audit with the dynamic enabling and disabling of the Remote Registry service on an underpowered Windows 2003 virtual machine:
That is less than a minute for a full patch and vulnerability audit on a Windows 2003 server. During the scan, there was very little CPU or memory usage as a result of the audit.
For More Information
This functionality is available to all Nessus users, including those using the Home Feed to audit their personal computers and networks, as well as to Professional Feed subscribers who can make use of this technology to audit corporate, university and government networks.
If the topic of IT auditing interest you, we have many other excellent blog entries on this subject listed below:
- Knowing When to Patch
- Testing the Effectiveness of your Patch Management System
- Finding Vulnerabilities older than 30 Days