Validating Your Results

As with most automated procedures that haven't been tuned, the danger of false positives is revealed in the first few OpenVAS scans. The technical staff should analyze each issue to determine whether the item is a false positive. This analysis usually consists of verifying that a reported service is, in fact, running on an open port and is responding. Sometimes false positives are the result of the technical staff modifying the software locally, such as when vendors back-port patches into a supported version of a package. If possible, the quickest way to validate your results is to compare the version of the software running on the remote system against versions listed in the various vulnerability databases.

If the results appear valid, your next step might be simply to trust OpenVAS and follow the recommendations given in the report, which could entail disabling a server or service. However, if you're feeling inquisitive, you might want to recreate the issue manually to better understand the context.

Writing Plugins In NASL

Like Nessus, OpenVAS lets you create your own plugins for custom security checks with the Nessus Attack Scripting Language (NASL). See the NASL Reference Guide, which is available online [3] for more on working with NASL. Listing 1 addresses a few of the basic features you'll need to address when working with NASL.

In Listing 1, the description block holds metadata about the plugin, including a description of the vulnerability, details about the plugin category, and information on any dependencies the script might have. In this case, you can see that the check is for CVE-2009-3023, a stack overflow that was reported in Microsoft's IIS FTP server.

Below the description block is a definition of the check itself. As you can see, the script checks to see that the specified port is open and then makes a call to the internal knowledge base to ensure that a writable directory is detected by the dependency plugin ftp_writeable_directories.nasl. If this is the case, the script then connects to the port and fetches the FTP banner. Once it has a banner, it compares the banner against known vulnerable versions and reports as necessary. The check knows that version 5.0 is definitely vulnerable, so it reports a hole in this case, but in other cases where Microsoft FTP server is running, a warning is issued.

The code in Listing 1 is a fairly simple example of a NASL script. NASL is a domain-specific language with a lot of security-specific functions. Although some questioned Tenable's decision to implement a whole new language, NASL is designed to be secure and provide the tools necessary to check even quite complex vulnerabilities. The NASL language includes built-in functions for packet crafting, packet capture, and many other useful tasks.

Conclusions

OpenVAS is a valuable tool for managing vulnerabilities. Although a tool like OpenVAS is very useful for identifying potential issues in targets and products, it is up to the technical staff to act on the reports and resolve the issues.