When installing the vulnerability scanner application Nikto/Nikto2 using yum with RedHat Enterprise Linux 7 or CentOS 7 or even Scientific Linux 7, the odds are good that you will encounter some irritating problems. Namely, the installation will fail while requiring a dependency that appears to not exist for the version of linux you are using. Fun! So you probably think you are safe if you install OpenVAS, a prepackaged suite of security utilities that includes Nikto as a plugin. But you would be wrong! Installing OpenVAS from an RPM will succeed, and everything will look fine, until you try to use Nikto within OpenVAS, which will result in a fatal error.
Nikto is included in the Extra Packages for Enterprise Linux/EPEL yum repository all recent versions of RedHat linux, which is part of the Fedora Project. While it contains third party applications, it is not a third party repository like RPMFusion or Atomicorp. I have only very rarely had problems with the EPEL yum repo, and this is the first time I have had problems with it in years.
So here is what the failure looks like:
Alternatively, if you are going the OpenVAS route, your scan report will include the following error from the Nikto plugin:
The studious reader will have noticed a common theme to the failure: a Perl module going by the mysterious initials "LW2". The initials stand for perl-libwhisker2. LibWhisker2 is in fact a library for Perl, focusing on http functions. It is commonly used by vulnerability scanners. However, to make matters a bit more complicated, more recent versions of Nikto require a slightly modified version of LibWhisker2, as can be seen from the Nikto installation guide (italics mine):
So how about just finding a third party repository that has addressed this issue, adding that repository to your server, and calling it a day? Seems reasonable enough, however, I looked at several repositories and I could only find one - Atomicorp - that appears to have patched this issue. Furthermore, there are many administrators who are wary of adding third party repositories to servers. Vulnerability scanners collect a wealth of very sensitive information. Even excellent third party repositories require that users provide a significant amount of trust in installing using their packages. To many admins, adding a third party repo simply is not an option.
Fortunately, I have confirmed for the time being that a previous RPM included in repositories for Fedora Core 19 will resolve the issues listed in this post. I have uploaded the LibWhisker2 RPM to my rarely-used Github page should anyone else need it. Remember you need to install Perl first, before installing the RPM.
NOTE: If you plan on using Nikto with Metasploit, you will require two additional Perl modules to correctly use logging: RPC::XML and RPC::XML::Client. Both of these are available through the EPEL yum repo using `yum install perl-RPC-XML.noarch`. This dependency is pretty clearly outlined in the Nikto installation documentation (and not required for a basic Nikto installation, like LibWhisker).
Nikto is included in the Extra Packages for Enterprise Linux/EPEL yum repository all recent versions of RedHat linux, which is part of the Fedora Project. While it contains third party applications, it is not a third party repository like RPMFusion or Atomicorp. I have only very rarely had problems with the EPEL yum repo, and this is the first time I have had problems with it in years.
So here is what the failure looks like:
[root@ip-172-31-20-10 notes]# yum install nikto
Loaded plugins: amazon-id, rhui-lb
Resolving Dependencies
--> Running transaction check
---> Package nikto.noarch 1:2.1.5-10.el7 will be installed
--> Processing Dependency: perl(LW2) for package: 1:nikto-2.1.5-10.el7.noarch
--> Finished Dependency Resolution
Error: Package: 1:nikto-2.1.5-10.el7.noarch (epel)
Requires: perl(LW2)
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
Alternatively, if you are going the OpenVAS route, your scan report will include the following error from the Nikto plugin:
Can't locate LW2.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /usr/bin/nikto line 63. BEGIN failed--compilation aborted at /usr/bin/nikto line 63.
The studious reader will have noticed a common theme to the failure: a Perl module going by the mysterious initials "LW2". The initials stand for perl-libwhisker2. LibWhisker2 is in fact a library for Perl, focusing on http functions. It is commonly used by vulnerability scanners. However, to make matters a bit more complicated, more recent versions of Nikto require a slightly modified version of LibWhisker2, as can be seen from the Nikto installation guide (italics mine):
The only required Perl module that does not come standard is LibWhisker. Nikto comes with and is configured to use a local LW.pm file (in the plugins directory). As of Nikto version 2.1.5, the included LibWhisker differs (slightly) from the standard LibWhisker 2.5 distribution.LibWhisker has always been somewhat of a pain in the ass for Nikto users. Eight years ago, when LibWhisker updated from version 1.x to version 2.x, Red Hat users found themselves unable to install Nikto when the repositories all dropped version 1.x from their package lists, even while the Nikto installer still required the previous version. Its obvious then that the package for installing the LibWhisker library has been packaged in a variety of Red Hat repositories for years. As of Red Hat 7, it is no longer included. Why? Who knows.
So how about just finding a third party repository that has addressed this issue, adding that repository to your server, and calling it a day? Seems reasonable enough, however, I looked at several repositories and I could only find one - Atomicorp - that appears to have patched this issue. Furthermore, there are many administrators who are wary of adding third party repositories to servers. Vulnerability scanners collect a wealth of very sensitive information. Even excellent third party repositories require that users provide a significant amount of trust in installing using their packages. To many admins, adding a third party repo simply is not an option.
Fortunately, I have confirmed for the time being that a previous RPM included in repositories for Fedora Core 19 will resolve the issues listed in this post. I have uploaded the LibWhisker2 RPM to my rarely-used Github page should anyone else need it. Remember you need to install Perl first, before installing the RPM.
NOTE: If you plan on using Nikto with Metasploit, you will require two additional Perl modules to correctly use logging: RPC::XML and RPC::XML::Client. Both of these are available through the EPEL yum repo using `yum install perl-RPC-XML.noarch`. This dependency is pretty clearly outlined in the Nikto installation documentation (and not required for a basic Nikto installation, like LibWhisker).