Nikto is an open source web server vulnerabilities scanner, it is written in Perl, publically available since 2011. Nikto provides the hability to search in webservers for wide known vulnerabilites. It does by itself more than 6.400 verifications about potentially dangerous web server flaws. Not every check is a security problem, though most are. There are some items that are "info only" type checks that look for things that may not have a security flaw, but the webmaster or security engineer may not know are present on the server. These items are usually marked appropriately in the information printed. There are also some checks for unknown items which have been seen scanned for in log files. For more information about Nikto, please visit the official repository of the project at Github here or visit the official documentation here.
In this article, we will explain you briefly how to use Nikto properly and easily in Kali Linux.
How to use it?
Nikto is included by default on any Kali Linux distribution, so if you type in the console:
nikto --helpYou should be able to see all the options that the CLI tool has on the output. Now, in order to scan for vulnerabilities on a website/server is so simple as running the following command:
nikto -h <server-ip> -p <port>Where:
-h: the ip address or hostname of the server that you want to scan.-p: as not every website runs on the 80 port, you may specify the port with this option.
Note that some servers may run multiple websites on the same server, so they will share the same IP, so if you want a specific scan for the correct website, provide the domain (hostname) instead of the IP e.g google.com. However if you want to scan a website that uses a SSL certificated (secured connection), the port should obviously change as well, for example to scan our own website we could just simply run:
nikto -h ourcodeworld.com -p 443And the scan should start as well. With a secured website, you will see as well the information of the SSL certificate and Nikto will run additional test for checking vulnerabilities on the SSL certificate. The output of nikto in the command line looks like this:
The scannning will took a while. In our case it took around 15 minutes and Nikto made 8348 requests checking for vulnerabilities:
As a server administrator should i fix everything on the generated list?
After detecting all the vulnerabilities of the server, is up to you to fixing them on the server that you've just tested. Note that not all the + are vulnerabilities, but information as well, so you will need to interpret correctly the information provided by Nikto and proceed according to the warning. Nikto uses the OSVDB (Open Source Vulnerability Database) codes, to provide information about the discovered vulnerabilities.
For example, when we scan the output of our website through the HTTPS protocol, we will have additional warnings:
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP: 69.64.34.144
+ Target Hostname: ourcodeworld.com
+ Target Port: 443
---------------------------------------------------------------------------
+ SSL Info: Subject: /OU=Domain Control Validated/OU=PositiveSSL Wildcard/CN=*.ourcodeworld.com
Ciphers: ECDHE-RSA-AES256-GCM-SHA384
Issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
+ Start Time: 2019-05-18 14:53:34 (GMT-5)
---------------------------------------------------------------------------
+ Server: Apache
+ Retrieved x-powered-by header: PleskLin
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The site uses SSL and the Strict-Transport-Security HTTP header is not defined.
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ Server leaks inodes via ETags, header found with file /cgi-bin/, fields: 0x31b 0x56c06c7df334a
+ The Content-Encoding header is set to "deflate" this may mean that the server is vulnerable to the BREACH attack.
+ Server is using a wildcard certificate: *.ourcodeworld.com
+ Web Server returns a valid response with junk HTTP methods, this may cause false positives.
+ OSVDB-3092: /sitemap.xml: This gives a nice listing of the site content.The message "Server is using a wildcard certificate: *.ourcodeworld.com" is generated by the tool, but, what does this means, i mean, we are using a SSL certificate to protect the website, that's better than nothing right? Well, in theory Nikto displays this warning because Wildcard Certificates are less secure than regular certificates, interesting right?. Other important example that you need to interpret right is the following: "The Content-Encoding header is set to "deflate" this may mean that the server is vulnerable to the BREACH attack", you can find a detailed but easy to understand explanation about the BREACH attack here. As mentioned on the article, the solution for this issue may be turning off the HTTP compression, but how in the world would you send uncompressed resources to your users ! That would increase the download times etc, recommended solutions for this issue would be instead on our code, not in the server by itself:
-
Protecting the vulnerable pages with a CSRF token.
-
Adding random bytes to the response to hide the actual compressed length.
-
Separating the sensitive data from the pages where input text is displayed.
The other epic message is the "OSVDB-3092: /sitemap.xml: This gives a nice listing of the site content.". Sure in some cases, the exposal of this information on a website would be harmful, but this kind of file is necessary for Google Web Masters to positionate the website in google ! With such messages, as a pentester you don't need to be paranoic and read carefully the warnings and intervene properly so you won't mess up things that are already working properly.
Happy pentesting !
