The list of successful attacks through web servers is long: first, because attackers can access operating system resources through vulnerabilities that should never be accessible to the outside world; second, because faulty settings or errors are made by admins when setting up their web servers (e.g., configuring aliases and allowing directory listings) or securing certain areas and functions; and third, especially in dynamic web applications, because scripting language interpreters or application servers are allowed to run in the background, which itself causes security problems or lets insecure scripts or programs execute.

If you are responsible for the security of your corporate infrastructure, you probably have an overview of the web servers that are accessible from the Internet. Ideally, you will operate these servers in dedicated areas of your demilitarized zone (DMZ network) and deploy web application firewalls to prevent attacks wherever possible. Nikto [1] lets you check the web server, the configuration, and the stored content and generates a detailed report that helps you support the people responsible for further hardening operations.

Nikto is written in Perl and has been under development since 2001. Unlike many other security products from that time, however, Nikto is still under active development today. Even if the last version tagged as stable dates back to 2015, you can always retrieve the latest Perl script from the Git repository on GitHub. To prepare the tests, first clone the Git repository with the command:

git clone https://github.com/sullo/nikto.git

For this article, I assume that Perl is already installed on your computer. If not, you can use the Dockerfile included in the repository to install Nikto in an Alpine image by executing in the folder

docker build -t nikto .

After doing so, you can use Nikto just as you would locally on your system. Instead of

./nikto.pl

simply start the container by typing

docker run --rm nikto

The --rm option lets you remove the instance of the container you created when the program terminates, which avoids the need to clean up manually later on. You can test the general functionality locally by changing to the program folder and running nikto.pl there. Alternatively, you can use a Docker image created previously.

Running Tests

For your first test, it's a good idea to choose a web server that you own and operate yourself, so you can avoid being blocked by attack detection mechanisms. Although I had always run against a particular <name>.de successfully for other security tests, I fell foul of the attack detection systems when I ran Nikto against them: Accessing the website from the same IP address will no longer be possible if this happens to you. Make sure you replace the domain in the call with

./nikto.pl -url <name>.de -ssl

Being locked out basically means that the attack detection mechanisms work; however, you also want to test access beyond this detection system on your own web servers because if you are blocked by your security mechanisms after 20 percent of the tests, then 80 percent of the tests will not be run against the web server or the application will run and you will see a timeout. In the end, you don't know whether your web application is vulnerable, and you don't know whether your attack detection system would have detected all of the other attacks simulated by Nikto.

Nikto also shows information about the server itself, such as the HTTP headers, cookies, and redirects. I created the test folder Software on the web server and "protected" it with guest:guest as the login credentials. Finding that was as easy as pie for Nikto.

More Tests

If you want to check specific aspects of your web server, Nikto offers you some options for doing so. For example, if you want to access a protected area, you can pass in some valid credentials to the tool with the command

./nikto.pl -url example.com -id username:password

If you only want to run isolated tests, you can do so by specifying the -Tuning argument. The output of your first test run provides the options. To test for SQL injection only, run the command

./nikto.pl -url example.com -Tuning 9

You can also exclude individual tests. Assuming you want to check everything except SQL injection, prefix the selection with an x:

./nikto.pl -url example.com -Tuning x9

Nikto lets you specify different ports for the next test run, which is useful because, for example, Tomcat environments are often accessible by different servers or endpoints. The selection of ports can be passed in to Nikto:

./nikto.pl -url example.com -p 80,88,443,8080,8443

If you want to configure Nikto further for your own tests (for example, to set a persistent HTTP proxy), copy the nikto.conf.default file to nikto.conf, where you will find more configuration options for your environment. Depending on whether your web server distinguishes the requesting user agents, you might want to adjust the USERAGENT option in the configuration with the -useragent argument and specify this information individually for each call to Nikto. The SKIPPORTS option lets you avoid requests for certain ports, for example, because you already know that these services are vulnerable or that you do not want to take any unnecessary risks.

If you want to give Nikto a cookie (e.g., for authentication or for use in an application session), you can use the configuration file. If you add appropriate values to STATIC-COOKIE, these values will be sent with all future requests. Firefox with the web developer tools enabled is a good choice if you want to retrieve meaningful cookie values, such as session variables. Under the Storage item, you can then display the cookie values for each domain accessed by the last query. Simply copy the content you find there to the Nikto configuration file. To make Nikto use the configuration, specify the path with the next call at the command line:

./nikto.pl -url example.com -config ./nikto.conf

If you do not like, or are not satisfied with, the command-line output, you can opt for output in HTML format:

./nikto.pl -url example.com -ssl -output results.html -Format htm

Besides HTML, you can also choose CSV, text, or XML as output formats. Displaying the report in HTML format sometimes improves readability and makes it easier to forward the results. Nikto also adds more information and links to the resources causing the hits here.

Nikto requires different specifications for external databases and plugins depending on the test you are running. You can access them in the developer's CIRT.net platform, which is also where you will find, for example, a default password database that you can also use individually on the site. If you want to update Nikto with the data stored there, use the command

./nikto.pl -update

Conclusions

Nikto is a great tool for checking your web servers for known vulnerabilities. It is easy to use, clear-cut in terms of its feature set, serves its purpose, and can compete with other pentesting tools.