From dave at cirt.net Thu Sep 11 15:05:23 2008 From: dave at cirt.net (David Lodge) Date: Thu, 11 Sep 2008 16:05:23 +0100 Subject: [Nikto-discuss] Plugins with SQLite Message-ID: I have a version of nikto on my dev box ready to svn up, which uses SQLite for the database backend. At the moment I have only one database moved into the format: that is for the httpoptions plugin. I've thought about this for a while, the pros and cons of using a real database back end are below: Pros: * Less resource use (at the moment nikto reads all the db files into memory) * Faster lookups * Better checking for uniqueness of plugins (unique nikto_id) * Better management of nikto_ids Cons: * Dependancy on SQLite and DBD::Sqlite * Rewriting work require over nikto * Rework over the updated backend * Have to go through a client to update databases I chose SQLite as it was small, fast and complete, allowing simple file distribution. The way to use the database from a plugin is to use the following methods: 1. $dbhandle = initalise_db("db_httpoptions"); Performs all the checks to whether we can connect to the database, including selecting from the metadata table. Returns a valid dbhandle. 2. Perform normal DBI stuff 3. close_db($dbhandle); Closes down the database. The database file must contain a table called metadata. Each row contains two fields: name and contents. There must be one row with a name of "version". All other tables and their format are up to the plugin author (db_httpoptions just contains one table: httpoptions). Any thoughts or comments before I commit or scrap this work? Thanks dave From jabra at spl0it.org Thu Sep 11 15:40:35 2008 From: jabra at spl0it.org (Jabra) Date: Thu, 11 Sep 2008 11:40:35 -0400 Subject: [Nikto-discuss] Plugins with SQLite In-Reply-To: References: Message-ID: <20080911154035.GA5294@navi.v2s.org> I would do some testing to see how long it takes to scan a single web application with the new db and compare the results with using the old db. Further, I would also like to see the result of a class C. Regards, Jabra -- Jabra < jabra at spl0it.org > http://www.spl0it.org From jericho at attrition.org Thu Sep 11 17:29:05 2008 From: jericho at attrition.org (security curmudgeon) Date: Thu, 11 Sep 2008 17:29:05 +0000 (UTC) Subject: [Nikto-discuss] Plugins with SQLite In-Reply-To: References: Message-ID: : I have a version of nikto on my dev box ready to svn up, which uses : SQLite for the database backend. At the moment I have only one database : moved into the format: that is for the httpoptions plugin. : : Cons: : * Dependancy on SQLite and DBD::Sqlite : : I chose SQLite as it was small, fast and complete, allowing simple file : distribution. : Any thoughts or comments before I commit or scrap this work? As a consultant, this would be extremely annoying and possibly force me to look for another solution. For remote scans from my own box, this wouldn't be that big an issue (other than a general dislike for adding a lot more software for the same functionality we've enjoyed). If I am on a client site, or working on a quick build laptop, or using the client's hardware (somewhat rare, but definitely happens), this may be a show stopper. From dave at cirt.net Fri Sep 12 07:08:51 2008 From: dave at cirt.net (David Lodge) Date: Fri, 12 Sep 2008 08:08:51 +0100 Subject: [Nikto-discuss] Plugins with SQLite In-Reply-To: References: Message-ID: On Thu, 11 Sep 2008 18:29:05 +0100, security curmudgeon wrote: > : I have a version of nikto on my dev box ready to svn up, which uses > : SQLite for the database backend. At the moment I have only one database > : moved into the format: that is for the httpoptions plugin. > As a consultant, this would be extremely annoying and possibly force me > to look for another solution. For remote scans from my own box, this > wouldn't be that big an issue (other than a general dislike for adding > a lot more software for the same functionality we've enjoyed). I've decided to can it now - for this reason, as well as, when testing it made a lot more false positives; which for me is a really bad thing (nessus produces enough, I don't need more from nikto)! I'll still be adding functionality for plugins to load databases on the fly - though these'll be simple csv databases, like the ones already present. dave From FBreedijk at schubergphilis.com Fri Sep 12 07:58:27 2008 From: FBreedijk at schubergphilis.com (Frank Breedijk) Date: Fri, 12 Sep 2008 09:58:27 +0200 Subject: [Nikto-discuss] Plugins with SQLite In-Reply-To: References: Message-ID: David, Using an SQL backend should be an option, not a requirement. One of the great points of nikto atm is its portability lack of prerequisites. If the SQL backend option is there try to keep it as DBI generic as possible. A lot of boxes already have mysql set up on them and you may find reluctance to add yet another database (YAD;) ) Frank Breedijk ..-. .-. .- -. -.- T: +31 (0)20-7506500 E: fbreedijk at schubergphilis.com W: www.schubergphilis.com > -----Original Message----- > From: nikto-discuss-bounces at attrition.org [mailto:nikto-discuss- > bounces at attrition.org] On Behalf Of David Lodge > Sent: 11 September 2008 17:05 > To: nikto-discuss at attrition.org > Subject: [Nikto-discuss] Plugins with SQLite > > I have a version of nikto on my dev box ready to svn up, which uses > SQLite > for the database backend. At the moment I have only one database moved > into the format: that is for the httpoptions plugin. > > I've thought about this for a while, the pros and cons of using a real > database back end are below: > Pros: > * Less resource use (at the moment nikto reads all the db files into > memory) > * Faster lookups > * Better checking for uniqueness of plugins (unique nikto_id) > * Better management of nikto_ids > > Cons: > * Dependancy on SQLite and DBD::Sqlite > * Rewriting work require over nikto > * Rework over the updated backend > * Have to go through a client to update databases > > I chose SQLite as it was small, fast and complete, allowing simple file > distribution. > > The way to use the database from a plugin is to use the following > methods: > 1. $dbhandle = initalise_db("db_httpoptions"); > Performs all the checks to whether we can connect to the database, > including selecting from the metadata table. Returns a valid dbhandle. > 2. Perform normal DBI stuff > 3. close_db($dbhandle); > Closes down the database. > > The database file must contain a table called metadata. Each row > contains > two fields: name and contents. There must be one row with a name of > "version". All other tables and their format are up to the plugin > author > (db_httpoptions just contains one table: httpoptions). > > Any thoughts or comments before I commit or scrap this work? > > Thanks > > dave > _______________________________________________ > Nikto-discuss mailing list > Nikto-discuss at attrition.org > https://attrition.org/mailman/listinfo/nikto-discuss From erik at edgeos.com Fri Sep 12 18:17:31 2008 From: erik at edgeos.com (Erik) Date: Fri, 12 Sep 2008 11:17:31 -0700 Subject: [Nikto-discuss] Plugins with SQLite In-Reply-To: References: Message-ID: <48CAB23B.6010502@edgeos.com> David Lodge wrote: > * Better checking for uniqueness of plugins (unique nikto_id) > * Better management of nikto_ids I think these are important. When each threat has a unique id, more in-depth & automated analysis becomes easier. For example, it becomes easier to do a differential anaylsis: * Threat i is newly discovered. * Threat j is no longer a threat. Having ids helps a lot with the reporting. Easier to define meta data for each test (e.g. risk, reference, summary, description, solution). I think risk factor is really important. We use nikto through nessus goggles, though, so my perspective may be a little skewed to the typical nikto user. I understand that the web app threats might not be as easily defined in a "threats db" the way the nessus tests are. I am guessing that moving the tests into a relational db would be a good step towards that goal. > * Dependancy on SQLite and DBD::Sqlite In response to some of the replies about depending on this, I do not understand why it is a concern to depend on sqlite. It is very lightweight. On a Debian install, I see this for the executable and perl binding: {{{ bash> ls -lh $(for i in $(dpkg -L sqlite3); do test -f $i && echo $i; done) -rwxr-xr-x 1 root root 32K Mar 6 2007 /usr/bin/sqlite3 -rw-r--r-- 1 root root 1.6K Aug 7 2006 /usr/share/doc/sqlite3/README -rw-r--r-- 1 root root 1.8K Mar 6 2007 /usr/share/doc/sqlite3/changelog.Debian.gz -rw-r--r-- 1 root root 381 Mar 6 2007 /usr/share/doc/sqlite3/copyright -rw-r--r-- 1 root root 2.9K Mar 6 2007 /usr/share/man/man1/sqlite3.1.gz bash> ls -lh $(for i in $(dpkg -L libdbd-sqlite3-perl); do test -f $i && echo $i; done) -rw-r--r-- 1 root root 0 Oct 14 2006 /usr/lib/perl5/auto/DBD/SQLite/SQLite.bs -rw-r--r-- 1 root root 71K Oct 14 2006 /usr/lib/perl5/auto/DBD/SQLite/SQLite.so -rw-r--r-- 1 root root 1.2K Feb 22 2002 /usr/share/doc/libdbd-sqlite3-perl/README -rw-r--r-- 1 root root 2.5K Oct 14 2006 /usr/share/doc/libdbd-sqlite3-perl/changelog.Debian.gz -rw-r--r-- 1 root root 2.5K Apr 9 2006 /usr/share/doc/libdbd-sqlite3-perl/changelog.gz -rw-r--r-- 1 root root 883 Oct 14 2006 /usr/share/doc/libdbd-sqlite3-perl/copyright -rw-r--r-- 1 root root 5.6K Oct 14 2006 /usr/share/man/man3/DBD::SQLite.3pm.gz -rw-r--r-- 1 root root 16K Sep 7 2006 /usr/share/perl5/DBD/SQLite.pm }}} Those with the concern about this dependency mind explaining a bit more? Thanks, Erik From dave at cirt.net Mon Sep 15 16:04:44 2008 From: dave at cirt.net (David Lodge) Date: Mon, 15 Sep 2008 17:04:44 +0100 Subject: [Nikto-discuss] Plugins with SQLite Message-ID: Quoting Frank Breedijk : > Using an SQL backend should be an option, not a requirement. One of the > great points of nikto atm is its portability lack of prerequisites. > If the SQL backend option is there try to keep it as DBI generic as > possible. A lot of boxes already have mysql set up on them and you may > find reluctance to add yet another database (YAD;) ) It looks like there is some agreement on this for managing plugins; people like the fact that nikto is small and standalone (just need Net::SSLeay and getargs long). Other people would like it to talk to databases properly - though mainly this is about the results, rather than the tests. I'm particularly interested in this area as it highlights one of the big problems with pen testing tools: there are lots of useful and cool tools, but they produce a massive amount of false positives and don't interact very well. So I think a roadmap forward would be to leave nikto as it is, small and customised for testing web apps and either abuse the XML export, or add an option export to allow it to send data to a flavour of database (up to the user). Then we can do differences etc. from a different application. This should please the guys who like the "small nikto is good" and the people, like me, who want better talking 'twixt tools. To be honest I've had this idea for ages - pen test tool reports are great, but I seem to spend my whole life in a spreadsheet chopping out the rubbish (Nessus, I'm looking at you here). With the nikto base code, I'm just going to be tuning the database format, so it doesn't need extra modules, but it will use less memory and be more dynamic (no editing nikto_core to add a new database). dave From dave at cirt.net Thu Sep 18 18:15:59 2008 From: dave at cirt.net (David Lodge) Date: Thu, 18 Sep 2008 19:15:59 +0100 Subject: [Nikto-discuss] Conditional execution of plugins Message-ID: Just trying to get some feelers out. I'm going to be working on the plugin architecture over the next couple of weekends. Whilst planning this it occured to me that it may be beneficial to allow a plugin to be executed conditionally, e.g. if server != Apache then don't run nikto_apacheusers.plugin. The advantage to this is that we cut down the amount of time spent running and potentially cut down on false positives. The disadvantage is that we may have some false negatives if a web server is vulnerable to another web server's faults. Or, we could compromise and run the plugins, but comment that it may be a false positive. Personally, I'd rather have false positives and be notified about them than miss items that may compromise a server. Thoughts? Opinions? dave From FBreedijk at schubergphilis.com Fri Sep 19 08:48:51 2008 From: FBreedijk at schubergphilis.com (Frank Breedijk) Date: Fri, 19 Sep 2008 10:48:51 +0200 Subject: [Nikto-discuss] Conditional execution of plugins In-Reply-To: References: Message-ID: I indeed also rather have false positives marked then filtered out or have this behavior selectable. In the output this would be a criteria to group on, e.g. first have the real sure ones then the potential false positives. Frank Breedijk ..-. .-. .- -. -.- T: +31 (0)20-7506500 E: fbreedijk at schubergphilis.com W: www.schubergphilis.com > -----Original Message----- > From: nikto-discuss-bounces at attrition.org [mailto:nikto-discuss- > bounces at attrition.org] On Behalf Of David Lodge > Sent: 18 September 2008 20:16 > To: nikto-discuss at attrition.org > Subject: [Nikto-discuss] Conditional execution of plugins > > Just trying to get some feelers out. > > I'm going to be working on the plugin architecture over the next couple > of > weekends. Whilst planning this it occured to me that it may be > beneficial > to allow a plugin to be executed conditionally, e.g. if server != > Apache > then don't run nikto_apacheusers.plugin. > > The advantage to this is that we cut down the amount of time spent > running > and potentially cut down on false positives. The disadvantage is that > we > may have some false negatives if a web server is vulnerable to another > web > server's faults. > > Or, we could compromise and run the plugins, but comment that it may be > a > false positive. > > Personally, I'd rather have false positives and be notified about them > than miss items that may compromise a server. > > Thoughts? Opinions? > > dave > _______________________________________________ > Nikto-discuss mailing list > Nikto-discuss at attrition.org > https://attrition.org/mailman/listinfo/nikto-discuss From lewis at lewisfrancis.com Sun Sep 21 02:36:39 2008 From: lewis at lewisfrancis.com (lewis francis) Date: Sat, 20 Sep 2008 22:36:39 -0400 Subject: [Nikto-discuss] MacNikto 1.1 released Message-ID: Hey all, congrats on getting Nikto 2.03 out the door. Fwiw, I've posted MacNikto 1.1, a minimalist OS X gui wrapper around Nikto, now with Nikto 2.03 support + some interface tweakage: http://www.informationgift.com/macnikto/ Best, -Lewis -- filtered by: Lewis Francis @ 703.855.6995 http://www.informationgift.com/ -- From Zube at CS.ColoState.EDU Fri Sep 26 14:51:34 2008 From: Zube at CS.ColoState.EDU (Zube) Date: Fri, 26 Sep 2008 08:51:34 -0600 Subject: [Nikto-discuss] latest apache 1.x incorrected noted in 2.03 Message-ID: <20080926145134.GA8745@mozart.cs.colostate.edu> When I scan my 1.3.41 Apache web server + mod_ssl with nikto 2.03, I receive the following: Apache/1.3.41 appears to be outdated (current is at least Apache/2.2.9). Apache 1.3.39 and 2.0.61 are also current. Perhaps the line from db_outdated could be updated in a future release? Cheers, Zube