Nikto Web Scanner

Nikto Web Scanner is a Web server scanner that tests Web servers for dangerous files/CGIs, outdated server software and other problems. It

performs generic and server type specific checks. It also captures and prints any cookies received. Nikto is a web server assessment tool. It is

designed to find various default and insecure files, configurations and programs on any type of web server.

The Nikto code itself is Open Source (GPL), however the data files used to drive it are not

Functions

Nikto performs comprehensive tests against web servers for multiple items, including over 6100 potentially dangerous files/CGIs, versions on

over 950 servers, and version specific problems on over 260 servers.

Variations

There are some variations of Nikto, one of which is MacNikto. MacNikto is an AppleScript GUI shell script wrapper built in Apple's Xcode and

Interface Builder, released under the terms of the GPL. It provides easy access to a subset of the features available in the Open Source,

command-line driven Nikto web security scanner, installed along with the MacNikto application. [3] [4]

Description

Examine a web server to find potential problems and security vulnerabilities, including:

Server and software misconfigurations

Default files and programs

Insecure files and programs

Outdated servers and programs

Error detection logic:

Nikto is built on LibWhisker (by RFP) and can run on any platform which has a PERL environment. It supports SSL, proxies, host authentication,

IDS evasion and more. It can be updated automatically from the command-line, and supports the optional submission of updated version data

back to the maintainers.

Most web security tools, (including Nikto 1.32 and below), rely heavily on the HTTP response to determine if a page or script exists on the target.

Because many servers do not properly adhere to RFC standards and return a 200 "OK" response for requests which are not found or forbidden,

this can lead to many false-positives. In addition, error responses for various file extensions can differ--the "not found" response for a .html file is

often different than a .cgi.

A list of unique file extensions is generated at run-time (from the test database), and each of those extensions is tested against the target. For

every file type, the "best method" of determining errors is found: standard RFC response, content match or MD4 hash (in decreasing order of

preference). This allows Nikto to use the fastest and most accurate method for each individual file type, and therefore help eliminate the false

positives seen for some servers

For example, if a server responds with a 404 "not found" error for a non-existent .txt file, Nikto will match the HTTP response of "404" on tests. If

the server responds with a 200 "OK" response, it will try to match on the content, and assuming it finds a match (for example, the words "could

not be found"), it will use this method for determining missing .txt files. If the other methods fail, Nikto will attempt to remove date and time

strings (which can constantly change) from the returned page's content, generate an MD5 hash of the content, and then match that hash value

against future .txt tests. The latter is by far the slowest type of match, but in many cases will provide valid results for a particular file type.

Basic Testing

The most basic Nikto scan requires simply a host to target, since port 80 is assumed if none is specified. The host can either be an IP or a

hostname of a machine, and is specified using the -h (-host) option. This will scan the IP 192.168.0.1 on TCP port 80:

perl nikto.pl -h 192.168.0.1

To check on a different port, specify the port number with the -p (-port) option. This will scan the IP 192.168.0.1 on TCP port 443:

perl nikto.pl -h 192.168.0.1 -p 443

Hosts, ports and protocols may also be specified by using a full URL syntax, and it will be scanned:

perl nikto.pl -h https://192.168.0.1:443/

There is no need to specify that port 443 may be SSL, as Nikto will first test regular HTTP and if that fails, HTTPS. If you are sure it is an SSL server,

specifying -s (-ssl) will speed up the test.

perl nikto.pl -h 192.168.0.1 -p 443 -ssl

Note

-mutate 1 increases the number of tests so that all filenames are tested against all databases inc db_tests. This will produce over

2,000,000 extra tests, which will use up a massive amount of resource.

More complex tests can be performed using the -mutate parameter, as detailed later. This can produce extra tests, some of which may be

provided with extra parameters through the -mutate-options parameter. For example, using -mutate 3, with or without a file attempts to

brute force usernames if the web server allows ~user URIs:

perl nikto.pl -h 192.168.0.1 -mutate 3 -mutate-options user-list.txt

Multiple Port Testing

Nikto can scan multiple ports in the same scanning session. To test more than one port on the same host, specify the list of ports in the -p (-port)

option. Ports can be specified as a range (i.e., 80-90), or as a comma-delimited list, (i.e., 80,88,90). This will scan the host on ports 80, 88 and

443.

perl nikto.pl -h 192.168.0.1 -p 80,88,443

Multiple Host Testing

Nikto support scanning multiple hosts in the same session via a text file of host names or IPs. Instead of giving a host name or IP for the -h (-host)

option, a file name can be given. A file of hosts must be formatted as one host per line, with the port number(s) at the end of each line. Ports can

be separated from the host and other ports via a colon or a comma. If no port is specified, port 80 is assumed.

Using a Proxy

If the machine running Nikto only has access to the target host (or update server) via an HTTP proxy, the test can still be performed. Set the

PROXY* variables (as described in section 4), then execute Nikto with the -u (-useproxy) command. All connections will be relayed through the

HTTP proxy specified in the configuration file.

perl nikto.pl -h 192.168.0.1 -p 80 -u

Mutation Techniques

A mutation will cause Nikto to combine tests or attempt to guess values. These techniques may cause a tremendous amount of tests to be

launched against the target. Use the reference number to specify the type, multiple may be combined.

Test all files with all root directories. This takes each test and splits it into a list of files and directories. A scan list is then created by combining

each file with each directory.

Guess for password file names. Takes a list of common password file names (such as "passwd", "pass", "password") and file extensions ("txt",

"pwd", "bak", etc.) and builds a list of files to check for.

Enumerate user names via Apache (/~user type requests). Exploit a misconfiguration with Apache UserDir setups which allows valid user names

to be discovered. This will attempt to brute-force guess user names. A file of known users can also be supplied by supplying the file name in the

-mutate-options parameter.

Enumerate user names via cgiwrap (/cgi-bin/cgiwrap/~user type requests). Exploit a flaw in cgiwrap which allows valid user names to be

discovered. This will attempt to brute-force guess user names. A file of known users can also be supplied by supplying the file name in the -

mutate-options parameter.

Attempt to brute force sub-domain names. This will attempt to brute force know domain names, it will assume the given host (without a www)

is the parent domain.

Attempt to brute directory names. This is the only mutate option that requires a file to be passed in the -mutate-options parameter. It will

use the given file to attempt to guess directory names. Lists of common directories may be found in the OWASP DirBuster project

Scan Tuning

Scan tuning can be used to decrease the number of tests performed against a target. By specifying the type of test to include or exclude, faster,

focused testing can be completed. This is useful in situations where the presence of certain file types are undesired -- such as XSS or simply

"interesting" files.

Test types can be controlled at an individual level by specifying their identifier to the -T (-Tuning) option. In the default mode, if -T is invoked

only the test type(s) specified will be executed. For example, only the tests for "Remote file retrieval" and "Command execution" can performed

against the target:

perl nikto.pl -h 192.168.0.1 -T 58

If an "x" is passed to -T then this will negate all tests of types following the x. This is useful where a test may check several different types of

exploit. For example:

perl nikto.pl -h 192.168.0.1 -T 58xb

The valid tuning options are:

0 - File Upload. Exploits which allow a file to be uploaded to the target server.

1 - Interesting File / Seen in logs. An unknown but suspicious file or attack that has been seen in web server logs (note: if you have information

regarding any of these attacks, please contact CIRT, Inc.).

2 - Misconfiguration / Default File. Default files or files which have been misconfigured in some manner. This could be documentation, or a

resource which should be password protected.

3 - Information Disclosure. A resource which reveals information about the target. This could be a file system path or account name.

4 - Injection (XSS/Script/HTML). Any manner of injection, including cross site scripting (XSS) or content (HTML). This does not include command

injection.

5 - Remote File Retrieval - Inside Web Root. Resource allows remote users to retrieve unauthorized files from within the web server's root

directory.

6 - Denial of Service. Resource allows a denial of service against the target application, web server or host (note: no intentional DoS attacks are

attempted).

7 - Remote File Retrieval - Server Wide. Resource allows remote users to retrieve unauthorized files from anywhere on the target.

8 - Command Execution / Remote Shell. Resource allows the user to execute a system command or spawn a remote shell.

9 - SQL Injection. Any type of attack which allows SQL to be executed against a database.

a - Authentication Bypass. Allows client to access a resource it should not be allowed to access.

b - Software Identification. Installed software or program could be positively identified.

c - Remote source inclusion. Software allows remote inclusion of source code.

x - Reverse Tuning Options. Perform exclusion of the specified tuning type instead of inclusion of the specified tuning type.

Scan Database Field Values

Though some checks can be found in other plugins, the scan_database.db contains the bulk of the web test information. Here is a description

of the field values:

Table 7.1. Scan Database Fields

Test ID Nikto test ID

OSVDB-ID Corresponding vulnerability entry number for osvdb.org

Server Type Generic server matching type

URI URI to retrieve

HTTP Method HTTP method to use for URI

Match 1 String or code to match for successful test

Match 1 (Or) String or code to alternatively match for successful test

Match1 (And) String or code to also match for successful test

Fail 1 String or code to match for test failure

Fail 2 String or code to match for test failure (alternative)

Summary Summary message to report for successful test

HTTP Data HTTP data to be sent during POST tests

Headers Additional headers to send during test

Data Structures

The below data structures are used to communicate between the various plugin methods. Unless otherwise mentioned, they are all standard perl hash references with the detailed members.

Mark

The mark hash contains all information about a target. It contains the below members. It should be read-only.Table 7.2. Members of the Mark structure

ident Host identifier, usually equivalent to what was passed on the command line.

hostname Host name of the target.

ip IP address of the target.

port TCP port of the target.

display_name Either the hostname, or the IP address of the target, dependant on whether a hostname has been discovered.

sslFlag to indicate whether the target runs over SSL. If it is set to 0, then the plugin should not use SSL. Any other value indicates

SSL should be used.

vhost Virtual hostname to use for the target.

root Root URI to use for the target.

banner Banner of the target's web server.

Vulnerability

The vulnerability hash contains all information about a vulnerability. It contains the below members. It should be read-only and should only be written using the add_vulnerability method.

Table 7.3. Members of the Vulnerability structure

mark Hash ref to a mark data structure.

message Message for the vulnerability.

nikto_id Test ID (tid) of the vulnerability, this should be a unique number which'll identify the vulnerability.

osvdbOSVDB reference to the vulnerability in the Open Source Vulnerability Database. This may be 0 if an OSVDB reference is not relevant or

doesn't exist.

method HTTP method used to find the vulnerability.

uri URI for the result.

result Any HTTP data, excluding headers.

Standard Methods

Several standard methods are defined in nikto_core.plugin that can be used for all plugins. It is strongly advised that these should be used where possible instead of writing new methods.For some methods, such as add_vulnerability which write to global variables, these must be the only interface to those global variables.

array change_variables(line);

string line;

Expands any variables in the line parameter. The expansions are variables defined in the global array @VARIABLES, which may be read from db_variables, or added by reconnaisance plugin methods.int is_404(uri,

content,

HTTPcode);

string uri;

string content;

string HTTPcode;

Makes a guess whether the result is a real web page or an error page. As several web servers are badly configured and don't return HTTP 404 codes when a page isn't found, Nikto attempts to look for common error pages. Returns 1 if the page looks like an error.string get_ext(uri);

string uri;

Attempts to work out the extension of the uri. Will return the extension or the special cases: DIRECTORY, DOTFILE, NONE.string date_disp();

;

Returns the current time in a human readable format (YYYY-mm-dd hh:mm:ss)string rm_active(content);

string content;

Attempts to remove active content (e.g. dates, adverts etc.) from a page. Returns a filtered version of the content.string get_banner(mark);

hashref mark;

Pulls the web servers banner. This is automatically performed for all targets before a mark is passed to the plugin.boolean content_present(HTTPcode);

string HTTPcode;

Checks the HTTPresponse against known "found" responses. TRUE indicates that the request was probably successful.string HTTPCode, string content fetch(uri,

method,

content,

headers,

noclean);

string uri;

string method;

string content;

hashref headers;

boolean noclean;

DeprecatedPerforms a simple HTTP request to URI using the HTTP method, method. content supplies any data to pass in the HTTP body. headers allows any custom headers to be placed in the request. noclean is a flag specifying that the request shouldn't be cleaned up before being sent (e.g. if the Host: header is blank).string HTTPCode, string content nfetch(uri,

method,

content,

headers,

noclean);

string uri;

string method;

string content;

hashref headers;

boolean noclean;

An updated version of fetch that uses a local, rather than a global request/result structure. This should be used in preference to fetch.

hashref setup_hash(requesthas

h,

mark);

hashref requesthash;

hashref mark;

Sets up up a libwhisker hash with the normal Nikto variables. This should be used if any custom calls to libwhisker are used.string char_escape(line);

string line;

Escapes any characters within line.array parse_csv(text);

string text;

Breaks a line of CSV text into an array of items.

arrayref init_db(dbnam

e);

string dbname;

Initialises a database that is in PLUGINDIR and returns an arrayref. The arrayref is to an array of hashrefs, each hash member is configured by the first line in the database file, for example:"nikto_id","md5hash","description"

This will result in an array of hashrefs with parameters:array[0]->{nikto_id}array[0]->{md5hash}array[0]->{description}void add_vulnerability(mark,

message,

nikto_id,

osvdb,

method,

uri,

data);

hashref mark;

string message;

string nikto_id;

string osvdb;

string method;

string uri;

string data;

Adds a vulnerability for the mark, displays it to standard out and sends it to any reporting plugins.void nprint(messag

e,

display);

string message;

string display;

Prints message to standard out. Display specifies a filter for the message, currently this can be "v" for verbose and "d" for debug output.