Network Security Tools | O'Reilly Media

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Software vulnerabilities are being discovered and announced more quickly than ever before. Every time a security advisory goes public, organizations that use the affected software must rush to install vendor-issued patches before their networks are compromised. The ease of finding exploits on the Internet today has enabled a casual user with few skills to launch attacks and compromise the networks of major corporations. It is therefore vital for anyone with hosts connected to the Internet to perform routine audits to detect unpatched remote vulnerabilities. Network security assessment tools such as Nessus can automatically detect such vulnerabilities.

Nessus is a free and open source vulnerability scanner distributed under the GNU General Public License (GPL). The Nessus Attack Scripting Language (NASL) has been specifically designed to make it easy for people to write their own vulnerability checks. An organization might want to quickly scan for a vulnerability that is known to exist in a custom or third-party application, and that organization can use NASL to do exactly that. Provided you have had some exposure to programming, this chapter will teach you NASL from scratch and show you how to write your own plug-ins for Nessus.

Nessus is based upon a client-server model. The Nessus server, nessusd, is responsible for performing the actual vulnerability tests. The Nessus server listens for incoming connections from Nessus clients that end users use to configure and launch specific scans. Nessus clients must authenticate to the server before they are allowed to launch scans. This architecture makes it easy to administer the Nessus installations.

You can and should use NASL to write Nessus plug-ins. Another alternative is to use the C programming language, but this is strongly discouraged. C plug-ins are not as portable as NASL plug-ins, and you must recompile them for different architectures. NASL was designed to make life easier for those who want to write Nessus plug-ins, so you should use it to do so whenever possible.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Nessus is based upon a client-server model. The Nessus server, nessusd, is responsible for performing the actual vulnerability tests. The Nessus server listens for incoming connections from Nessus clients that end users use to configure and launch specific scans. Nessus clients must authenticate to the server before they are allowed to launch scans. This architecture makes it easy to administer the Nessus installations.

You can and should use NASL to write Nessus plug-ins. Another alternative is to use the C programming language, but this is strongly discouraged. C plug-ins are not as portable as NASL plug-ins, and you must recompile them for different architectures. NASL was designed to make life easier for those who want to write Nessus plug-ins, so you should use it to do so whenever possible.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You can install the Nessus server on Unix- and Linux-compatible systems. The easiest way to install Nessus is to run the following command:

[notroot]$ lynx -source http://install.nessus.org | sh

This command downloads the file served by http://install.nessus.org/ and runs it using the sh interpreter. If you want to see the contents of the file that is executed, simply point your web browser to http://install.nessus.org/.

If you don't want to run a shell script from a web site, issue the build commands yourself. Nessus source code is available at http://nessus.org/download/. First, install nessus-libraries:

[notroot]$ tar zxvf nessus-libraries-x.y.z.tar.gz
[notroot]$ cd nessus-libraries
[notroot]$ ./configure
[notroot] make
[root]# make install

Next, install libnasl:

[notroot]$ tar zxvf libnasl-x.y.z.tar.gz
[notroot]$ cd libnasl
[notroot]$ ./configure
[notroot]$ make
[root]# make install
[root]# ldconfig

Then, install nessus-core:

[notroot]$ tar zxvf nessus-core.x.y.z.tar.gz 
[notroot]$ cd nessus-core [notroot]$ ./configure
[notroot]$ make 
[root]# make install

If you are installing nessus-core on a server that does not have the GTK libraries and you don't need the Nessus GUI client, run ./configure with the --disable-gtk option.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

First, start the Nessus server:

[root]# nessusd &

Before you can connect to the server, you need to add a Nessus user . Do this by executing the nessus-adduser executable. Note that Nessus is responsible for authenticating and authoring its users, so a Nessus user has no connection with a Unix or Linux user account. Next, run the nessus executable from the host on which you installed Nessus or on a remote host that will connect to the Nessus server.

Make sure you select the "Nessusd host" tab, as shown in Figure 1-1. Input the IP address or hostname of the host where the Nessus server is running, along with the login information as applicable to the Nessus user you created. Click the "Log in" button to connect to the Nessus server.

Figure 1-1: Logging in to the Nessus server using the GUI client

Next, select the Plugins tab to look at the different options available. For example, select "CGI abuses" from the "Plugin selection" list, and you should see a list of plug-ins available to you, as shown in Figure 1-2.

Figure 1-2: Selecting Nessus plug-ins

The "Enable all but dangerous plugins" button disables plug-ins known to crash remote services. Also take a look at the scans listed under the Denial of Service family. Because these plug-ins perform tests that can cause remote hosts or services to crash, it is a good idea to uncheck these boxes when scanning hosts that provide critical services.

Use the Filter... button to search for specific plug-ins. For example, you can search for vulnerability checks that have a certain word in their description, or you can search by the Common Vulnerabilities and Exposures (CVE) name of a specific vulnerability. The CVE database is available at

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Use the NASL interpreter, nasl, to run and test NASL scripts via the command line. Invoke it with the -v flag to see what version is installed on your system:

[notroot]$ nasl -v
nasl 2.0.10

Copyright (C) 1999 - 2003 Renaud Deraison <deraison@cvs.nessus.org>
Copyright (C) 2002 - 2003 Michel Arboi <arboi@noos.fr>

See the license for details

A vanilla Nessus installation comes packaged with NASL scripts that act as plug-ins for the Nessus scanner. The Nessus server executes these scripts to test for vulnerabilities, and you can find the scripts in the /usr/local/lib/ness/plugins/ directory. You can execute these scripts directly by invoking them with nasl. For example, the finger.nasl script checks to see if fingerd is enabled on a remote host. Finger is a service that listens on port 79 by default, and you can use it to query information about users. To run this script against a host with the IP address of 192.168.1.1 using the NASL interpreter, execute the following:

 [notroot]$ nasl -t 192.168.1.1 finger.nasl
** WARNING : packet forgery will not work
** as NASL is not running as root

The 'finger' service provides useful information to attackers, since it allows 
them to gain usernames, check if a machine is being used, and so on... 
Here is the output we obtained for 'root' : 

Login: root                             Name: System Administrator
Directory: /var/root                    Shell: /bin/sh
On since Wed  5 May 08:51 (CDT) on ttyp2 from 127.0.0.1:0.0
No Mail.
No Plan.

Solution : comment out the 'finger' line in /etc/inetd.conf
Risk factor : Low
[6533] plug_set_key:send(0)['1 finger/active=1;
'](0 out of 19): Socket operation on non-socket

The preceding output is from the finger.nasl script, which was able to use the finger server running on host 192.168.1.1 to find out information about the root user.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

What programming tutorial would be complete without a Hello World example? The following NASL script is just that:

display("Hello World\n");

Run the preceding line with the nasl interpreter, and you will see the text Hello World displayed.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

NASL allows for the assignment of values to variables that can be manipulated by a NASL script. Unlike a strongly typed language such as C, NASL does not require you to predefine a variable's type. In NASL, the variable type is determined automatically when a variable is assigned a specific value. NASL recognizes two valid datatypes: scalars and arrays. A scalar can be a number or a string, while an array is a collection of scalars.

NASL allows variables to hold integer values—for example, the number 11. It is also possible to assign numeric values to variables using a hexadecimal representation. You write hexadecimal numbers in NASL using a leading "0x" prefix. For example, the hexadecimal number 0x1b holds the value 27 when represented as an integer in base-10 notation. Type the following script into a file:

h=0x1b;
display ("The value of h is ",h,"\n");

Now run it using the NASL interpreter to see the output:

[notroot]$ nasl hex.nasl
The value of h is 27

It is also possible to input numerical values in octal notation form, which uses base- 8 notation by placing a leading "0" prefix. For example, the x and y are equivalent in the following example:

x=014; #octal
y=12; #decimal

A string is a collection of characters. abcdefg, Hello World, and Boeing 747 are all examples of strings. Consider the following NASL script:

mystring="Hello. I am a string!\n";
display(mystring);

The \n at the end of mystring is an escape character and is equivalent to a newline character. Table 1-1 lists common escape characters applicable to NASL.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

NASL provides arithmetic, comparison, and assignment operators. These operators are explained in the following sections.

Here are the common arithmetic operators:

+: Used to add numbers. It can also be used to perform string concatenation.
-: Used to perform subtraction. It can also be used to perform string subtraction. For example, 'cat, dog, mouse' - ', dog' results in the string 'cat, mouse'.
*: Used to multiply numbers.
/: Used to divide numbers. Note that NASL will return a 0 if you try to divide by zero.
%: Used to perform a modulo operation. For example, 10%3 computes to 1.
**: Used to perform exponentiation. For example,

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You can use the if...else statement to execute a block of statements depending on a condition. For example, suppose we want the value of variable port_open to be 1 if the value of the variable success is positive. Otherwise, we want the value of port_open to be -1. Our if...else statement would be as follows:

if (success>0)
{
    port_open=1;
}
else
{
    port_open=-1;
}

Because we have only one statement within the if and else blocks, the braces { and } are optional, so our statement would have also worked if we had not enclosed our assignment statements within the braces.

It is also possible to nest if...else statements. For example, suppose we want to assign the value -2 to port_open if success equals -10, or the value 0 to port_open if success is less than 1. Otherwise, we want to assign the value 1 to port_open. In this case, our if..else statement would be as follows:

if (success==-10)
{
    port_open=-2;
}
else if (success<1)
{
    port_open=0;
}
else
{
    port_open=1;
}

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Loops are used to iterate through a particular set of statements based upon a set of conditions. The following sections discuss the different types of loop statements supported by NASL.

A for loop expects three statements separated by semicolons as arguments. The first statement is executed first, and only once. It is most frequently used to assign a value to a variable, which is usually used by the loop to perform iteration. The second statement is a condition that should return true for the loop to continue looping. The third statement is invoked by the for loop after every iteration, and is used to increment or decrement the iteration variable. For example, the following for loop prints all the values of the array myports:

for(i=0; i < max_index(myports); i++)
{
    display(myports[i],"\n");
}

The function max_index() returns the number of elements in an array, and we use it in our for loop to ensure that the value of i is within range.

You can use the foreach statement to loop for every array element. This is useful in cases when you need to iterate through an array. For example, the following loop iterates through myports[] and prints the values contained in it:

foreach i (myports)
{
    display (i, "\n");
}

The condition specified after until is evaluated after the loop is executed. This means a repeat...until loop always executes at least once. For example, the following displays the string Looping!:

i=0;

repeat
{
    display ("Looping!\n");

} until (i == 0);

A while loop expects one conditional statement and loops as long as the condition is true. For example, consider the following while loop, which prints integers 1 to 10:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A function is a block of code that performs a particular computation. Functions can be passed input parameters and return a single value. Functions can use arrays to return multiple values.

The following function expects the integer value port as input. The function returns 1 if port is even, 0 if it is odd:

function is_even (port)
{
    return (!(port%2));
}

The function is_even( ) performs the modulo operation to obtain the remainder when port is divided by 2. If the modulo operation returns 0, the value of port must be even. If the modulo operation returns 1, the value of port must be odd. The ! operator is used to invert the evaluation, and this causes the function to return 1 when the modulo operation evaluates to 0, and 0 when the modulo operation evaluates to 1.

Functions in NASL do not care about the order of parameters. To pass a parameter to a function, precede it with the parameter name—for example, is_even(port:22). Here is an example of how you can invoke is_even( ):

for(i=1;i<=5;i++)
{
    display (i," is ");

    if(is_even(port:i))
        display ("even!");
    else
        display ("odd!");

    display ("\n");
}

When executed, the preceding program displays the following:

1 is odd!
2 is even!
3 is odd!
4 is even!
5 is odd!

The NASL library consists of some functions that are not global. Such functions are defined in .inc files and you can include them by invoking the include() function call. For example:

include("http_func.inc");
include("http_keepalive.inc");

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This section lists global variables that are predefined and are commonly used when writing NASL plug-ins.

Note that NASL does not forbid you from changing the value of these variables, so be careful not to do so accidentally. For example, TRUE should always evaluate to a nonzero value, while FALSE should always evaluate to 0.

The variable TRUE evaluates to 1. The variable FALSE evaluates to 0.

This variable signifies an undefined value. If an integer variable is tested (example: i == NULL) with NULL, first it will be compared with 0. If a string variable is tested (example: str == NULL) with NULL, it will be compared with the empty string "".

Every NASL plug-in needs to specify a single category it belongs to by invoking script_category(). For example, a plug-in whose main purpose is to test a denial-of-service vulnerability should invoke script_category( ) as follows:

script_category(ACT_DENIAL);

You can invoke the

script_category(
)

function with any of the following categories as the parameter:

ACT_ATTACK: This category is used by plug-ins to specify that their purpose is to launch a vulnerability scan on a target host.
ACT_DENIAL: This category is reserved for plug-ins which perform denial-of-service vulnerability checks against services running on remote hosts.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This section presents the most basic string, plug-in maintenance, and reporting functions available in NASL. For an exhaustive list of all function calls available in the NASL library, read the NASL2 Reference Manual available at http://nessus.org/documentation/.

NASL provides a rich library for string manipulation. When scanning for vulnerabilities, outgoing requests and incoming responses contain data presented to NASL plug-ins as strings, so it is important to learn how to best utilize the available string API. This section discusses NASL-provided functions for pattern matching, simple string manipulation and conversion, and other miscellaneous string-related functions.

Section 1.12.1.1: Simple string manipulation functions

The chomp() function takes in a string as a parameter and strips away any carriage returns, line feeds, tabs, or whitespace at the end of the string. For example:

mystring='abcd \t\r\n';
display ('BEGIN',chomp(mystring),'END\n');

displays BEGINabcdEND on one line.

The crap( ) function is used to fill a buffer with repeated occurrences of a specified string. The function takes in two parameters, length and data. The length parameter specifies the length of the string to be returned, while the data parameter specifies the string that should be used to fill the buffer. For example, crap(length:10,data:'a') returns aaaaaaaaaa. If data is not specified, a default value of X is used.

To perform string concatenation, you can use the strcat( ) function. This function also converts given variables to strings when performing concatenation. The following example causes the value of mystring to be set to abcdefgh123:

string1="abcd";
string2="efgh";
number1=123;
mystring=strcat(string1,string2,number1);

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Now that you understand NASL specifics, this section will help you understand how some of the important NASL plug-ins work. Once you understand how some of the existing plug-ins work, you will be able to refer to them when you need to write your own. The Section 1.13.5 later in this chapter quickly recaps all steps necessary to write and install your own plug-in from scratch.

Administrators sometimes forget to harden services that allow remote access. Some of these services come with default usernames and passwords. A Nessus plug-in can detect such vulnerabilities by attempting to log on to the remote service with a default username or password. For example, the ftp_anonymous.nasl plug-in connects to an FTP server to check if anonymous access is allowed:

#
# This script was written by Renaud Deraison <deraison@cvs.nessus.org>
#
#
# See the Nessus Scripts License for details
#

if(description)
{
 script_id(10079);
 script_version ("$Revision: 1.2 $");
 script_cve_id("CAN-1999-0497");
 script_name(english:"Anonymous FTP enabled");

 script_description(english:"
This FTP service allows anonymous logins. If you do not want to share data
with anyone you do not know, then you should deactivate the anonymous account,
since it can only cause troubles.

Risk factor : Low");

 script_summary(english:"Checks if the remote ftp server accepts anonymous logins");

 script_category(ACT_GATHER_INFO);
 script_family(english:"FTP");
 script_copyright(english:"This script is Copyright (C) 1999 Renaud Deraison");
 script_dependencie("find_service.nes", "logins.nasl", "smtp_settings.nasl");
script_require_ports("Services/ftp", 21);
 exit(0);
}

#
# The script code starts here :
#

include("ftp_func.inc");

port = get_kb_item("Services/ftp");
if(!port)port = 21;

state = get_port_state(port);
if(!state)exit(0);
soc = open_sock_tcp(port);
if(soc)
{
 domain = get_kb_item("Settings/third_party_domain");
 r = ftp_log_in(socket:soc, user:"anonymous", pass:string("nessus@", domain));
 if(r)
 {
  port2 = ftp_get_pasv_port(socket:soc);
  if(port2)
  {
   soc2 = open_sock_tcp(port2, transport:get_port_transport(port));
   if (soc2)
   {
    send(socket:soc, data:'LIST /\r\n');
    listing = ftp_recv_listing(socket:soc2);
    close(soc2);
    }
  }

  data = "
This FTP service allows anonymous logins. If you do not want to share data
with anyone you do not know, then you should deactivate the anonymous account,
since it may only cause troubles.

";

  if(strlen(listing))
  {
   data += "The content of the remote FTP root is :

" + listing;
  }

 data += "

Risk factor : Low";

  security_warning(port:port, data:data);
  set_kb_item(name:"ftp/anonymous", value:TRUE);
  user_password = get_kb_item("ftp/password");
  if(!user_password)
  {
   set_kb_item(name:"ftp/login", value:"anonymous");
   set_kb_item(name:"ftp/password", value:string("nessus@", domain));
  }
 }
 close(soc);
}

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Ettercap is a network analyzer that is free and open source. Advanced features such as ARP poisoning, packet filtering, and OS fingerprinting, along with support for password dissectors and plug-ins make Ettercap a powerful tool and a favorite among many network administrators. Ettercap has been known to compile on various Unix and Linux flavors, and has been successfully ported to run on Microsoft Windows operating systems.

This chapter introduces the concept of writing dissectors and plug-ins for Ettercap. Dissectors allow you to grab important information, such as usernames and passwords, that are transmitted over a network. For the purposes of understanding how to write a dissector, we will step through a dissector that captures and displays FTP usernames and passwords. Then, to demonstrate how to write an Ettercap plug-in, we will step through a plug-in that alerts the user when one host on the network attempts to establish a new TCP connection with another host.

The latest Ettercap source code is available from http://ettercap.sourceforge.net/download.php. Grab the latest tarball and compile Ettercap:

[notroot]$ tar zxvf ettercap-NG-x.y.z.tar.gz
[notroot]$ cd ettercap-NG-x.y.z
[notroot]$ ./configure
[notroot]$ make
[root]# make install

Make sure you obtain and install an Ettercap version that is equal to or greater than 0.7.0. Ettercap APIs of versions older than 0.7.0 differ significantly, and are no longer supported.

You can run Ettercap in console mode, curses mode, or GTK mode, the latter of which is shown in Figure 2-1.

Figure 2-1: Ettercap in GTK mode

Run ettercap -h to discover the plethora of options and features Ettercap provides. See the ettercap manpage for more details on available options and features.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The latest Ettercap source code is available from http://ettercap.sourceforge.net/download.php. Grab the latest tarball and compile Ettercap:

[notroot]$ tar zxvf ettercap-NG-x.y.z.tar.gz
[notroot]$ cd ettercap-NG-x.y.z
[notroot]$ ./configure
[notroot]$ make
[root]# make install

Make sure you obtain and install an Ettercap version that is equal to or greater than 0.7.0. Ettercap APIs of versions older than 0.7.0 differ significantly, and are no longer supported.

You can run Ettercap in console mode, curses mode, or GTK mode, the latter of which is shown in Figure 2-1.

Figure 2-1: Ettercap in GTK mode

Run ettercap -h to discover the plethora of options and features Ettercap provides. See the ettercap manpage for more details on available options and features.

The Ettercap web site consists of a publicly available message board dedicated to providing support in case you experience problems. Access the message board by visiting http://ettercap.sourceforge.net/forum/.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A dissector captures protocol-specific information from the network. Most Ettercap dissectors are designed to capture usernames and passwords transmitted over the network in real time. Here is an example of how to run Ettercap in console mode to sniff passwords:

[root]# ettercap --text --quiet

ettercap NG-0.7.0 copyright 2001-2004 ALoR & NaGA

Listening on en0... (Ethernet)
   eth0 ->       00:0B:25:30:11:B      192.168.1.1     255.255.255.0

Privileges dropped to UID 65534 GID 65534...
   0 plugins
  39 protocol dissectors
  53 ports monitored
6312 mac vendor fingerprint
1633 tcp OS fingerprint
2183 known services

Starting Unified sniffing...


Text only Interface activated...
Hit 'h' for inline help

FTP : 10.0.0.1:21 -> USER: john  PASS: try4ndgu355m3!!

In the preceding example, the FTP dissector successfully sniffed the FTP password try4ndgu355m3!! of user john logged on to an FTP server running on host 10.0.0.1.

In the following paragraphs, we will discuss the dissector responsible for capturing FTP usernames and passwords. First we will discuss the FTP authentication mechanism, followed by a detailed analysis of the FTP dissector source code.

This section discusses how FTP performs authentication. We need to understand this before we step through FTP dissector source code for Ettercap.

FTP is a plain-text protocol, and it uses no encryption. FTP servers listen on TCP port 21 by default. To authenticate with an FTP server, the client establishes a connection to TCP port 21 and expects a banner that is preceded with 220:

220 Welcome to ftp.example.com

The banner string is irrelevant and can be changed by the FTP server administrator. By default, banner strings of some FTP servers provide the FTP server name and version number. With respect to the Ettercap dissector, we are concerned with only the 220 response code, which signifies that the FTP server is ready to serve further requests.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You can enable or disable Ettercap plug-ins on the fly, and therefore you can use them to extend Ettercap functionality on demand. Ettercap comes bundled with a variety of plug-ins that you can find in the plug-ins directory of the Ettercap source tree. The following sections show you how to write find_tcp_conn, a plug-in that detects the initiation of a new TCP connection on the network.

To establish a TCP connection with a remote host, the source host sends a TCP packet with the SYN flag set to the remote host. If the remote host is listening on a particular port, it responds with a TCP packet with the SYN and ACK flags set. The source host then sends a TCP packet with the ACK bit set to formally establish the TCP connection. This sequence is known as the three-way TCP handshake . Therefore, to detect new TCP connections with other hosts, our plug-in has to analyze the network traffic for TCP packets that have the SYN flag set. The find_tcp_conn plug-in described in the following paragraphs analyzes TCP packets for the SYN flag, and if one is found, it alerts the Ettercap user that a host on the network is attempting to establish a new TCP connection with another host.

The find_tcp_conn plug-in alerts the Ettercap user whenever a TCP packet with the SYN flag set is captured. Therefore, the plug-in alerts the Ettercap user even if the server host does not respond to the connection attempt. This plug-in can be useful for noticing when a SYN port-scan is being performed on a network.

The find_tcp_conn plug-in will not detect new TCP connections when the host running Ettercap is on a network switch because network switches attempt to segregate network traffic. Therefore, the find_tcp_conn plug-in will detect SYN packets from other hosts only when the host running Ettercap is on a network hub, or when Ettercap is instructed to perform ARP poisoning.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Many security tools do not support a plug-in architecture, making extending these tools somewhat challenging. However, if your security tool uses a modular architecture, or if it uses a configurable database for specifying its behavior, you can extend it more easily. In this chapter we demonstrate how to extend the popular open source security tool, Hydra, to support an additional protocol, as well as adding signatures to the service signature file for the popular port scanner, Nmap, to recognize additional services.

By extending existing tools to support additional protocols and services, you can test for security vulnerabilities in networks where nonstandard or proprietary protocols and services exist, without creating an entirely new tool from scratch.

Hydra is a popular tool written by Van Hauser (http://www.thc.org/) for testing networked services for weak username and password combinations. This technique, commonly known as brute-force testing, is valuable for ensuring that network services and systems are not vulnerable to password-guessing attacks due to weak username and password combinations.

Although Hydra supports a number of different protocols for testing, most likely you'll want to test services available on your network that Hydra doesn't support. In this section we will demonstrate how to add a module for testing Simple Mail Transport Protocol (SMTP) authentication. You could use this to determine if weak passwords exist in your email user base and close this potential exposure before a spammer takes advantage of it.

Hydra is freely available for noncommercial use and for commercial use with proper acknowledgment. You can download it from http://www.thc.org/thc-hydra/. The module described in this section is included in Hydra Version 4.2.

Hydra is a very popular tool primarily because of the wide variety of protocols it supports and because its parallel nature divides password-testing tasks among a user-definable number of tasks.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Hydra is a popular tool written by Van Hauser (http://www.thc.org/) for testing networked services for weak username and password combinations. This technique, commonly known as brute-force testing, is valuable for ensuring that network services and systems are not vulnerable to password-guessing attacks due to weak username and password combinations.

Although Hydra supports a number of different protocols for testing, most likely you'll want to test services available on your network that Hydra doesn't support. In this section we will demonstrate how to add a module for testing Simple Mail Transport Protocol (SMTP) authentication. You could use this to determine if weak passwords exist in your email user base and close this potential exposure before a spammer takes advantage of it.

Hydra is freely available for noncommercial use and for commercial use with proper acknowledgment. You can download it from http://www.thc.org/thc-hydra/. The module described in this section is included in Hydra Version 4.2.

Hydra is a very popular tool primarily because of the wide variety of protocols it supports and because its parallel nature divides password-testing tasks among a user-definable number of tasks.

As of Version 4.4, Hydra supports the following protocols:

telnet	ftp	http
https

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Recent versions of the popular port scanner Nmap can detect the type and version of services running on a network, as illustrated in Example 3-2.

Example 3-2. Example Nmap version scan

>nmap -sV 127.0.0.1  

Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2003-07-05 17:12 EDT
Interesting ports on localhost (127.0.0.1):
(The 1658 ports scanned but not shown below are in state: closed)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 3.8.1p1 (protocol 2.0)

Nmap run completed -- 1 IP address (1 host up) scanned in 1.104 seconds

This scan is implemented as a series of probes and responses in the file nmap-service-probes . This file defines the probes that will be sent to the service to elicit some response, as well as a series of regular expressions against which to match responses to determine which services are running and, where possible, their versions.

At a high level, the version-scanning methodology follows this process:

If the port is a TCP port, connect to it and listen. This is called the NULL probe. Many services will return a banner on connection. If a match is made, processing stops.
If no match is given, or if the protocol is UDP, probes defined in the nmap-service-probes file will be attempted if the protocol and the port ranges in the file match. If a response matching a probe is found, processing stops. If a soft match occurs (whereby a service is recognized, but not its type or version), follow-on probes will be limited to relevant ones.
If no match is found, each probe in the nmap-service-probes file will be tried, regardless of the ports on which the service usually runs. This will be limited where a soft match has already occurred.
If SSL was found, Nmap will connect using SSL (if available) to run the version-detection process again.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Nikto is one of a number of open source security tools available to consultants and administrators. Nikto is a web server scanner, but it also can be used as a CGI scanner. Its purpose is to conduct a series of tests against a web server and to report known vulnerabilities in the server and its applications. The Nikto program is Perl code written and maintained by Chris Sullo. Nikto is regarded as the best in its class, which has earned it the number 16 spot in Fyodor's annual "Top Security Tools" survey, and it is mentioned in numerous books and articles. This chapter will give you an overview of the tool and explain how to extend it by writing your own code in the form of plug-ins and plug-in database entries.

Nikto is available on its author's web site at http://www.cirt.net. Download the latest tar.gz file of the Nikto source code. After uncompressing it, execute perl nikto.pl from the command line to see the program's options. This chapter was written using Nikto 1.32 as a reference, but future versions should be very similar, as the core is stable.

To use Nikto you must have a Perl interpreter on your system. If you want to use Nikto's SSL scanning features you must install the SSL software and libraries. You can get these for Windows systems from http://www.activestate.com/. If you're running Nikto on a Unix-like system, you can get OpenSSL from http://www.openssl.org/ and the Net::SSLeay module from http://www.cpan.org/. At its foundation Nikto uses RFP's LibWhisker, which comes bundled with the tar.gz file; optionally you can place Nikto in the Perl library search path.

Nikto runs on a variety of operating systems, including Mac OS X, Solaris, Linux, Windows, and many others, as long as a Perl interpreter is installed on the system.

Using Nikto is fairly straightforward. The main required arguments are the target host and port against which the scan will be conducted. If no port is specified, port 80 (the default) is used. All command-line options except for

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Nikto is available on its author's web site at http://www.cirt.net. Download the latest tar.gz file of the Nikto source code. After uncompressing it, execute perl nikto.pl from the command line to see the program's options. This chapter was written using Nikto 1.32 as a reference, but future versions should be very similar, as the core is stable.

To use Nikto you must have a Perl interpreter on your system. If you want to use Nikto's SSL scanning features you must install the SSL software and libraries. You can get these for Windows systems from http://www.activestate.com/. If you're running Nikto on a Unix-like system, you can get OpenSSL from http://www.openssl.org/ and the Net::SSLeay module from http://www.cpan.org/. At its foundation Nikto uses RFP's LibWhisker, which comes bundled with the tar.gz file; optionally you can place Nikto in the Perl library search path.

Nikto runs on a variety of operating systems, including Mac OS X, Solaris, Linux, Windows, and many others, as long as a Perl interpreter is installed on the system.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Using Nikto is fairly straightforward. The main required arguments are the target host and port against which the scan will be conducted. If no port is specified, port 80 (the default) is used. All command-line options except for -debug, -update, -dbcheck, and -verbose are available by using the first letter as a short-form option. Execute the program with no arguments, and a description of all available options along with module-loading warning messages will be displayed. You'll see the warning messages if support modules such as SSL are not installed correctly.

Here are the options you have available to you:

Cgidirs: This allows you to manually set a single CGI directory from which to start all tests. It overrides any of the CGI directory entries made in config.txt. Additionally it accepts the values all or none. all forces the core plug-in to run checks against every CGI directory specified in config.txt. none runs all CGI checks against the webroot (/).
cookies: This prints out cookies if the web server attempts to set them.
evasion+: LibWhisker lets you apply up to nine different URI obfuscation techniques to each request, with the goal of bypassing intrusion detection systems (IDSes) that do strict signature matching and no URI normalization/conversion. After seeing the evasion options by running Nikto with no arguments, specify as many of these numeric options as you want and they will be applied. For example:

$perl ./nikto.pl -h www.example.com -e 3489

findonly

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This section traces the logic flow of the entire Nikto program, and discusses the routines available through nikto_core and LibWhisker. The Nikto program structure is modular. Most of Nikto's actual functionality lies within external plug-ins , which you can find in the plugins/ directory where the Nikto source code was uncompressed.

It is a good idea to browse the source of existing plug-ins to better understand how they work. Execute the following Linux command from the Nikto root directory to generate a tag file for the source tree:

find . -name "*.pl" -o -name "*.pm" -o -name "*.plugin" | xargs ctags 
--language-force=perl

At 200 lines of code the Nikto.pl file is relatively small. The following paragraphs briefly discuss what the program does on a macro level.

At the start of the program, you'll notice a series of global variables. To avoid namespace collisions, plug-in developers shouldn't use these variable names. Next, load_configs( ) parses the configuration file config.txt and initializes %CONFIG. Then the find_plugins( ) routine searches expected directories for the plug-in file, and sets appropriate values in %FILES. The nikto_core plug-in and LibWhisker are included with the require keyword, which makes all routines from LW.pm and nikto_core.plugin available to the rest of nikto.pl as well as to its plug-ins. The general_config() routine parses the command-line options and sets %CLI appropriately. Next, LibWhisker's http_init_request( ) initializes LibWhisker's %request with default values.

The

Table of Contents

Section 1.12.1.1: Simple string manipulation functions