Nikto

The vast majority of Internet-facing software is web applications. While there are only a few mail or web servers, whose security history is well known, there are thousands of web applications that do not always have a good security record. Nikto allows network administrators to identify known vulnerable web applications and dangerous files.

Nikto is an open source web scanner available on Linux and Windows. Nikto 1.35 can identify about 3,200 vulnerable applications or dangerous files on more than 600 servers, and it can identify more than 200 server security issues. The scanner supports SSL and nonstandard HTTP ports as well as the basic web authentication.

The most common vulnerabilities in web applications are:

Nikto looks for all of these vulnerabilities. It contains a list of such vulnerabilities in known applications and tests the presence and behavior of these vulnerable pieces of code.

Nikto is a command-line utility. To start a scan and save the report, type:

[julien@asus ˜]# nikto -host domain.net-Format
 csv -output nikto.csvt
---------------------------------------------------------------------------
- Nikto 1.35/1.34     -     www.cirt.net
+ Target IP:       192.168.0.1
+ Target Hostname: domain.net
+ Target Port:     80
+ Start Time:      Fri Mar  9 10:18:37 2007
---------------------------------------------------------------------------
- Scan is dependent on "Server" string which can be faked, use -g to override
+ Server: Apache/2.0.52 (CentOS)
- Retrieved X-Powered-By header: PHP/5.1.6
+ Apache/2.0.52 appears to be outdated (current is at least
Apache/2.0.54). Apache 1.3.33 is still maintained and considered secure.
+ 2.0.52 (CentOS) - TelCondex Simpleserver 2.13.31027 Build 3289 and
below allow directory traversal with '/.../' entries.

Nikto first gets information about the server. It uses it to filter out the CGI and dangerous files to test:

+ /icons/ - Directory indexing is enabled, it should only be enabled for specific dire
ctories (if required). If indexing is not used at all, the /icons directory
should be removed. (GET)

Nikto tests the server configuration. Then it looks for dangerous files and vulnerable CGIs:

+ /admin/config.php - Needs Auth: (realm "Access protected) / - TRACE option
+ appears to allow XSS or credential theft. See
http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf for details (TRACE)
+ //admin/admin.shtml - Needs Auth: (realm "Access protected)
[...]
/index.php?topic=<script>alert(document.cookie)</script>%2
0
- This might be interesting... has been seen in web logs from an unknown scanner. (GET
)
+ 2563 items checked - 14 item(s) found on remote host(s)
+ End Time:        Fri Mar  9 10:20:22 2007 (105 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

The scan is very fast (105s) on a small web site. A complete scan with all the plug-ins (using the -g option) takes only 40 seconds more.

The report can be saved in text (-Format txt), HTML (-Format hml) or CSV (-Format csv) format.

Warning

Be careful with a report in HTML format. Nikto does not escape the links. The HTML report can contain dangerous JavaScript or characters.

If you scan an HTTPS server, use the options -ssl -port 443 to run the scan. If some directories require web authentication, you can provide the login and password information to Nikto with the option -idlogin:password.

There are a lot of false positives. With a scan specific on my personal server, Nikto found 14 potential issues. Only two are truly potential issues: directory listing of /icons and the allowed use of TRACE. The potential PHP vulnerabilities, the potential cross-site scripting, etc., do not apply. The full scan (-generic option) displays two more potential issues that are also two more false positives.

Tip

If Nikto finds a CGI with the same filename as a vulnerable application, you might consider changing its name, even if it is secured. Nikto is widely used by script kiddies who will hammer the CGI if it is reported as vulnerable during a scan.

Unfortunately, Nikto added options to evade an Intrusion Detection System (IDS). I think it is unfortunate because this tool should not be used to test an IDS. Nikto was designed to quickly find known vulnerable software. Most of the CGIs it looks for are very old and do not always try to exploit vulnerability. Some tests check only whether the filename of a page is the same as known vulnerable software (/cgi-bin/mail.pl, for example). This does not mean the CGI installed is vulnerable to anything, and a request to such a script is legitimate.

The default traffic generated by Nikto can easily be flagged by an IDS since each HTTP request contains "Nikto/1.35" in the user-agent header. With one signature, an IDS would detect all the tests. The evasion options do not necessarily make it harder for the IDS to detect something.

To add an evasion technique, use the option -evasion followed by steps 1–9:

  1. URL encoding. The URL is encoded. Today's high-end IDS can manage encoded URLs without a problem. This evasion technique does not make any difference to a sophisticated IDS.

  2. Add /./ in front of each URL. With the same URL decoding feature used for the previous evasion technique, the IDS easily restores the original URL. Since this is a known evasion technique, this technique would probably be detected by most IDSes, making it less than useless.

  3. Premature URL ending. Nikto actually adds random folders followed by /../. For example, instead of requesting /icons, Nikto requests /foo/bar/../../icons, which is functionally the exact same thing. As in evasion 2, not only can the IDS understand the canonical URL just like the web server, it also detects the /../ as a directory traversal, a well-known technique.

  4. Append random long strings. Same technique as before, but with much longer strings and the same results.

  5. Fake parameters. Add unnecessary parameters (/uri/?foo=bar). This does not make any difference to a decent IDS.

  6. Tab as request spacer. Use a tab instead of a space to separate the different elements of the URL. Once again, this does not bother a decent IDS.

  7. Case-insensitivity. Change random characters to uppercase. Windows servers do not care about case-insensitivity, so the test would be valid in this instance. But for most other systems that are case-sensitive (e.g., *nix), the new URLs created do not make sense. For example, /cgi-bin/mail.pl is different from /cgi-BIn/mAIl.Pl for Apache on Linux. This evasion technique should be used very carefully.

  8. Use \ as folder separation. This is the same case as above. Using \ instead of / may be fine with IIS on Windows, but it is not for *nix: the new URL would not make sense.

  9. Session splicing. This is the only interesting evasion technique, even if it is quite old. It is basically Nikto + fragroute(http://monkey.org/˜dugsong/fragroute/). Nikto generates one byte data packets. It is a good way to easily test how an IDS handles heavily fragmented traffic without the hassle of installing fragrouter.

Nikto should be used to detect vulnerable applications that should not have been installed on a network. But it should not be used to test the coverage of an IDS, even if the addition of evasion techniques suggest that it has been designed for this. By the same token, Nessus also contains checks for vulnerable CGIs, but not as many as Nikto.