Nikto v2 / The Manual

]> Nikto v2 / The Manual Introduction Overview 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. Description Nikto is PERL software designed to find many types of web server problems, including: Server and software misconfigurations Default files and programs Insecure files and programs Outdated servers and programs Nikto is built on LibWhisker and can run any platform which has a PERL runtime, and 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. The name "Nikto" is taken from the movie "The Day the Earth Stood Still", and of course subsequent abuse by Bruce Campbell in "Army of Darkness". More information on the pop-culture popularity of Nikto can be found at http://www.blather.net/blather/2005/10/klaatu_barada_nikto_the_day_th.html Advanced Error Detection Logic 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. Some testing tools, such as Nessus, also look at the content of the response to help eliminate these false positives. While often effective, this method relies on pre-defined strings to help eliminate false positives. As of version 2.0 Nikto no longer assumes the error pages for different file types will be the same. 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 in version 1.32 and below. 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. History The Nikto 1.00 Beta was released on December 27, 2001, (followed almost immediately by the 1.01 release). Over the course of two years Nikto's code evolved into the most popular freely available web vulnerability scanner. The 2.0 release, in November, 2007 represents several years of improvements. Installation Requirements Any system which supports a basic PERL installation should allow Nikto to run. It has been extensively tested on: Windows (using ActiveState Perl) Mac OSX Various Linux and Unix installations (including RedHat, Solaris, Debian, Knoppix, etc.) The only required PERL module that does not come standard is LibWhisker. Nikto comes with and is configured to use a local LW.pm file (in the plugins directory), but users may wish to change Nikto to use a version installed on the system. See Section 2 for further information. For SSL support the Net::SSLeay PERL module must be installed (which in turn requires OpenSSL on the Unix platform). Windows support for SSL is dependent on the installation package, but is rumored to exist for ActiveState's Perl. The nmap scanner can also be used, if desired. In some cases using nmap will slow down Nikto execution, as it must call an external program. For scanning many ports across one or more servers, using nmap will be faster than using Nikto's internal PERL scanning. PERL: http://www.cpan.org/ LibWhisker: http://www.wiretrip.net/ ActiveState Perl: http://www.activestate.com/ OpenSSL: http://www.openssl.org/ nmap: http://insecure.org/ Install These instructions do not include information on installing PERL, PERL Modules, OpenSSL, LibWhisker or any of the utilities that may be needed during installation (such as gzip, tar, etc.). Please see the distributor's documentation for information on how to install and configure those software packages. Unpack the download file:

tar -xvf nikto-current.tar.gz gzip -d nikto-current.tar

Assuming a standard OS/PERL installation, Nikto should now be usable. See Chapter 4 (Options) or Chapter 8 (Troubleshooting) for further configuration information. Usage 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

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. This is an example of a valid hosts file:

192.168.0.1:80 192.168.0.2,80 192.168.0.3 192.168.0.1,80,443 192.168.0.1:80:443 localhost:8888

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

Updating Nikto can be automatically updated, assuming you have Internet connectivity from the host Nikto is installed on. To update to the latest plugins and databases, simply run Nikto with the -update command.

perl nikto.pl -update

The -update option cannot be abbreviated. If updates are required, you will see a list of the files downloaded:

perl nikto.pl -update + Retrieving 'nikto_core.plugin' + Retrieving 'CHANGES.txt'

Updates may also be manually downloaded from http://www.cirt.net/ Integration with Nessus Nessus (http://www.nessus.org/nessus/) can be configured to automatically launch Nikto when it finds a web server. Ensure Nikto works properly, then place the directory containing nikto.pl in root's PATH environment variable. When nessusd starts, it should see the nikto.pl program and enable usage through the GUI. All Options Below are all of the Nikto command line options and explanations. A brief version of this text is available by running Nikto with the -h (-help) option. &options; Detailed Options 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. 1 - 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. 2 - 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. 3 - 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. 4 - 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. Display The Display option 1 - Show redirects. This will display all requests which elicit a "redirect" response from the server. 2 - Show cookies received. This will display all cookies that were sent by the remote host. 3 - Show all 200/OK responses. This will show all responses which elicit an "okay" (200) response from the server. This could be useful for debugging. 4 - Show URLs which require authentication. This will show all responses which elicit an "authorization required" header. D - Debug Output. Show debug output, which shows the verbose output and extra information such as variable content. V - Verbose Output. Show verbose output, which typically shows where Nikto is during program execution. 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, the include or exclude logic is reversed such that all tests except those specified will be performed. In this example, all tests except "Remote file retrieval" and "Command execution" are performed against the target:

perl nikto.pl -h 192.168.0.1 -T 58x

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 intention 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. Single Request Mode Single request mode is designed to preform a solitary request against the target. This is useful to confirm a test result using the same resources Nikto used during a scan. The single option allows manual setting of most variables used by Nikto and LibWhisker, and upon completion will display both the request and the result of the operation. Most options have a default value or can be left blank. The most common and required values are at the beginning of the "questions" section for slightly easier use. True and false are specified by numeric equivalents, 1 and 0 respectively. Please note that Single mode is not very user-friendly. Here is an example Nikto run with the -Single option. Output and Reports Export Formats Nikto saved output comes in three flavors: text, CSV or HTML. When using -o (output), an output format may be specified with -F (Format). Text format is assumed if nothing is specified with -F. The DTD for the Nikto XML format can be found in the 'docs' directory (nikto.dtd). HTML Customization HTML reports are generated from template files located in the "templates" directory. Variables are defined as #variable-name, and are replaced when the report is generated. The files "htm_start.tmpl" and "htm_end.tmpl" are included at the beginning and end of the report (respectively). The "htm_summary.tmpl" also appears at the beginning of the report. The "htm_host_head" appears once for every host, and the "htm_host_item.tmpl" and "htm_host_im.tmpl" appear once for each item found on a host and each "informational message" per host (respectively). All valid variables are used in these templates. Future versions of this documentation will include a list of variables and their meaning. The copyright statements must not be removed from the "htm_end.tmpl" without placing them in another of the templates. It is a violation of the Nikto license to remove these notices. Test & Code Writing 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: 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 Match1 (And) String or code to also match for successful test Match 1 (Or) String or code to alternatively 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 User-Defined Tests Users can create their own, private tests for any of the databases. By placing a syntactically correct database file in the "plugins" directory, with a file name prefaced with a "u", the data will be loaded along with the built-in checks. For example, create the file "plugins/udb_outdated" and it will be loaded at the same time "plugins/db_outdated" is loaded. These files will also be checked for syntax when -dbcheck is used. For tests which require a "private" OSVDB ID, use the OSVDB ID 0 (zero). This should be used for all vulnerabilities that do not (or should not) exist in OSVDB, as ID 0 is for testing only. You are encouraged to send missing information to OSVDB at moderators@osvdb.org. For the "Test ID", it is recommended you use unique numbers between 400000 and 499999 to allow for growth of the Nikto database without interfering with your own tests (note: numbers above 500000 are reserved for other tests). Please help Nikto's continued success by sending test updates to sullo@cirt.net. Scan Database Syntax The scan database is a CSV delimited file which contains most of the tests. Fields are enclosed by quotes and separated by commas. The field order is: Test-ID, OSVDB-ID, Tuning Type, URI, HTTP Method, Match 1, Match 1 And, Match1 Or, Fail 1, Fail 2, Summary, HTTP Data, Headers Here is an example test: "120","3092","2","/manual/","GET","200","","","","","Web server manual","","" Plugins Plugins are standard PERL which follow a standard Nikto naming format. All plugins must be named in the pattern nikto_name.plugin, where "name" is the name of the plugin. The file must have a subroutine named the same as the file name without the ".plugin" extension. For example, a plugin named nikto_mycode.plugin would need a subroutine called "sub nikto_mycode()", which would be executed when called. All plugins must also be placed in the nikto_plugin_order.txt file in the proper location for execution, otherwise it will not be called. See the section "Test Identifiers" for how to select and create a unique identifier for any test written in code, and how to ensure the test result is stored in saved output. Test Identifiers Each test, whether it comes from one of the databases or in code, must have a unique identifier. The numbering scheme for writing tests is as follows: 000000 db_tests 400000 user defined tests (udb* files) 500000 db_favicon 600000 db_outdated 700000 db_realms 800000 db_server_msgs 900000 tests defined in code As much data as possible in the %TESTS hash should be populated for each new test that is defined in code (plugins). These fields include URI for the test, message to print on success, HTTP method and OSVDB ID. Without a 'message' value in %TESTS output will not be saved in HTML or XML reports. Not all tests are expected to have a uri, method or OSVDB ID. Here is an example of setting those fields: $TESTS{999999}{uri}="/~root"; $TESTS{999999}{message}="Enumeration of users is possible by requesting ~username"; $TESTS{999999}{method}="GET"; $TESTS{999999}{osvdb}=637; Code Copyrights Any new or updated code, tests or information sent to the author is assumed to free of copyrights. By sending new or updated code, tests or information to the author you relinquish all claims of copyright on the material, and agree that this code can be claimed under the same copyright as Nikto. Troubleshooting SOCKS Proxies Nikto does not currently support SOCKS proxies. Licenses Nikto Nikto is licensed under the GNU General Public License (GPL), and copyrighted by CIRT, Inc. LibWhisker LibWhisker is licensed under the GNU General Public License (GPL), and copyrighted by Rain Forrest Puppy. Tests The web tests are licensed for use with Nikto only, and may not be reused without written consent from CIRT, Inc. Credits Nikto Nikto is written and maintained by Sullo, CIRT, Inc. All code is © CIRT, Inc., except LibWhisker which is © rfp.labs (wiretrip.net). Other portions of code may be © as specified. Thanks Many people have provided feedback, fixes, and suggestions. This list attempts to make note of those people, though not all contributors are listed. In no particular order: Nikto 2 Testing: Paul Woroshow, Mark G. Spencer, Michel Arboi, Jericho, rfp Jericho (attrition.org/OSVDB/OSF). Support/ideas/tests/corrections/spam and help matching OSVDB IDs to tests. rfp (wiretrip.net). LibWhisker and continuing support. Erik Cabetas for many updates and fixes. Jake Kouns (OSVDB/OSF). Jabra (spl0it.org) for XML DTD, XML templates and supporting code. Stephen Valdez. Extensive testing. We all miss you. S Saady. Extensive testing. Zeno (cgisecurity.com). Nikto mirroring. P Eronen (nixu.com). Provided many code fixes. M Arboi. Great support by writing the code to make Nikto work within Nessus, as well as bug reports. T Seyrat. Maintains Nikto for the Debian releases. J DePriest. Ideas/fixes. P Woroshow. Ideas/fixes. fr0stman. Tests. H Heimann. Tests. Xiola (xiola.net). Web design and more. This document is © 2008 CIRT, Inc. and may not be reused without permission.