From subs at qcontinuum.plus.com Tue May 1 07:33:51 2012 From: subs at qcontinuum.plus.com (Subscriptions) Date: Tue, 01 May 2012 13:33:51 +0100 Subject: [Nikto-discuss] Nikto plugin for Nessus Message-ID: <4F9FD82F.4020506@qcontinuum.plus.com> I'm not sure who is responsible for the nikto.nasl Nessus plugin, but since I haven't got a response from Tenable yet, I decided to raise the issue here as well. I recently discovered the Nikto plugin for Nessus and installed it on our server running Nessus 5.1. Having followed the configuration steps on Tenable's website I got everything working nicely. About a week ago it suddenly stopped working. I have checked that: - Nikto runs Ok on its own. - Nikto directory is in the system path. - Nikto can be called using ..\..\nasl nikto.nasl from the plugins directory. - Nikto is enabled in the policy preferences - The correct policy is being used in the scan template - web application tests are enabled - CGI Abuses and CGI Abuses:XSS are enabled, along with service detection, settings and web servers - have also tried with ALL plugins enabled - Disable if server never replies 404: tried checked and unchecked - rebooted server to make sure I cannot see anything in the log showing that the plugin is being run, nor can I see a 'perl nikto.pl' process starting while the scan is in progress. Although the plugins have been updated via our Professional Feed, the nikto.nasl plugin appears to have the same date and appears unchanged. I think this may be a Nessus rather than a Nikto issue so apologies if I shouldn't have posted here, but I'm running out of ideas and was hoping that someone might have thought of something I haven't. From jericho at attrition.org Tue May 1 13:18:58 2012 From: jericho at attrition.org (security curmudgeon) Date: Tue, 1 May 2012 13:18:58 -0500 (CDT) Subject: [Nikto-discuss] Nikto plugin for Nessus In-Reply-To: <4F9FD82F.4020506@qcontinuum.plus.com> References: <4F9FD82F.4020506@qcontinuum.plus.com> Message-ID: On Tue, 1 May 2012, Subscriptions wrote: : I'm not sure who is responsible for the nikto.nasl Nessus plugin, but : since I haven't got a response from Tenable yet, I decided to raise the : issue here as well. 5.0.1 I assume (Apr 16)? : I recently discovered the Nikto plugin for Nessus and installed it on : our server running Nessus 5.1. Having followed the configuration steps : on Tenable's website I got everything working nicely. About a week ago : it suddenly stopped working. That plugin has not been changed since 2011/03/21, so it shouldn't be related to it. The upgrade to 5.0.1, or if you upgraded Nikto recently, may be an issue. : I see a 'perl nikto.pl' process starting while the scan is in progress. : Although the plugins have been updated via our Professional Feed, the : nikto.nasl plugin appears to have the same date and appears unchanged. I : think this may be a Nessus rather than a Nikto issue so apologies if I : shouldn't have posted here, but I'm running out of ideas and was hoping : that someone might have thought of something I haven't. First, can you confirm the exact dates of when it last worked, as compared to when you upgraded to 5.0.1? From subs at qcontinuum.plus.com Fri May 4 06:27:54 2012 From: subs at qcontinuum.plus.com (Subscriptions) Date: Fri, 04 May 2012 12:27:54 +0100 Subject: [Nikto-discuss] Nikto plugin for Nessus Message-ID: <4FA3BD3A.7060505@qcontinuum.plus.com> Having spent considerable time on this, I'm wondering whether the fact that it worked at all in the first place was a fluke! It seems to come down to some kind of problem with how the pread function determines 'the directory where the command was found' when the the cd parameter is set to true or 1. Since find_in_path does not directly return a value, I'm not sure how pread can determine that path. If the return value is being stored somewhere then it appears to be getting changed before we reach the call to pread. Whatever the case, end result was always the same; the cmd variable was getting set to 'nikto' but the plugin was still returning 'Nikto was not found in $PATH'. Since I also wanted to be able to run Nikto on Windows (for no other reason than the fact that the organization I work for is insisting on it) I decided to investigate the workings of nikto.nasl and modify it to allow an override of this 'auto detect' feature. It seems this was a worthwhile effort as I now have an version of the plugin that allows the admin to override the result of the 'find_in_path' function and specify an absolute path to Nikto. In addition, I provided a second field to specify optional additional parameters. On a Windows system this allows the admin to specify 'perl' as the command and the path to the Nikto script as the first command line option. If the new fields are left blank, then the plugin behaves as it always has done. The only restriction is that for it to work on Windows, you have to be running Nessus 5.x. As I understand it, Nessus 4.x does not support the pread function on Windows. Until I can figure out how to sign the plugin, I've had to set nasl_no_signature_check = yes. If the code is of interest to anyone, I will be happy to supply it. On 01/05/2012 19:18, security curmudgeon wrote: > On Tue, 1 May 2012, Subscriptions wrote: > > : I'm not sure who is responsible for the nikto.nasl Nessus plugin, but > : since I haven't got a response from Tenable yet, I decided to raise the > : issue here as well. > > 5.0.1 I assume (Apr 16)? > > : I recently discovered the Nikto plugin for Nessus and installed it on > : our server running Nessus 5.1. Having followed the configuration steps > : on Tenable's website I got everything working nicely. About a week ago > : it suddenly stopped working. > > That plugin has not been changed since 2011/03/21, so it shouldn't be > related to it. The upgrade to 5.0.1, or if you upgraded Nikto recently, > may be an issue. > > : I see a 'perl nikto.pl' process starting while the scan is in progress. > : Although the plugins have been updated via our Professional Feed, the > : nikto.nasl plugin appears to have the same date and appears > unchanged. I > : think this may be a Nessus rather than a Nikto issue so apologies if I > : shouldn't have posted here, but I'm running out of ideas and was hoping > : that someone might have thought of something I haven't. > > First, can you confirm the exact dates of when it last worked, as > compared to when you upgraded to 5.0.1? From subs at qcontinuum.plus.com Fri May 4 06:52:01 2012 From: subs at qcontinuum.plus.com (Subscriptions) Date: Fri, 04 May 2012 12:52:01 +0100 Subject: [Nikto-discuss] Nikto tuning : passwords Message-ID: <4FA3C2E1.3020901@qcontinuum.plus.com> I'm looking at the Nikto tuning options and I came across this mutate option: 2. Guess for password file names. Takes a list of common password file names (such as "passwd", "pass", "password") and file extensions ("txt", "pwd", "bak", etc.) and builds a list of files to check for. So presumably this searches for know password file names accessible for the web server. I tried running a scan with it on and it ran for a very long time (over 20mins). I had to kill it eventually. Is it supposed to take this long? Is there also an option that can search for passwords embedded in config files? From subs at qcontinuum.plus.com Fri May 4 07:24:39 2012 From: subs at qcontinuum.plus.com (Subscriptions) Date: Fri, 04 May 2012 13:24:39 +0100 Subject: [Nikto-discuss] Nikto HTML output Message-ID: <4FA3CA87.40600@qcontinuum.plus.com> When Nikto output is passed to Nessus via the nikto.nasl plugin, it is passed as plain text which is not displayed very well in Nessus. Since Nikto can pass output in HTML, is it possible to output HTML but just the content of the BODY section? From subs at qcontinuum.plus.com Wed May 9 05:21:39 2012 From: subs at qcontinuum.plus.com (Subscriptions) Date: Wed, 09 May 2012 11:21:39 +0100 Subject: [Nikto-discuss] Nikto plugin for Nessus In-Reply-To: References: <4F9FD82F.4020506@qcontinuum.plus.com> <4FA29E7F.70707@qcontinuum.plus.com> Message-ID: <4FAA4533.7010702@qcontinuum.plus.com> Agree with that. There are some issues on Debian based systems (e.g. Ubuntu) for example due to the way sudo works on these Linux variants. I am however 100% certain on my system this is not a 'pathing issue'. On 04/05/2012 19:39, security curmudgeon wrote: > On Thu, 3 May 2012, Subscriptions wrote: > > : Having spent considerable time on this, I'm wondering whether the fact > : that it worked at all in the first place was a fluke! > > Once the pathing issues are fixed (accounts for 95% of the problems), it > has worked fine historically. I have not tested it with Nessus 5 or 5.0.1 > though. I appreciate the response, a couple of days after I posted here, I found out that this is not quite so. While only Tenable can sign official plugins with their official key, it is also possible to create a single 'local' key using OpenSSL and sign plugins with that key. https://discussions.nessus.org/thread/1710 There appear to be problems with this under Windows apparently: https://discussions.nessus.org/message/15580#15580 I tried it and it does work and gets rid of the errors relating to unsigned plugins means that I do not have to set Nessus to accept untrusted plugins. Just thought I'd share that. A little more development and I will be happy to share that plugin code with Tenable. I'm working with Nikto 2.1.4 and am also in the process of updating the nikto.nasl plugin to use the Nikto -Plugin option rather than -mutate as per documentation. I'm also adding the missing mutate options as mutate 5 (-Plugin subdomain) might be useful to us. When is the deprecated -mutate option scheduled to be completely withdrawn? > Only Tenable can sign plugins for security reasons. > > : If the code is of interest to anyone, I will be happy to supply it. > > You should definitely share the code with Tenable. If the changes are > solid, they can likely integrate them and release an updated nikto.pl > script for everyone. > > If you want, mail bmartin at tenable.com and it will get passed to R&D. From jericho at attrition.org Wed May 9 13:03:26 2012 From: jericho at attrition.org (security curmudgeon) Date: Wed, 9 May 2012 13:03:26 -0500 (CDT) Subject: [Nikto-discuss] Nikto plugin for Nessus In-Reply-To: <4FAA4533.7010702@qcontinuum.plus.com> References: <4F9FD82F.4020506@qcontinuum.plus.com> <4FA29E7F.70707@qcontinuum.plus.com> <4FAA4533.7010702@qcontinuum.plus.com> Message-ID: : > Once the pathing issues are fixed (accounts for 95% of the problems), it : > has worked fine historically. I have not tested it with Nessus 5 or 5.0.1 : > though. : : I appreciate the response, a couple of days after I posted here, I found : out that this is not quite so. While only Tenable can sign official : plugins with their official key, it is also possible to create a single : 'local' key using OpenSSL and sign plugins with that key. Yes, you can bypass the need for Tenable to sign it. I said that in the context of rolling it out as a solution across the enterprise, where self signing could be problematic for pushing updates, or getting updates from Tenable. : A little more development and I will be happy to share that plugin code : with Tenable. I'm working with Nikto 2.1.4 and am also in the process of : updating the nikto.nasl plugin to use the Nikto -Plugin option rather : than -mutate as per documentation. I'm also adding the missing mutate : options as mutate 5 (-Plugin subdomain) might be useful to us. : : When is the deprecated -mutate option scheduled to be completely : withdrawn? That is a question for Sullo or the Nikto team. From csullo at gmail.com Wed May 9 13:09:37 2012 From: csullo at gmail.com (Sullo) Date: Wed, 9 May 2012 14:09:37 -0400 Subject: [Nikto-discuss] Nikto plugin for Nessus In-Reply-To: References: <4F9FD82F.4020506@qcontinuum.plus.com> <4FA29E7F.70707@qcontinuum.plus.com> <4FAA4533.7010702@qcontinuum.plus.com> Message-ID: On Wed, May 9, 2012 at 2:03 PM, security curmudgeon wrote: > > > : A little more development and I will be happy to share that plugin code > : with Tenable. I'm working with Nikto 2.1.4 and am also in the process of > : updating the nikto.nasl plugin to use the Nikto -Plugin option rather > : than -mutate as per documentation. I'm also adding the missing mutate > : options as mutate 5 (-Plugin subdomain) might be useful to us. > : > : When is the deprecated -mutate option scheduled to be completely > : withdrawn? > > That is a question for Sullo or the Nikto team. > Thanks, missed that one! There's not much effort going on with removing that code, so I wouldn't expect it to leave any time soon. Ultimately, it needs to be reimplemented via -Plugins so the functionality is not fully lost. Right now development is shifting to some other changes. And if possible, we'll leave -mutate in for legacy commands... much like -findonly, which now is just an 'alias' for the proper -Plugins options. -- RVAsec security conference & training: June 15-16, Richmond, VA http://rvasec.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From subs at qcontinuum.plus.com Thu May 10 06:23:16 2012 From: subs at qcontinuum.plus.com (Subscriptions) Date: Thu, 10 May 2012 12:23:16 +0100 Subject: [Nikto-discuss] Nikto not finding plugins Message-ID: <4FABA524.1010002@qcontinuum.plus.com> I'm having trouble running Nikto on one of my servers. Its a Windows 2008 machine. and I'm running Nikto 2.1.4. I have Nikto installed in C:\Scripts\Nikto and if I run if from that directory it works fine. However, if I run it from anywhere else it fails with: c:\Temp>perl c:\scripts\nikto\nikto.pl Can't locate plugins/nikto_core.plugin in @INC (@INC contains: C:/strawberry/perl/site/lib C:/strawberry/perl/vendor/lib C:/strawberry/perl/lib .) at c:\scripts\nikto\nikto.pl line 85. In the nikto.pl I have: $VARIABLES{'configfile'} = "C:/Scripts/Nikto/nikto.conf"; In the config file I have also added: EXECDIR=C:/Scripts/Nikto This worked fine on my Vista laptop and allowed me to run Nikto from anywhere, but does not appear to work on Windows 2008 server. I have also tried running perl with an -IC:/Scripts/Nikto like this: perl -IC:/Scripts/Nikto c:/scripts/nikto/nikto.pl -F csv -o - -vhost localhost -timeout 5 -host 127.0.0.1 -port 8834 -ssl But this time I get: + ERROR: Can't find/read required file "plugins/db_404_strings" Time::HiRes::ualarm(): unimplemented in this platform at (eval 8) line 1 BEGIN failed--compilation aborted at (eval 8) line 2. ...propagated at C:/Scripts/Nikto/plugins/nikto_core.plugin line 1071. The files are there and, as I said, it works OK when I cd to the Nikto directory first. Can anyone she any light on this? From subs at qcontinuum.plus.com Thu May 10 10:17:50 2012 From: subs at qcontinuum.plus.com (Subscriptions) Date: Thu, 10 May 2012 16:17:50 +0100 Subject: [Nikto-discuss] Nikto not finding plugins Message-ID: <4FABDC1E.7040008@qcontinuum.plus.com> Ok, I think I've found the answer. In one conf file these two settings were commented out: # PLUGINDIR=/opt/nikto/plugins # TEMPLATEDIR=/opt/nikto/templates Whereas on the offending machine these settings were set to: PLUGINDIR=plugins TEMPLATEDIR=templates Not sure why that was the case (no one else is using the system) so I simply commented them out and now it works. From subs at qcontinuum.plus.com Tue May 15 04:16:18 2012 From: subs at qcontinuum.plus.com (Subscriptions) Date: Tue, 15 May 2012 10:16:18 +0100 Subject: [Nikto-discuss] Nikto updates Message-ID: <4FB21EE2.6030406@qcontinuum.plus.com> How often does Nikto get updated? I notice on the update repository there have not been any updates since July 2011. I appreciate it depends on new threats being identified, but I find it hard to believe that nothing new has cropped up for nearly a year? Incidentally, what is the recommended interval to run the nikto.pl -update command? The documentation does not appear to specify or recommend anything. From wkwang at cisco.com Wed May 23 16:01:15 2012 From: wkwang at cisco.com (Peter Wang (wkwang)) Date: Wed, 23 May 2012 21:01:15 +0000 Subject: [Nikto-discuss] Not well-formed XML report containing not escaped chars Message-ID: Hi, In parsing one of Nikto XML report file, my script throw an error complaining error "not well-formed (invalid token)" at line 5 character 88 /O=TANDBERG/OU=UKR&D/ <--Error-- CN=ukdev-mint.uk.rd.tandberg.com/emailA" Finding the XML report containing some special characters in the text without necessary escaping. An offending section is as below, Thanks, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: