From here on out, you no longer need sudo privileges. This means you can have a break from always having to type your password.

To do a simple scan, use the -h option to specify the target host:

nikto -h 192.168.0.9
nikto -h www.example.com

Let's look at some sample output. Here's the top part:

+ Allowed HTTP Methods: POST, OPTIONS, GET, HEAD
+ OSVDB-396: /_vti_bin/shtml.exe: Attackers may be able to crash FrontPage by requesting a DOS device, like shtml.exe/aux.htm -- a DoS was not attempted.
+ /cgi-bin/guestbook.pl: May allow attackers to execute commands as the web daemon.
+ /cgi-bin/wwwadmin.pl: Administration CGI?
+ /cgi-bin/Count.cgi: This may allow attackers to execute arbitrary commands on the server

At the top, we can see that there's an shtml.exe file present, which is supposedly for the FrontPage web authoring program. I have no idea why it's there, considering that this is a Linux server and that that's a Windows executable. Nikto is telling me that by having that file there, someone could possibly do a Denial of Service (DOS) attack against me.

Next, we can see that there are various scripts in the /cgi-bin directory. You can see from the explanatory messages that that's not a good thing because it could allow attackers to execute commands on my server.

Let's look at the second part:

+ OSVDB-28260: /_vti_bin/shtml.exe/_vti_rpc?method=server+version%3a4%2e0%2e2%2e2611: Gives info about server settings.
+ OSVDB-3092: /_vti_bin/_vti_aut/author.exe?method=list+documents%3a3%2e0%2e2%2e1706&service%5fname=&listHiddenDocs=true&listExplorerDocs=true&listRecurse=false&listFiles=true&listFolders=true&listLinkInfo=true&listIncludeParent=true&listDerivedT=false&listBorders=fals: We seem to have authoring access to the FrontPage web.

Here, we can see that there's an author.exe file in the vti_bin directory, which could theoretically allow someone to have authoring privileges.

And now, the final part:

+ OSVDB-250: /wwwboard/passwd.txt: The wwwboard password file is browsable. Change wwwboard to store this file elsewhere, or upgrade to the latest version.
+ OSVDB-3092: /stats/: This might be interesting...
+ OSVDB-3092: /test.html: This might be interesting...
+ OSVDB-3092: /webstats/: This might be interesting...
+ OSVDB-3092: /cgi-bin/wwwboard.pl: This might be interesting...
+ OSVDB-3233: /_vti_bin/shtml.exe/_vti_rpc: FrontPage may be installed.
+ 6545 items checked: 0 error(s) and 15 item(s) reported on remote host
+ End Time:           2017-12-24 10:54:21 (GMT-5) (678 seconds)

The final item of interest is the passwd.txt file that's in the wwwboard directory. Apparently, this password file is browsable, which is definitely not a good thing.

Now, before you accuse me of making these problems up, I will reveal that this is a scan of a real production website on a real hosting service (and yes, I do have permission to scan it), So, these problems are real and need to be fixed.

Here are a couple of other sample messages that I got from scanning a web server that's running WordPress:

HTTP TRACK method is active, suggesting the host is vulnerable to XST
Cookie wordpress_test_cookie created without the httponly flag

To cut a long story short, both of these two problems could potentially allow an attacker to steal user credentials. The fix, in this case, would be to see whether the WordPress folk have issued any updates that would fix the problem.

So, how can we protect a web server against these kinds of vulnerabilities? Let's see:

• As we saw in the first example, you want to ensure that you don't have any risky executable files on your web server. In this case, we found two .exe files that might not hurt anything on our Linux server, since Windows executable files don't run on Linux. However, on the other hand, it could be a Linux executable that's disguised as a Windows executable. We also found some perl scripts that definitely would run on Linux and that could pose a problem.
• In the event that someone were to plant some malicious script on your web server, you'll want to have some form of mandatory access control, such as SELinux or AppArmor, that would keep the malicious scripts from running. (see Chapter 9, Implementing Mandatory Access Control with SELinux and AppArmor, for details of that).
• You may also consider installing a web application firewall, such as ModSecurity. Space doesn't permit me to cover the details of ModSecurity, but you'll find a book that covers it on the Packt Publishing website.
• Keep your systems updated, especially if you're running a PHP-based content management system such as WordPress. If you keep up with the IT security news, you'll see stories about WordPress vulnerabilities more often than you'd like to.

There are other scan options that you can see by just typing nikto at the command line. For now, though, this is enough to get you started with basic web server scanning.