When Patch Auditing Tools Collide

I recently had a customer report they were experiencing Nessus “over reporting” when compared to his Windows patch auditing tool. This blog reviews some of the many reasons you can get different results with different tools, especially on Windows operating systems.

Your patch auditing tool could be incorrect or not as accurate as you think

A patch auditing tool that only checks a program’s registry settings and does not perform actual file inspection can make erroneous assumptions. There are many instances where a Windows operating system can have a patch seemingly applied, but not actually in effect, leaving the system in an unknown state. For example, there could have been an error during the patch update process or the patch required a reboot to take effect.

Nessus overcomes this by using the SMB protocol to look at the actual version information of the relevant DLL and other files for the program being audited. This check is slightly slower than a registry check, but it is more accurate and reliable.

In addition, as Tenable’s Discussion Forum user swtornio points out:

"One particularly annoying vulnerability is "MS08-070: Vulnerabilities in Visual Basic 6.0 ActiveX Controls Could Allow Remote Code Execution (932349)." Nessus finds a vulnerable version of C:\WINDOWS\system32\Mscomct2.ocx, but Windows will only report the patch is necessary if Visual Studio or FoxPro is installed. The file is packaged with applications created by those products, so if you're the end user of a VS or FoxPro developer, it's likely that this control was delivered to you as part of their installation package, but Windows won't think an update is required."

Previous blog posts have discussed testing the effectiveness of your patch auditing system, and that some patch audits can be misleading. Tenable also recently added a Nessus check to see if a Windows computer needs to be rebooted in order to complete the patch process. Often, when pushing out patches via WSUS or some other type of mechanism, a Windows computer is not fully patched until it is rebooted. The patch may be applied and the registry settings may be set, but the application that is still running is still vulnerable.

There could be an issue with a Nessus check

Vendors never like to admit that they can make mistakes and anyone who has worked with Tenable knows that we get the vast majority of Nessus checks correct. More importantly, the things we don’t get right we tend to fix very quickly, usually just requiring a plugin update.

If you think you have found a bug with a Nessus plugin, please consider the following:

• Have you updated your plugins recently? Tenable pushes out new plugins and enhances the performance and accuracy of many other plugins on a daily basis. With the large number of Nessus users, Tenable receives a consistent stream of feature requests and enhancements for plugins, as well as reports about how the plugins interact with more exotic and uncommon network devices and applications.
• If you are simply comparing the results of two other scanners, there is not much for us to go on. Very often, other patch auditing tools rely solely on the registry, so you may have two incorrect testing tools.
• You may not be testing with Administrator credentials. We’ve run into false positive or false negative issues with Nessus where a check could not complete because the permissions of a service, registry setting or file were too restrictive for the account given to Nessus to perform the audit.
• If the plugin is a NASL script, attempt to read the plugin logic and see what sort of files and settings it is testing and then verify that the machine is indeed vulnerable. A larger percentage of our “Nessus bug” support tickets never make it to our Nessus plugin team because it is a mis-configuration at the customer premise.
• If you are a HomeFeed user, consider publishing your concerns on the Discussion Forums. Security Center and ProfessionalFeed users also can leverage the Forums, but also have the opportunity to open up a support ticket on the Tenable Support Portal.

An official patch or fix does not exist

Tenable’s policy is to test for patches for vulnerabilities that have been officially publicly disclosed from the operating system or application vendor. This means that if there is a zero day exploit discussed in the media, Tenable will not likely write a Nessus plugin to look for the issue. We do however make sure that Nessus can detect and report on the applications in general, so that users can indeed find certain versions of potentially vulnerable software if needed.

More and more enterprises are subscribing to vulnerability alert services where they can receive alerts about vulnerabilities for specific operating systems and applications that are in use in their infrastructure. For example, your organization may be officially using Internet Explorer 7 and would like to ignore any vulnerability reported for Internet Explorer 6 or Internet Explorer 8.

These types of services generate alerts and reports on vulnerabilities that may not yet have an available patch or may not have been acknowledged by the responsible vendor.

During the time between when a vulnerability is disclosed and when a patch is made available, it is very possible that vulnerabilities can get reported where there is no corresponding patch from the vendor. If you have tied this subscription into your asset management system, it is possible you can find servers that are vulnerable, yet fully patched.

In recent years, both Real Audio and Adobe have had popular products with vulnerabilities for which there was no patch. In those cases, Tenable ensured that these products and versions could be detected but would not alert on the presence of a missing patch since there was no patch available for the given issue.

For More Information

Patch auditing is something we’ve blogged about several times over the past few years:

• How did you test for MS08-67?
• Misleading Patch Audits
• Testing the effectiveness of your patch auditing system
• Knowing when to patch
• Common Mistakes in vulnerability and compliance reporting