nikto web scanner
TRANSCRIPT
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.