- Date: 21 September 2012
- Author: Arch Grinds Rips
- Category: Network Security, nikto, Tools, Web Application Security
- Comments: 0
Nikto, the well known web vulnerability scanner, derives its name from the movie “The Day The Earth Stood Still”. I found that piece of trivia here. I wanted to write a series of posts about improving Nikto usage for web application and network assessments, as its use is commonplace. If you are completely unfamiliar with Nikto, review the home page and these books for tips on basic usage. Throughout these posts, I will use Backtrack (BT5R3) as the OS distribution in the examples. If you are using a different distribution, the majority of the information presented here should be relevant, but keep in mind there may be slight differences. Starting with a few simple tips…
Easy to do, easy to forget.
On BT5R3, Nikto 2.1.5 cannot be updated with the built-in update mechanism (UPDATE: version 2.1.5 has been officially released and now can be updated via nikto.pl -update). Alternatively, subversion can be used.
root@bt:~# cd /pentest/web/nikto/
root@bt:/pentest/web/nikto# svn update
Updated to revision 850.
Keep in mind subversion will prompt to resolve conflicts if you have modified any files (nikto.conf, for example). For Nikto versions 2.1.4 and older, use nikto.pl -update
Place Nikto in $PATH
By default, Nikto is not immediately accessible from a terminal in Backtrack. Certainly not a big deal, but this can be handy, especially when automating Nikto. Typing which nikto or which nikto.pl should validate Nikto is not in $PATH. In Backtrack, most tools are usually located within the /pentest/ subdirectory, and can easily be found with the locate command.
root@bt:~# locate nikto.pl
Create symlinks for core Nikto files.
root@bt:~# ln -s /pentest/web/nikto/nikto.pl /usr/bin/nikto.pl
root@bt:~# ln -s /pentest/web/nikto/nikto.conf /etc/nikto.conf
Modify /etc/nikto.conf to include location of critical files. Using your favorite editor, change the following lines:
# Location of NiktoNIKTODTD=docs/nikto.dtd
If all went well, Nikto is now in $PATH and ready to go. Bonus.
Nikto will occasionally prompt before taking certain actions, such as submitting a fingerprint to cirt.net. Forgetting to change this behavior before kicking off an automated scan of a slew of HTTP/HTTPS services could result in a serious ‘DOH!’ moment. Modify /etc/nikto.conf to disable prompting. Change the following line:
Change The Default User Agent
Nikto’s default User-Agent string is “USERAGENT=Mozilla/5.00 (Nikto/@VERSION) (Evasions:@EVASIONS) (Test:@TESTID)”. Web Application Firewalls (WAFs) and other security devices may block Nikto scans with this User-Agent. Change it! You can determine the current browser’s User-Agent string by using a web proxy, sniffing, or using web based utilities. A gargantuan list of strings is available here, as well. Again, change the following line in /etc/nikto.conf:
USERAGENT=Mozilla/5.00 (Nikto/@VERSION) (Evasions:@EVASIONS) (Test:@TESTID)
USERAGENT=Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/4.0; InfoPath.2; SV1; .NET CLR 2.0.50727; WOW64)
Keep in mind that running a Nikto scan is usually not a stealthy endeavor (as stated on the home page), but this action can help to bypass simple pattern matching defenses.
Use The Maxtime Switch
Nikto scans that hang are a total bummer, especially in an automated setup. Specifying a maximum timeout can help to avoid a bigger loss in the event a security device uses rate limiting, tarpitting, shunning at the application layer, etc. Using ‘nikto.pl -H’ shows all available options, where the maxtime switch can be observed (this option does not exist in versions 2.1.4 and prior). The value for the maxtime parameter is specified in seconds. The following example will timeout after 4 hours:
nikto.pl -h 127.93.2.200:80 -maxtime 14400
I suggest a value that reflects hours, but really this is unique to the environment and constraints of the assessment.
Use Alternate Log Formats
Nikto is able to log in a variety of formats (CSV, HTML,NBE [Nessus], TXT, XML, and even to Metasploit). The HTML format is interesting as it allows for quicker verification of findings, though the results can be repetitive. In my opinion, the XML format provides the greatest fidelity for parsing (even with grep) and is actually easy on the eyes as well. Here’s a snippet:
<item id=”001407″ osvdbid=”119″ osvdblink=”http://osvdb.org/119″ method=”GET”>
<description><![CDATA[/?PageServices: The remote server may allow directory listings through Web Publisher by forcing the server to show all files via ‘open directory browsing’. Web Publisher should be disabled. CVE-1999-0269.]]></description>
<item id=”750000″ osvdbid=”3268″ osvdblink=”http://osvdb.org/3268″ method=”GET”>
<description><![CDATA[/?wp-cs-dump: Directory indexing found.]]></description>
Grepping ‘<description>’ or ‘<namelink>’ yields an easy way to visualize results.
The easiest way to specify a log format is by specifying a file name with the relevant file extension for the output parameter. For example, to generate an XML logfile:
nikto.pl -h 127.93.2.200:80 -maxtime 14400 -o localhost.xml
or to generate an HTML logfile:
nikto.pl -h 127.93.2.200:80 -maxtime 14400 -o localhost.html
-Arch Grinds Rips