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.

01 desc = "Microsoft IIS FTPd NLST stack overflow
02
03 The Microsoft IIS FTPd service may be vulnerable to a stack overflow
04 via the NLST command. On Microsoft IIS 5.x this vulnerability can be
05 used to gain remote SYSTEM level access, whilst on IIS 6.x it has been
06 reported to result in a denial of service. Whilst it can be triggered
07 by authenticated users with write access to the FTP server, this check
08 determines whether anonymous users have the write access necessary to
09 trigger it without authentication.
10
11 On the following platforms, we recommend you mitigate in the described
12 manner:
13
14 Microsoft IIS 5.x
15 Microsoft IIS 6.x
16
17 We recommend you mitigate in the following manner:
18
19 Filter inbound traffic to 21/tcp to only known management hosts
20 Consider removing directories writable by 'anonymous'
21
22 Solution:
23 We are not aware of a vendor approved solution at the current time.
24
25 See also:
26 http://www.securityfocus.com/bid/36189
27
28 Risk factor: High";
29
30 if (description)
31 {
32         script_id(100952);
33         script_cve_id("CVE-2009-3023");
34         name = "Microsoft IIS FTPd NLST stack overflow";
35         script_name(name);
36         script_description(desc);
37         summary = "Determines whether Microsoft IIS FTPd is accessible and whether anonymous users have write access";
38         script_summary(summary);
39         script_category(ACT_GATHER_INFO);
40         family = "FTP";
41         script_family(family);
42         copyright = "(c) Tim Brown, 2009";
43         script_copyright(copyright);
44         script_dependencie("find_service.nes", "secpod_ftp_anonymous.nasl", "ftp_writeable_directories.nasl");
45         script_require_keys("ftp/writeable_dir");
46         script_require_ports("Services/ftp", 21);
47         exit(0);
48 }
49
50 include ("ftp_func.inc");
51
52 port = 21;
53 if (!get_port_state(port))
54 {
55         exit(0);
56 }
57 if(!get_kb_item("ftp/writeable_dir"))
58 {
59         exit(0);
60 }
61 banner = get_ftp_banner(port);
62 if (!banner) {
63         exit(0);
64 }
65 if ("Microsoft FTP Service (Version 5.0)" >< banner){
66         security_hole(port);
67 }
68 else
69 {
70         if ("Microsoft FTP Service" >< banner){
71                 security_warning(port);
72         }
73 }

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.