Tip

Using Nessus Attack Scripting Language (NASL) to find application vulnerabilities

    Requires Free Membership to View

    Login

Want more Nessus tips?

For more information, check out the rest of our Nessus 3 Tutorial.
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:

  • script_id(50000): 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:

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.


This was first published in July 2008

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.

    Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.

    Back to top