In earlier parts of the Nessus 3 Tutorial, topics included how to install and configure Nessus, and how to run a basic security scan. Up until this point, however, signatures have come from the large database provided by Tenable Network Security's subscription feed. The signatures are definitely a great source of up-to-date vulnerability information, and they provide protection against most threats known to exist in the wild. There's one scenario, however, that isn't addressed by the database approach: custom applications that have been written within your own organization and have known vulnerabilities.
Starting with an example
As a hypothetical, suppose you have a custom Web-monitoring application called KillerApp that contains a known vulnerability in a file named "killerapp.asp." This application ran on every Web server in the environment until you discovered that it contains a critical vulnerability allowing an anonymous user to shut down the servers. The application has since been removed, but you suspect that some servers may still have it installed. Fortunately, the Nessus Attack Scripting Language (NASL) can be used to write a custom Nessus "attack," or a check that can find "killerapp.asp."
First, I'll show you the entire NASL script for this type of scenario. Then we'll dissect it to explore the NASL structure. Here's the whole script:
#
# KillerApp check
#
if (description)
{
script_id(50000);
script_name(english:"Check for KillerApp");
script_description(english:"KillerApp is a high-risk application and should be removed.");
script_summary(english:"Checks for KillerApp");
script_copyright(english:"Copyright 2008, Mike Chapple");
script_category(ACT_ATTACK);
script_family(english:"Denial of Service");
script_require_ports("Services/www",80);
}
include("http_func.inc");
include("http_keepalive.inc");
port = get_http_port(default:80);
if (get_port_state(port))
{
if (is_cgi_installed_ka(item:"/killerapp.asp",port:port))
{
security_hole(port);
}
}
NASL script structure
Notice that the NASL script has two distinct sections: a description of the plan, and a layout of the attack contents. The description section begins with the "if (description)" statement and includes all of the statements contained within the curly braces ("{…}") following it. Many of the items in that section are self-descriptive. Some notable ones:
: sets the script identification number, which must be a unique integer between 1 and 99,999. It's a good idea to choose a high number to avoid conflicting with other Nessus checks (both those that are user-created and those that are downloaded from a Nessus feed).
script_category(ACT_ATTACK): sets a category for the check. In this case, the script checks for a vulnerability that would allow a hacker to carry out an attack, so we use the ACT_ATTACK category. Another example, ACT_GATHER_INFO, is used when the NASL script indicates the possibility of a reconnaissance vulnerability.
script_require_ports("Services/www",80): defines required ports for the success of the attack. In this case, we're specifying that the attack should only be run if the target system has a Web server running on port 80.
The remaining portion of the script defines the attack itself. Let's take it line-by-line:
- port = get_http_port(default:80)
: checks to see if a Web server is running on port 80.
if (get_port_state(port)): an opening 'if' clause, this states that the commands contained within the curly braces should only be run if the port is open.
if (is_cgi_installed_ka(item:"/killerapp.asp",port:port)): the 'is_cgi_installed_ka' function checks to see whether a particular item exists on a Web server. In this case, we're checking to see if the killerapp.asp file exists under the server's root.
security_hole(port): states that if the file does exist, a security hole will be reported back.
Using a custom script
There are two ways to execute a custom script: running the nasl.exe standalone tool from the command line, or including it in Nessus scans.
The syntax for running it at the command line is:
<![CDATA[nasl.exe -t <IP><script>]]>
For example, if you wanted to run the killerapp.nasl script against a Web server located at 192.168.1.1, you would execute:
nasl.exe -t 192.168.1.1 "C:\Program Files\Tenable\Nessus\plugins\killerapp.nasl"
If the script returns a hole, it outputs a status of "Success," as shown below:
[Wed Jun 11 19:08:58 2008][5832] Only Ethernet is supported for now (type of {07
061642-1076-44D2-9D72-6C7BC3022BCF} = 71)
C:\Program Files\Tenable\Nessus\plugins\killerapp.nasl: Success
Alternatively, the NASL check can be included in a standard Nessus scan by simply including the file in your Nessus folder's 'plug-ins' directory. You'll then find it among the checks available to you when configuring a Nessus scan.
Learning more about NASL
NASL is a fairly simple scripting language, but it does contain a number of built-in functions to help customize your own scripts. For the definitive reference on NASL, view the NASL Reference Guide on the main Nessus site.
NESSUS TUTORIAL
Introduction: What is Nessus?
How to install and configure Nessus
How to run a system scan
Using Nessus Attack Scripting Language (NASL)
Vulnerability scanning in the enterprise
How to simplify security scans
How to use Nessus with the SANS Top 20
About the author:
Mike Chapple, CISA, CISSP, is an IT security professional with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force. Mike is a frequent contributor to SearchSecurity, a technical editor for Information Security magazine and the author of several information security titles, including the CISSP Prep Guide and Information Security Illuminated. He also answers your questions on network security.
