From kost at linux.hr Mon Oct 6 13:36:26 2008 From: kost at linux.hr (Vlatko Kosturjak) Date: Mon, 06 Oct 2008 13:36:26 +0200 Subject: [Openvas-plugins] Bunch of free nasl scripts In-Reply-To: <200809291141.32323.jan-oliver.wagner@intevation.de> References: <48DC16C1.3030400@linux.hr> <200809291141.32323.jan-oliver.wagner@intevation.de> Message-ID: <48E9F83A.9010401@linux.hr> >> 4check: it should be checked if they work at all. For example there is >> gentoo checks which might not work - can someone who is doing gentoo >> stuff check it? > Thomas did care for gentoo recently. Probably he could answer best here. Thomas, can you check them? >> depend-misc: these scripts depends on various nasl/inc files which are >> not free, but with relatively small effort they could be rewritten to >> not require commercial scripts, the scripts itself are free > I'd say: check them in. We have already a lot of such scripts in there. OK. I will check them in. For those scripts which depend on smb or something else, I will put comment #FIXME-depend-smb or similar, so we can quickly grep for them (in order to fix them). Also, I will change script_id to put them in 8NNNN tree. Anybody have different idea before I start testing and comitting to SVN? >> BTW David also pointed me to stillsecure nasl archive at: >> http://arachnids.stillsecure.com/SAT/scripts/OSSSA/GPL/released/OSSSA/scripts/ > there was already some discussion about this repository in the OpenVAS project - > I didn't found the emails at a quick glance though. Maybe it was at IRC or elsewhere > discussed. We talked on IRC about that. Here's direct link to that IRC conversation: http://www.linux.hr/openvas/archive/index.php?d=2008-09-26 Kost From meyer at strato-rz.de Mon Oct 6 15:48:08 2008 From: meyer at strato-rz.de (Michael Meyer) Date: Mon, 6 Oct 2008 15:48:08 +0200 Subject: [Openvas-plugins] Failed to find interface eth0 mentioned in /proc/net/route Message-ID: <20081006134808.GA3183@strato-rz.de> Hello, openvas30:/usr/lib64/openvas # openvas-nasl -X -t komma-nix.de /usr/lib64/openvas/plugins/smtpserver_detect.nasl Failed to find interface eth0 mentioned in /proc/net/route Failed to find interface eth0 mentioned in /proc/net/route Failed to find interface eth0 mentioned in /proc/net/route Speicherzugriffsfehler openvas30:/usr/lib64/openvas # cat /proc/net/route Iface Destination Gateway Flags RefCnt Use Metric Mask MTU Window IRTT eth0 00861AAC 00000000 0001 0 0 0 00FEFFFF 0 0 0 eth0 0000FEA9 00000000 0001 0 0 0 0000FFFF 0 0 0 lo 0000007F 00000000 0001 0 0 0 000000FF 0 0 0 eth0 00000000 01861AAC 0003 0 0 0 00000000 0 0 0 openvas30:/usr/lib64/openvas # ifconfig eth0 eth0 Protokoll:Ethernet Hardware Adresse 00:1B:C6:00:03:34 inet Adresse:172.26.134.205 Bcast:172.26.135.255 Maske:255.255.254.0 inet6 Adresse: fe80::21b:c6ff:fe00:334/64 G?ltigkeitsbereich:Verbindung UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:15528 errors:0 dropped:0 overruns:0 frame:0 TX packets:1756 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenl?nge:1000 RX bytes:1051638 (1.0 Mb) TX bytes:993431 (970.1 Kb) It`s an OpenSUSE 10.2 XenNode. ,--[ smtpserver_detect.nasl ] | send(socket:soctcp25, data:string("EHLO ",this_host(),"\r\n")); `---| This is the Part of the Plugin what activate the error from above. OpenVAS never shows results from smtpserver_detect.nasl unless i comment out the line above. Same Plugin on an identical Host (same Kernel, same Xen-Version, etc) are executed without any errors by nessus (/opt/nessus/bin/nasl -t komma-nix.de /tmp/smtpserver_detect.nasl). Any idea whats going wrong? Greetings Michael From lists at securityspace.com Wed Oct 8 21:18:32 2008 From: lists at securityspace.com (Thomas Reinke) Date: Wed, 08 Oct 2008 15:18:32 -0400 Subject: [Openvas-plugins] Bunch of free nasl scripts In-Reply-To: <48E9F83A.9010401@linux.hr> References: <48DC16C1.3030400@linux.hr> <200809291141.32323.jan-oliver.wagner@intevation.de> <48E9F83A.9010401@linux.hr> Message-ID: <48ED0788.8020401@securityspace.com> Vlatko Kosturjak wrote: >>> 4check: it should be checked if they work at all. For example there is >>> gentoo checks which might not work - can someone who is doing gentoo >>> stuff check it? >> Thomas did care for gentoo recently. Probably he could answer best here. > > Thomas, can you check them? There's one in there about gentoo - have made the necessary changes in it to get it to work with gather-package-nasl, and checked it in. Thomas From lists at securityspace.com Wed Oct 8 21:25:47 2008 From: lists at securityspace.com (Thomas Reinke) Date: Wed, 08 Oct 2008 15:25:47 -0400 Subject: [Openvas-plugins] RPM kb usage without distro checks? Message-ID: <48ED093B.1060802@securityspace.com> I've noticed a few scripts that are starting to use the RPM kb. Have these been verified to work on RPM based systems? The thing that tweaked when I looked over the code is the fact that when checking the RPM version number, there seems to be (in at least some cases) no checking what distribution one is on. RPMs are known to exist on RedHat, Fedora, Mandriva, TurboLinux, SuSE, Trustix (at least). I'm worried that these scripts might be written on the assumption that it is a RedHat system (with the RedHat numbering policy, backporting, etc.) and subsequently start tripping false on other distros. Note that the current gather-package-list.nasl DOES set the RPMs for each of the above distros. Just wondering. Thomas From jan-oliver.wagner at intevation.de Thu Oct 9 11:38:31 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Thu, 9 Oct 2008 11:38:31 +0200 Subject: [Openvas-plugins] RPM kb usage without distro checks? In-Reply-To: <48ED093B.1060802@securityspace.com> References: <48ED093B.1060802@securityspace.com> Message-ID: <200810091138.33211.jan-oliver.wagner@intevation.de> On Mittwoch, 8. Oktober 2008, Thomas Reinke wrote: > I've noticed a few scripts that are starting to use the > RPM kb. Have these been verified to work on RPM based > systems? The thing that tweaked when I looked over the > code is the fact that when checking the RPM version number, > there seems to be (in at least some cases) no checking > what distribution one is on. > > RPMs are known to exist on RedHat, Fedora, Mandriva, > TurboLinux, SuSE, Trustix (at least). > I'm worried that these scripts might be written on the > assumption that it is a RedHat system (with the RedHat > numbering policy, backporting, etc.) and subsequently > start tripping false on other distros. > > Note that the current gather-package-list.nasl DOES set the RPMs > for each of the above distros. I'd appreciate if anyone could eventually document the KB and NASL-API for such very often used base functioanlities in the OpenVAS compendium. Perhaps not just in the form of a reference, but also in form of a guide. Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Mon Oct 13 14:02:31 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Mon, 13 Oct 2008 14:02:31 +0200 Subject: [Openvas-plugins] OpenVAS Contest closes soon Message-ID: <200810131402.33840.jan-oliver.wagner@intevation.de> Hello, the OpenVAS Contest[1] "Best Advances for OpenVAS Network Vulnerability Tests" closes soon (Oct. 15th). Because it appeared to be a bit unclear, I'd underline that anyone who contributed and is not a sponsor(-member) should be considered for the award :-) From Oct. 16th on the OpenVAS steering comittee and the sponsors will start to review the contributions. On Oct. 30th winners are announced. So, anyone who still has something in the queue, commit it or send to the mailing lists. Best Jan [1] http://www.openvas.org/openvas-contest.html -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From madhat at unspecific.com Wed Oct 15 20:56:59 2008 From: madhat at unspecific.com (MadHat Unspecific) Date: Wed, 15 Oct 2008 13:56:59 -0500 Subject: [Openvas-plugins] Plugin WishList Message-ID: <48F63CFB.5020005@unspecific.com> I am looking to start working on some plugins for openvas. I have been chatting on IRC and looking at old list archives and was pointed to http://lists.wald.intevation.org/pipermail/openvas-plugins/2008-September/000098.html I am looking for guidance on what people would like to see done. I know there are several _detect plugins that are not overly complicated that I can reproduce in short order, but I would like to know what people would find most useful. Thanks -- MadHat (at) Unspecific.com "The true man wants two things: danger and play. For that reason he wants woman, as the most dangerous plaything." - Friedrich Nietzsche From madhat at unspecific.com Thu Oct 16 20:18:01 2008 From: madhat at unspecific.com (MadHat Unspecific) Date: Thu, 16 Oct 2008 13:18:01 -0500 Subject: [Openvas-plugins] subversion_detect.nasl Message-ID: <48F78559.1040202@unspecific.com> Just randomly choosing a plugin to rewrite, here is what I came up with. Nothing here was taking from the Tenable plugin. I left the ID blank as I didn't know if it should be a new ID or use the Tenable subversion_detect ID (not what I would expect). I did some basic testing, but please let me know if this does not work. Thanks -- MadHat (at) Unspecific.com "The true man wants two things: danger and play. For that reason he wants woman, as the most dangerous plaything." - Friedrich Nietzsche -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: subversion_detect.nasl Url: http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20081016/726ea943/subversion_detect.asc From lists at securityspace.com Thu Oct 16 20:38:19 2008 From: lists at securityspace.com (Thomas Reinke) Date: Thu, 16 Oct 2008 14:38:19 -0400 Subject: [Openvas-plugins] subversion_detect.nasl In-Reply-To: <48F78559.1040202@unspecific.com> References: <48F78559.1040202@unspecific.com> Message-ID: <48F78A1B.2060606@securityspace.com> Couple notes, If you do make a script that checks for a new type of service, the script itself should make a call to register_service, e.g. register_service(port:port, proto:"subversion"); In this case, there seems to be some GPLed missing scripts that already do what you've done. Specifically, find_service2.nasl was definitely in the GPL feed, was labelled as GPL post feed changes by Tenable, and afaict should be in OpenVAS. Anyone know why this plugin wasn't committed? Thomas MadHat Unspecific wrote: > Just randomly choosing a plugin to rewrite, here is what I came up with. > Nothing here was taking from the Tenable plugin. I left the ID blank > as I didn't know if it should be a new ID or use the Tenable > subversion_detect ID (not what I would expect). I did some basic > testing, but please let me know if this does not work. > > Thanks > > > ------------------------------------------------------------------------ > > # > # This script was written by MadHat Unspecific > # > # GPL > # > > if(description) > { > script_id(); > script_version ("$Revision: 1 $"); > > script_name(english:"Subversion detection"); > > desc["english"] = "Subversion is running on this host. > > Subversion (SVN) is an open source version control system initiated in > 2000 by CollabNet Inc. It is used to maintain current and historical > versions of files such as source code, web pages, and documentation. > Its goal is to be a mostly-compatible successor to the widely used > Concurrent Versions System (CVS). > > Ref: http://subversion.tigris.org/ > Ref: http://en.wikipedia.org/wiki/Subversion_(software) > > Risk factor : None / Low"; > > script_description(english:desc["english"]); > > summary["english"] = "Detect Subversion server"; > script_summary(english:summary["english"]); > > script_category(ACT_GATHER_INFO); > > script_copyright(english:"This script is Copyright (C) 2008 MadHat Unspecific"); > family["english"] = "General"; > script_family(english:family["english"]); > script_require_ports("Services/subversion", 3690); > exit(0); > } > > port = get_kb_item("Services/subversion"); > if (! port) port = 3690; > > if(!get_port_state(port))exit(0); > > sochand = open_sock_tcp(port); > if (!sochand) exit(0); > > read = recv_line(socket:sochand, length:32); > > if (ereg(pattern:'^\\( success \\( [0-9] [0-9] \\( ANONYMOUS \\) \\( ', string:read)) > { > security_note(port); > } > close(sochand); > exit(0); > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Openvas-plugins mailing list > Openvas-plugins at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins From lists at securityspace.com Thu Oct 16 20:41:25 2008 From: lists at securityspace.com (Thomas Reinke) Date: Thu, 16 Oct 2008 14:41:25 -0400 Subject: [Openvas-plugins] subversion_detect.nasl In-Reply-To: <48F78A1B.2060606@securityspace.com> References: <48F78559.1040202@unspecific.com> <48F78A1B.2060606@securityspace.com> Message-ID: <48F78AD5.8040200@securityspace.com> Blech...me and my typos. The file IS committed. Please check find_service2.nasl, which already does what you are proposing. Thomas Thomas Reinke wrote: > Couple notes, > > If you do make a script that checks for a new type of service, > the script itself should make a call to register_service, > > e.g. register_service(port:port, proto:"subversion"); > > In this case, there seems to be some GPLed missing scripts > that already do what you've done. Specifically, > find_service2.nasl was definitely in the GPL feed, was > labelled as GPL post feed changes by Tenable, and afaict > should be in OpenVAS. > > Anyone know why this plugin wasn't committed? > > Thomas > > MadHat Unspecific wrote: >> Just randomly choosing a plugin to rewrite, here is what I came up with. >> Nothing here was taking from the Tenable plugin. I left the ID blank >> as I didn't know if it should be a new ID or use the Tenable >> subversion_detect ID (not what I would expect). I did some basic >> testing, but please let me know if this does not work. >> >> Thanks >> >> >> ------------------------------------------------------------------------ >> >> # >> # This script was written by MadHat Unspecific >> # >> # GPL >> # >> >> if(description) >> { >> script_id(); >> script_version ("$Revision: 1 $"); >> >> script_name(english:"Subversion detection"); >> >> desc["english"] = "Subversion is running on this host. >> >> Subversion (SVN) is an open source version control system initiated in >> 2000 by CollabNet Inc. It is used to maintain current and historical >> versions of files such as source code, web pages, and documentation. >> Its goal is to be a mostly-compatible successor to the widely used >> Concurrent Versions System (CVS). >> >> Ref: http://subversion.tigris.org/ >> Ref: http://en.wikipedia.org/wiki/Subversion_(software) >> >> Risk factor : None / Low"; >> >> script_description(english:desc["english"]); >> >> summary["english"] = "Detect Subversion server"; >> script_summary(english:summary["english"]); >> >> script_category(ACT_GATHER_INFO); >> >> script_copyright(english:"This script is Copyright (C) 2008 MadHat Unspecific"); >> family["english"] = "General"; >> script_family(english:family["english"]); >> script_require_ports("Services/subversion", 3690); >> exit(0); >> } >> >> port = get_kb_item("Services/subversion"); >> if (! port) port = 3690; >> >> if(!get_port_state(port))exit(0); >> >> sochand = open_sock_tcp(port); >> if (!sochand) exit(0); >> >> read = recv_line(socket:sochand, length:32); >> >> if (ereg(pattern:'^\\( success \\( [0-9] [0-9] \\( ANONYMOUS \\) \\( ', string:read)) >> { >> security_note(port); >> } >> close(sochand); >> exit(0); >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Openvas-plugins mailing list >> Openvas-plugins at wald.intevation.org >> http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins > > _______________________________________________ > Openvas-plugins mailing list > Openvas-plugins at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins > From madhat at unspecific.com Thu Oct 16 20:50:50 2008 From: madhat at unspecific.com (MadHat Unspecific) Date: Thu, 16 Oct 2008 13:50:50 -0500 Subject: [Openvas-plugins] subversion_detect.nasl In-Reply-To: <48F78AD5.8040200@securityspace.com> References: <48F78559.1040202@unspecific.com> <48F78A1B.2060606@securityspace.com> <48F78AD5.8040200@securityspace.com> Message-ID: <48F78D0A.7070707@unspecific.com> I pulled the script from the list posted here a while back (month ago) and I even asked yesterday for a wish list, referencing the orig email. http://lists.wald.intevation.org/pipermail/openvas-plugins/2008-September/000098.html As for the register_service I will make sure to look into it. Thomas Reinke wrote: > Blech...me and my typos. The file IS committed. > > Please check find_service2.nasl, which already > does what you are proposing. > > Thomas > > Thomas Reinke wrote: >> Couple notes, >> >> If you do make a script that checks for a new type of service, >> the script itself should make a call to register_service, >> >> e.g. register_service(port:port, proto:"subversion"); >> >> In this case, there seems to be some GPLed missing scripts >> that already do what you've done. Specifically, >> find_service2.nasl was definitely in the GPL feed, was >> labelled as GPL post feed changes by Tenable, and afaict >> should be in OpenVAS. >> >> Anyone know why this plugin wasn't committed? >> >> Thomas >> >> MadHat Unspecific wrote: >>> Just randomly choosing a plugin to rewrite, here is what I came up with. >>> Nothing here was taking from the Tenable plugin. I left the ID blank >>> as I didn't know if it should be a new ID or use the Tenable >>> subversion_detect ID (not what I would expect). I did some basic >>> testing, but please let me know if this does not work. >>> >>> Thanks >>> >>> >>> ------------------------------------------------------------------------ >>> >>> # >>> # This script was written by MadHat Unspecific >>> # >>> # GPL >>> # >>> >>> if(description) >>> { >>> script_id(); >>> script_version ("$Revision: 1 $"); >>> >>> script_name(english:"Subversion detection"); >>> >>> desc["english"] = "Subversion is running on this host. >>> >>> Subversion (SVN) is an open source version control system initiated in >>> 2000 by CollabNet Inc. It is used to maintain current and historical >>> versions of files such as source code, web pages, and documentation. >>> Its goal is to be a mostly-compatible successor to the widely used >>> Concurrent Versions System (CVS). >>> >>> Ref: http://subversion.tigris.org/ >>> Ref: http://en.wikipedia.org/wiki/Subversion_(software) >>> >>> Risk factor : None / Low"; >>> >>> script_description(english:desc["english"]); >>> >>> summary["english"] = "Detect Subversion server"; >>> script_summary(english:summary["english"]); >>> >>> script_category(ACT_GATHER_INFO); >>> >>> script_copyright(english:"This script is Copyright (C) 2008 MadHat Unspecific"); >>> family["english"] = "General"; >>> script_family(english:family["english"]); >>> script_require_ports("Services/subversion", 3690); >>> exit(0); >>> } >>> >>> port = get_kb_item("Services/subversion"); >>> if (! port) port = 3690; >>> >>> if(!get_port_state(port))exit(0); >>> >>> sochand = open_sock_tcp(port); >>> if (!sochand) exit(0); >>> >>> read = recv_line(socket:sochand, length:32); >>> >>> if (ereg(pattern:'^\\( success \\( [0-9] [0-9] \\( ANONYMOUS \\) \\( ', string:read)) >>> { >>> security_note(port); >>> } >>> close(sochand); >>> exit(0); >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Openvas-plugins mailing list >>> Openvas-plugins at wald.intevation.org >>> http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins >> _______________________________________________ >> Openvas-plugins mailing list >> Openvas-plugins at wald.intevation.org >> http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins >> > > _______________________________________________ > Openvas-plugins mailing list > Openvas-plugins at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins -- MadHat (at) Unspecific.com "The true man wants two things: danger and play. For that reason he wants woman, as the most dangerous plaything." - Friedrich Nietzsche From madhat at unspecific.com Thu Oct 16 20:58:33 2008 From: madhat at unspecific.com (MadHat Unspecific) Date: Thu, 16 Oct 2008 13:58:33 -0500 Subject: [Openvas-plugins] subversion_detect.nasl In-Reply-To: <48F78AD5.8040200@securityspace.com> References: <48F78559.1040202@unspecific.com> <48F78A1B.2060606@securityspace.com> <48F78AD5.8040200@securityspace.com> Message-ID: <48F78ED9.9020303@unspecific.com> Also, at least 3 plugins (subversion_1_0_5.nasl, subversion_1_0_6.nasl, subversion_1_0_8.nasl) require subversion_detect.nasl, so someone may want to update those to require find_services2.nasl instead. Thomas Reinke wrote: > Blech...me and my typos. The file IS committed. > > Please check find_service2.nasl, which already > does what you are proposing. > > Thomas > > Thomas Reinke wrote: >> Couple notes, >> >> If you do make a script that checks for a new type of service, >> the script itself should make a call to register_service, >> >> e.g. register_service(port:port, proto:"subversion"); >> >> In this case, there seems to be some GPLed missing scripts >> that already do what you've done. Specifically, >> find_service2.nasl was definitely in the GPL feed, was >> labelled as GPL post feed changes by Tenable, and afaict >> should be in OpenVAS. >> >> Anyone know why this plugin wasn't committed? >> >> Thomas >> >> MadHat Unspecific wrote: >>> Just randomly choosing a plugin to rewrite, here is what I came up with. >>> Nothing here was taking from the Tenable plugin. I left the ID blank >>> as I didn't know if it should be a new ID or use the Tenable >>> subversion_detect ID (not what I would expect). I did some basic >>> testing, but please let me know if this does not work. >>> >>> Thanks >>> -- MadHat (at) Unspecific.com "The true man wants two things: danger and play. For that reason he wants woman, as the most dangerous plaything." - Friedrich Nietzsche From lists at securityspace.com Thu Oct 16 21:43:22 2008 From: lists at securityspace.com (Thomas Reinke) Date: Thu, 16 Oct 2008 15:43:22 -0400 Subject: [Openvas-plugins] subversion_detect.nasl In-Reply-To: <48F78ED9.9020303@unspecific.com> References: <48F78559.1040202@unspecific.com> <48F78A1B.2060606@securityspace.com> <48F78AD5.8040200@securityspace.com> <48F78ED9.9020303@unspecific.com> Message-ID: <48F7995A.8050309@securityspace.com> Updates to these scripts have now been committed, Thanks for pointing that out. Thomas MadHat Unspecific wrote: > Also, at least 3 plugins (subversion_1_0_5.nasl, subversion_1_0_6.nasl, > subversion_1_0_8.nasl) require subversion_detect.nasl, so someone may > want to update those to require find_services2.nasl instead. > > Thomas Reinke wrote: >> Blech...me and my typos. The file IS committed. >> >> Please check find_service2.nasl, which already >> does what you are proposing. >> >> Thomas >> >> Thomas Reinke wrote: >>> Couple notes, >>> >>> If you do make a script that checks for a new type of service, >>> the script itself should make a call to register_service, >>> >>> e.g. register_service(port:port, proto:"subversion"); >>> >>> In this case, there seems to be some GPLed missing scripts >>> that already do what you've done. Specifically, >>> find_service2.nasl was definitely in the GPL feed, was >>> labelled as GPL post feed changes by Tenable, and afaict >>> should be in OpenVAS. >>> >>> Anyone know why this plugin wasn't committed? >>> >>> Thomas >>> >>> MadHat Unspecific wrote: >>>> Just randomly choosing a plugin to rewrite, here is what I came up >>>> with. >>>> Nothing here was taking from the Tenable plugin. I left the ID blank >>>> as I didn't know if it should be a new ID or use the Tenable >>>> subversion_detect ID (not what I would expect). I did some basic >>>> testing, but please let me know if this does not work. >>>> >>>> Thanks >>>> > > From timb at nth-dimension.org.uk Thu Oct 16 22:14:58 2008 From: timb at nth-dimension.org.uk (Tim Brown) Date: Thu, 16 Oct 2008 21:14:58 +0100 Subject: [Openvas-plugins] subversion_detect.nasl In-Reply-To: <48F78A1B.2060606@securityspace.com> References: <48F78559.1040202@unspecific.com> <48F78A1B.2060606@securityspace.com> Message-ID: <200810162114.58480.timb@nth-dimension.org.uk> On Thursday 16 October 2008 19:38:19 Thomas Reinke wrote: > Couple notes, > > If you do make a script that checks for a new type of service, > the script itself should make a call to register_service, > > e.g. register_service(port:port, proto:"subversion"); Thomas, in your opinion should ike-scan.nasl call this in addition/or instead of scanner_add_port(). Bare in mind that this plugin identifies itself as a scanner right now: ... script_category(ACT_SCANNER); family["english"] = "Port scanners"; ... Cheers, Tim -- Tim Brown From lists at securityspace.com Thu Oct 16 22:32:43 2008 From: lists at securityspace.com (Thomas Reinke) Date: Thu, 16 Oct 2008 16:32:43 -0400 Subject: [Openvas-plugins] subversion_detect.nasl In-Reply-To: <48F78D0A.7070707@unspecific.com> References: <48F78559.1040202@unspecific.com> <48F78A1B.2060606@securityspace.com> <48F78AD5.8040200@securityspace.com> <48F78D0A.7070707@unspecific.com> Message-ID: <48F7A4EB.8090409@securityspace.com> MadHat Unspecific wrote: > I pulled the script from the list posted here a while back (month ago) > and I even asked yesterday for a wish list, referencing the orig email. > http://lists.wald.intevation.org/pipermail/openvas-plugins/2008-September/000098.html > > > As for the register_service I will make sure to look into it. > Fair enough. The one script that I know (from experience) can be used as a leverage point for a significant number of other scripts would be a webmirror.nasl equivalent. The value there lies specifically in finding and recording URLs and directories into the kb. In addition, we've found that it then becomes _very_ simple to extend this to detect additional web packages that might be installed on a system (and not always in a fixed location) by looking for various web page "fingerprints" (e.g. "Powered by Product version X") Thomas From lists at securityspace.com Thu Oct 16 22:49:30 2008 From: lists at securityspace.com (Thomas Reinke) Date: Thu, 16 Oct 2008 16:49:30 -0400 Subject: [Openvas-plugins] subversion_detect.nasl In-Reply-To: <200810162114.58480.timb@nth-dimension.org.uk> References: <48F78559.1040202@unspecific.com> <48F78A1B.2060606@securityspace.com> <200810162114.58480.timb@nth-dimension.org.uk> Message-ID: <48F7A8DA.3050602@securityspace.com> Not sure that I know _all_ of the ramifications, but I suspect probably both would be appropriate. First to list the port as being open, the second to list it as a VPN endpoint in case any other scripts want to have a quick list of any known VPN end points for testing subsequent issues. I'm not aware of any restrictions or impact on calling either of these functions during the ACT_SCANNER phase of a scan. Thomas Tim Brown wrote: > On Thursday 16 October 2008 19:38:19 Thomas Reinke wrote: >> Couple notes, >> >> If you do make a script that checks for a new type of service, >> the script itself should make a call to register_service, >> >> e.g. register_service(port:port, proto:"subversion"); > > Thomas, in your opinion should ike-scan.nasl call this in addition/or instead > of scanner_add_port(). Bare in mind that this plugin identifies itself as a > scanner right now: > > ... > script_category(ACT_SCANNER); > family["english"] = "Port scanners"; > ... > > Cheers, > Tim From timb at nth-dimension.org.uk Thu Oct 16 22:50:31 2008 From: timb at nth-dimension.org.uk (Tim Brown) Date: Thu, 16 Oct 2008 21:50:31 +0100 Subject: [Openvas-plugins] subversion_detect.nasl In-Reply-To: <48F7A4EB.8090409@securityspace.com> References: <48F78559.1040202@unspecific.com> <48F78D0A.7070707@unspecific.com> <48F7A4EB.8090409@securityspace.com> Message-ID: <200810162150.32011.timb@nth-dimension.org.uk> On Thursday 16 October 2008 21:32:43 Thomas Reinke wrote: > The value there lies specifically in finding and recording > URLs and directories into the kb. In addition, we've > found that it then becomes _very_ simple to extend > this to detect additional web packages that might be > installed on a system (and not always in a fixed location) > by looking for various web page "fingerprints" (e.g. > "Powered by Product version X") I'd second that, it would be a most excellent addition. Cheers, Tim -- Tim Brown From madhat at unspecific.com Thu Oct 16 22:59:50 2008 From: madhat at unspecific.com (MadHat Unspecific) Date: Thu, 16 Oct 2008 15:59:50 -0500 Subject: [Openvas-plugins] subversion_detect.nasl In-Reply-To: <48F7A4EB.8090409@securityspace.com> References: <48F78559.1040202@unspecific.com> <48F78A1B.2060606@securityspace.com> <48F78AD5.8040200@securityspace.com> <48F78D0A.7070707@unspecific.com> <48F7A4EB.8090409@securityspace.com> Message-ID: <48F7AB46.3030304@unspecific.com> Thomas Reinke wrote: > > The one script that I know (from experience) can be used > as a leverage point for a significant number of other > scripts would be a webmirror.nasl equivalent. > > The value there lies specifically in finding and recording > URLs and directories into the kb. In addition, we've > found that it then becomes _very_ simple to extend > this to detect additional web packages that might be > installed on a system (and not always in a fixed location) > by looking for various web page "fingerprints" (e.g. > "Powered by Product version X") > Well now... that is not a trivial script. I'll start digging through it and see what I can come up with. -- MadHat (at) Unspecific.com "The true man wants two things: danger and play. For that reason he wants woman, as the most dangerous plaything." - Friedrich Nietzsche From lists at securityspace.com Thu Oct 16 23:57:34 2008 From: lists at securityspace.com (Thomas Reinke) Date: Thu, 16 Oct 2008 17:57:34 -0400 Subject: [Openvas-plugins] subversion_detect.nasl In-Reply-To: <48F7AB46.3030304@unspecific.com> References: <48F78559.1040202@unspecific.com> <48F78A1B.2060606@securityspace.com> <48F78AD5.8040200@securityspace.com> <48F78D0A.7070707@unspecific.com> <48F7A4EB.8090409@securityspace.com> <48F7AB46.3030304@unspecific.com> Message-ID: <48F7B8CE.2050600@securityspace.com> > Well now... that is not a trivial script. Hence being on the wish list ;-) Thomas From jan-oliver.wagner at intevation.de Fri Oct 17 08:58:25 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Fri, 17 Oct 2008 08:58:25 +0200 Subject: [Openvas-plugins] Plugin WishList In-Reply-To: <48F63CFB.5020005@unspecific.com> References: <48F63CFB.5020005@unspecific.com> Message-ID: <200810170858.27692.jan-oliver.wagner@intevation.de> On Mittwoch, 15. Oktober 2008, MadHat Unspecific wrote: > I am looking to start working on some plugins for openvas. I have been > chatting on IRC and looking at old list archives and was pointed to > http://lists.wald.intevation.org/pipermail/openvas-plugins/2008-September/000098.html > > I am looking for guidance on what people would like to see done. I know > there are several _detect plugins that are not overly complicated that I > can reproduce in short order, but I would like to know what people would > find most useful. first thanks for your offer to work on this! There are two major rules how to do this: * Don't even look at the proprietary scripts by Tenable! * Coordinate with the other developers to avoid that two people work on the same thing. This list is the best place for this. Simply tell us which one you like to start on. Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From kost at linux.hr Fri Oct 17 10:44:14 2008 From: kost at linux.hr (Vlatko Kosturjak) Date: Fri, 17 Oct 2008 10:44:14 +0200 Subject: [Openvas-plugins] subversion_detect.nasl In-Reply-To: <48F78559.1040202@unspecific.com> References: <48F78559.1040202@unspecific.com> Message-ID: <48F8505E.3080909@linux.hr> MadHat Unspecific wrote: > Just randomly choosing a plugin to rewrite, here is what I came up with. Thanks for your contribution! > Nothing here was taking from the Tenable plugin. I left the ID blank > as I didn't know if it should be a new ID or use the Tenable > subversion_detect ID (not what I would expect). I did some basic > testing, but please let me know if this does not work. Just send script with blank ID and I'll take it and put in 8NNNN contributions tree. Next time when you contribute script, please specify which version of GPL (GPL v2 or later or something else). As other said, it seems your subversion detection is already implemented in find_service2.nasl. I just checked that service detection in find_service2.nasl and it seems it doesn't work in all cases as well as your script. I tried against my friend's SVN and this is what that SVN spits out: $ nc svn.rot13.org 3690 ( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries commit-revprops depth log-revprops partial-replay ) ) ) So, I changed line to (in find_service2.nasl): if (r=~ '^\\( success \\( [0-9] [0-9] \\(.*\\) \\(.*') Is there anyone who is willing to test against their Subversion installations? Thanks in advance, Kost From kost at linux.hr Fri Oct 17 10:56:00 2008 From: kost at linux.hr (Vlatko Kosturjak) Date: Fri, 17 Oct 2008 10:56:00 +0200 Subject: [Openvas-plugins] subversion_detect.nasl In-Reply-To: <48F78AD5.8040200@securityspace.com> References: <48F78559.1040202@unspecific.com> <48F78A1B.2060606@securityspace.com> <48F78AD5.8040200@securityspace.com> Message-ID: <48F85320.60705@linux.hr> Thomas Reinke wrote: > Blech...me and my typos. The file IS committed. > > Please check find_service2.nasl, which already > does what you are proposing. Maybe subversion_detect.nasl would be useful, but in different context i.e. that script could try to enumerate default repository names (/code /svn /rep etc...) Kost From madhat at unspecific.com Fri Oct 17 16:42:38 2008 From: madhat at unspecific.com (MadHat Unspecific) Date: Fri, 17 Oct 2008 09:42:38 -0500 Subject: [Openvas-plugins] subversion_detect.nasl In-Reply-To: <48F8505E.3080909@linux.hr> References: <48F78559.1040202@unspecific.com> <48F8505E.3080909@linux.hr> Message-ID: <48F8A45E.2090505@unspecific.com> Vlatko Kosturjak wrote: > MadHat Unspecific wrote: >> Just randomly choosing a plugin to rewrite, here is what I came up with. > > Thanks for your contribution! > >> Nothing here was taking from the Tenable plugin. I left the ID blank >> as I didn't know if it should be a new ID or use the Tenable >> subversion_detect ID (not what I would expect). I did some basic >> testing, but please let me know if this does not work. > > Just send script with blank ID and I'll take it and put in 8NNNN > contributions tree. > > Next time when you contribute script, please specify which version of > GPL (GPL v2 or later or something else). I really don't care. I am not intimately familiar with the differences in the 2 and to me it is a moot point. Set it to the same thing OpenVAS is using and move on. > > As other said, it seems your subversion detection is already implemented > in find_service2.nasl. I just checked that service detection in > find_service2.nasl and it seems it doesn't work in all cases as well as > your script. I tried against my friend's SVN and this is what that SVN > spits out: > $ nc svn.rot13.org 3690 > ( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries > commit-revprops depth log-revprops partial-replay ) ) ) > > So, I changed line to (in find_service2.nasl): > if (r=~ '^\\( success \\( [0-9] [0-9] \\(.*\\) \\(.*') > > Is there anyone who is willing to test against their Subversion > installations? I was going to point that out. The 2 digits will not always be 1 and 2, but I am not sure the exact specs in subversion. -- MadHat (at) Unspecific.com "The true man wants two things: danger and play. For that reason he wants woman, as the most dangerous plaything." - Friedrich Nietzsche From madhat at unspecific.com Fri Oct 17 16:52:58 2008 From: madhat at unspecific.com (MadHat Unspecific) Date: Fri, 17 Oct 2008 09:52:58 -0500 Subject: [Openvas-plugins] Plugin WishList In-Reply-To: <200810170858.27692.jan-oliver.wagner@intevation.de> References: <48F63CFB.5020005@unspecific.com> <200810170858.27692.jan-oliver.wagner@intevation.de> Message-ID: <48F8A6CA.2030606@unspecific.com> Jan-Oliver Wagner wrote: > On Mittwoch, 15. Oktober 2008, MadHat Unspecific wrote: >> I am looking to start working on some plugins for openvas. I have been >> chatting on IRC and looking at old list archives and was pointed to >> http://lists.wald.intevation.org/pipermail/openvas-plugins/2008-September/000098.html >> >> I am looking for guidance on what people would like to see done. I know >> there are several _detect plugins that are not overly complicated that I >> can reproduce in short order, but I would like to know what people would >> find most useful. > > first thanks for your offer to work on this! > > There are two major rules how to do this: > > * Don't even look at the proprietary scripts by Tenable! Not possible. Since I am looking at filling in the gaps where needed and several of these scripts are needed as dependencies by existing scripts already being used in OpenVAS, I have to know what variables are being set. I understand that the code can not be used, but I have to know what is expected and I don't see a way of doing that without at least a cursory look at the Tenable scripts. > > * Coordinate with the other developers to avoid that two > people work on the same thing. > This list is the best place for this. > Simply tell us which one you like to start on. The request yesterday was for webmirror.nasl. Being very familiar with the HTTP protocol and writing scripts to do checks (though in perl), I will be working on it. If there is an issue with this, please let me know as soon as you can, so I don't waste any time. Also this is a perfect example of where I have to look at the tenable script to see what it actually does, but I know not to use any code, wording, or anything that could be construed as being taken directly from the tenable script. -- MadHat (at) Unspecific.com "The true man wants two things: danger and play. For that reason he wants woman, as the most dangerous plaything." - Friedrich Nietzsche From madhat at unspecific.com Fri Oct 17 17:15:24 2008 From: madhat at unspecific.com (MadHat Unspecific) Date: Fri, 17 Oct 2008 10:15:24 -0500 Subject: [Openvas-plugins] subversion_detect.nasl In-Reply-To: <48F7A4EB.8090409@securityspace.com> References: <48F78559.1040202@unspecific.com> <48F78A1B.2060606@securityspace.com> <48F78AD5.8040200@securityspace.com> <48F78D0A.7070707@unspecific.com> <48F7A4EB.8090409@securityspace.com> Message-ID: <48F8AC0C.7010402@unspecific.com> Thomas Reinke wrote: > > Fair enough. > > The one script that I know (from experience) can be used > as a leverage point for a significant number of other > scripts would be a webmirror.nasl equivalent. OK, let's try this a little bit differently. What would be the first functionality you would like to see implemented? The Tenable script does a lot in a single script and sets several KB variables. What would you find most useful? -- MadHat (at) Unspecific.com "The true man wants two things: danger and play. For that reason he wants woman, as the most dangerous plaything." - Friedrich Nietzsche From lists at securityspace.com Fri Oct 17 18:10:32 2008 From: lists at securityspace.com (Thomas Reinke) Date: Fri, 17 Oct 2008 12:10:32 -0400 Subject: [Openvas-plugins] subversion_detect.nasl In-Reply-To: <48F8AC0C.7010402@unspecific.com> References: <48F78559.1040202@unspecific.com> <48F78A1B.2060606@securityspace.com> <48F78AD5.8040200@securityspace.com> <48F78D0A.7070707@unspecific.com> <48F7A4EB.8090409@securityspace.com> <48F8AC0C.7010402@unspecific.com> Message-ID: <48F8B8F8.1030109@securityspace.com> MadHat Unspecific wrote: > Thomas Reinke wrote: >> >> Fair enough. >> >> The one script that I know (from experience) can be used >> as a leverage point for a significant number of other >> scripts would be a webmirror.nasl equivalent. > > > OK, let's try this a little bit differently. What would be the first > functionality you would like to see implemented? The Tenable script > does a lot in a single script and sets several KB variables. What would > you find most useful? > > The sheer ability to crawl a web site, recording all directories that are found. The kb entry set should be "www//content/directories" A lot of scripts require this kb entry. Rational: a) Many scripts require the above kb entry b) Many additional tests can be added to the system easily by later on extending the webmirror.nasl capability. Thomas From madhat at unspecific.com Fri Oct 17 18:31:22 2008 From: madhat at unspecific.com (MadHat Unspecific) Date: Fri, 17 Oct 2008 11:31:22 -0500 Subject: [Openvas-plugins] ldap_detect.nasl Message-ID: <48F8BDDA.1040808@unspecific.com> While waiting on feedback from the webmirror script, I threw this together. It is not complete from my standards, but will detect LDAP. I can add more to be more specific about what version of LDAP is supported. Feedback is welcome. Again I don't care which GPL is used. Here are my notes (thanks wireshark) from working on this. LDAP Simple Bind Request (version3): 0000 30 0c 02 01 01 60 07 02 01 03 04 00 80 00 LDAP Simple Bind Request (version2): 0000 30 0c 02 01 01 60 07 02 01 02 04 00 80 00 Byte 00 always 30 from testing. Success: 0000 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 Byte 04 Message ID (01) Byte 05 ProtocolOp: bindResponse (1) Byte 07 bindResponse (0a 01) Byte 09 resultCode: success (0) Success: 0000 30 84 00 00 00 10 02 01 01 61 84 00 00 00 07 0a 0010 01 00 04 00 04 00 Byte 08 Message ID (01) Byte 09 ProtocolOp: bindResponse (1) Byte 15 bindResponse (0a 01) Byte 17 resultCode: success (0) Success: 0000 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 Byte 04 Message ID (01) Byte 05 ProtocolOp: bindResponse (1) Byte 07 bindResponse (0a 01) Byte 09 resultCode: success (0) Protocol not Supported: 0000 30 21 02 01 01 61 1c 0a 01 02 04 00 04 15 76 65 0010 72 73 69 6f 6e 20 6e 6f 74 20 73 75 70 70 6f 72 0020 74 65 64 Byte 04 Message ID (01) Byte 05 protocolOp: bindResponse (1) Byte 07 bindResponse (0a 01) Byte 09 resultCode: protocolError (02) Byte 14 errorMessage: version not supported -- MadHat (at) Unspecific.com "The true man wants two things: danger and play. For that reason he wants woman, as the most dangerous plaything." - Friedrich Nietzsche -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ldap_detect.nasl Url: http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20081017/8c3f5a91/ldap_detect.asc From madhat at unspecific.com Fri Oct 17 18:41:44 2008 From: madhat at unspecific.com (MadHat Unspecific) Date: Fri, 17 Oct 2008 11:41:44 -0500 Subject: [Openvas-plugins] ldap_detect.nasl In-Reply-To: <48F8BDDA.1040808@unspecific.com> References: <48F8BDDA.1040808@unspecific.com> Message-ID: <48F8C048.8010408@unspecific.com> Hi, I am a tard.... I copied this over to another box to test and I forgot to change something... slap me later. yeah, sorry. Here is the one without that bad line. -- MadHat (at) Unspecific.com "The true man wants two things: danger and play. For that reason he wants woman, as the most dangerous plaything." - Friedrich Nietzsche -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ldap_detect.nasl Url: http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20081017/cbb107b5/ldap_detect.pot From madhat at unspecific.com Fri Oct 17 19:42:05 2008 From: madhat at unspecific.com (MadHat Unspecific) Date: Fri, 17 Oct 2008 12:42:05 -0500 Subject: [Openvas-plugins] ldap_detect.nasl In-Reply-To: <48F8C048.8010408@unspecific.com> References: <48F8BDDA.1040808@unspecific.com> <48F8C048.8010408@unspecific.com> Message-ID: <48F8CE6D.8060606@unspecific.com> Just scratch the whole thing. I screwed up in a lot of ways. I'll get back to you on this. /me bangs his head against the wall -- MadHat (at) Unspecific.com "The true man wants two things: danger and play. For that reason he wants woman, as the most dangerous plaything." - Friedrich Nietzsche From madhat at unspecific.com Fri Oct 17 19:43:46 2008 From: madhat at unspecific.com (MadHat Unspecific) Date: Fri, 17 Oct 2008 12:43:46 -0500 Subject: [Openvas-plugins] ldap_detect.nasl In-Reply-To: <48F8C048.8010408@unspecific.com> References: <48F8BDDA.1040808@unspecific.com> <48F8C048.8010408@unspecific.com> Message-ID: <48F8CED2.9020102@unspecific.com> Just scratch the whole thing. I screwed up in a lot of ways. I'll get back to you on this. /me bangs his head against the wall -- MadHat (at) Unspecific.com "The true man wants two things: danger and play. For that reason he wants woman, as the most dangerous plaything." - Friedrich Nietzsche From madhat at unspecific.com Fri Oct 17 19:45:22 2008 From: madhat at unspecific.com (MadHat Unspecific) Date: Fri, 17 Oct 2008 12:45:22 -0500 Subject: [Openvas-plugins] ldap_detect.nasl In-Reply-To: <48F8C048.8010408@unspecific.com> References: <48F8BDDA.1040808@unspecific.com> <48F8C048.8010408@unspecific.com> Message-ID: <48F8CF32.6040504@unspecific.com> Just scratch the whole thing. I screwed up in a lot of ways. I'll get back to you on this. /me bangs his head against the wall -- MadHat (at) Unspecific.com "The true man wants two things: danger and play. For that reason he wants woman, as the most dangerous plaything." - Friedrich Nietzsche From jan-oliver.wagner at intevation.de Fri Oct 17 21:07:55 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Fri, 17 Oct 2008 21:07:55 +0200 Subject: [Openvas-plugins] subversion_detect.nasl In-Reply-To: <48F8A45E.2090505@unspecific.com> References: <48F78559.1040202@unspecific.com> <48F8505E.3080909@linux.hr> <48F8A45E.2090505@unspecific.com> Message-ID: <200810172108.05383.jan-oliver.wagner@intevation.de> On Friday 17 October 2008 16:42, MadHat Unspecific wrote: > > Next time when you contribute script, please specify which version of > > GPL (GPL v2 or later or something else). > > I really don't care. ?I am not intimately familiar with the differences > in the 2 and to me it is a moot point. ?Set it to the same thing OpenVAS > is using and move on. For new things we currently apply by default "GPLv2+" = "GNU General Public License Version 2 or any later version". As do many other Free Software projects. There is a default header in doc/ section of Subversion which can be copied for new files. Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From meyer at strato-rz.de Sun Oct 19 14:08:04 2008 From: meyer at strato-rz.de (Michael Meyer) Date: Sun, 19 Oct 2008 14:08:04 +0200 Subject: [Openvas-plugins] find_service.c Message-ID: <20081019120804.GA29983@strato-rz.de> Hello, OpenVAS (openvas_tcp_scanner.nes) found port 3306 open but does not report what is behind port 3306. ,---| | mime at host01:~> telnet 81.169.179.226 3306 | Trying 81.169.179.226... | Connected to 81.169.179.226. | Escape character is '^]'. | QHost 'nat.monitoring.rz-ip.net' is not allowed to connect to this MySQL serverConnection closed by foreign host. `---| ,---[ dump.log ] | find_service(81.169.179.226): found hex banner in KB for port 3306. len=0 | find_service(81.169.179.226): found banner in KB for port 3306. len=1 | find_service(81.169.179.226): banner is known on port 3306 - will not open a new connection | find_service(81.169.179.226): Port 3306 is open. "Transport" is 1 `--- ,---[ find_service.c ] | 2219 else if (line[0] != '\0' && (strncmp(line + 1, "host '", 6) == 0) && strstr(line, "mysql") != NULL) | 2220 mark_mysql(desc, port, origline, trp); `---| at this point, 'line' contains only 'q' (The first character of the 'not allowded' string. The 'Q' was lowercased in line 2105. ,---[ find_service.c ] | 2103 | 2104 for (i = 0; i < len; i++) | 2105 buffer[i] = tolower(buffer[i]); | 2106 | 2107 line = estrdup(buffer); | 2108 `---| Because 'line' contains only 'q', find_service.c can not detect that there is a MySQL behind port 3306. There is a function for unknown services but it is commented out. ,---[ find_service.c ] | 1450 #if 0 | 1451 static void | 1452 mark_unknown_svc(desc, port, banner, trp) | 1453 struct arglist *desc; | 1454 int port, trp; | 1455 const unsigned char *banner; | 1456 { | 1457 char tmp[1600], *norm = NULL; | 1458 | 1459 /* Do NOT use plug_replace_key! */ | 1460 plug_set_key(desc, "Services/unknown", ARG_INT, (void *) port); | 1461 snprintf(tmp, sizeof(tmp), "unknown/banner/%d", port); | 1462 plug_replace_key(desc, tmp, ARG_STRING, (char *) banner); | 1463 | 1464 norm = (char *) port_to_name(port); | 1465 *tmp = '\0'; | 1466 if (norm != NULL) { | 1467 snprintf(tmp, sizeof(tmp), "An unknown service is running on this por | 1468 It is usually reserved for %s", | 1469 get_encaps_through(trp), norm); | 1470 } | 1471 if (*tmp != '\0') | 1472 post_note(desc, port, tmp); | 1473 } | 1474 #endif | | [... ] | | 2579 #if 0 | 2580 /* | 2581 * find_service_3digits will run | 2582 * after us | 2583 */ | 2584 if (!three_digits) | 2585 mark_unknown_svc(desc, port, banner, | 2586 #endif `---| If i reactivate this funktion, port 3306 will marked as a unknown service and then *find_service1.nasl* detects that there is a MySQL behind port 3306. Why is 'mark_unknown_svc' commented out? Why 'line' contains only the first character of the whole 'not allowed' string? Greetings Michael From meyer at strato-rz.de Sun Oct 19 18:34:06 2008 From: meyer at strato-rz.de (Michael Meyer) Date: Sun, 19 Oct 2008 18:34:06 +0200 Subject: [Openvas-plugins] cast to pointer from integer of different size Message-ID: <20081019163406.GA26224@strato-rz.de> Hello, FYI, on a 64bit: mime at host01:/tmp/openvas-plugins-1.0.3 % make [...] gcc -g -O2 -I/usr/local/include/openvas -I/usr/local/include/openvas -DHAVE_LIBNET_1_1 -c find_service.c -fPIC -DPIC -o .libs/find_service.o find_service.c: In function 'register_service': find_service.c:125: warning: cast to pointer from integer of different size find_service.c: In function 'mark_wrapped_svc': find_service.c:1368: warning: cast to pointer from integer of different size find_service.c: In function 'plugin_do_run': find_service.c:1979: warning: cast to pointer from integer of different size find_service.c:1981: warning: cast to pointer from integer of different size find_service.c:2019: warning: cast from pointer to integer of different size find_service.c:2091: warning: cast to pointer from integer of different size find_service.c:2093: warning: cast to pointer from integer of different size find_service.c:2119: warning: cast to pointer from integer of different size find_service.c: In function 'plugin_run': find_service.c:2715: warning: cast from pointer to integer of different size find_service.c:2849: warning: cast from pointer to integer of different size find_service.c:2858: warning: cast to pointer from integer of different size find_service.c:2859: warning: cast to pointer from integer of different size [... ] gcc -g -O2 -I/usr/local/include/openvas -I/usr/local/include/openvas -DHAVE_LIBNET_1_1 -c openvas_tcp_scanner.c -fPIC -DPIC -o .libs/openvas_tcp_scanner.o openvas_tcp_scanner.c: In function 'banner_grab': openvas_tcp_scanner.c:247: warning: cast from pointer to integer of different size openvas_tcp_scanner.c:267: warning: cast to pointer from integer of different size openvas_tcp_scanner.c:870: warning: cast to pointer from integer of different size openvas_tcp_scanner.c:872: warning: cast to pointer from integer of different size openvas_tcp_scanner.c:915: warning: cast to pointer from integer of different size openvas_tcp_scanner.c:917: warning: cast to pointer from integer of different size openvas_tcp_scanner.c:1196: warning: cast to pointer from integer of different size openvas_tcp_scanner.c:1219: warning: cast to pointer from integer of different size openvas_tcp_scanner.c:1222: warning: cast to pointer from integer of different size openvas_tcp_scanner.c:1237: warning: cast to pointer from integer of different size openvas_tcp_scanner.c:1243: warning: cast to pointer from integer of different size openvas_tcp_scanner.c:1255: warning: cast to pointer from integer of different size openvas_tcp_scanner.c:1256: warning: cast to pointer from integer of different size openvas_tcp_scanner.c:1257: warning: cast to pointer from integer of different size openvas_tcp_scanner.c:1258: warning: cast to pointer from integer of different size openvas_tcp_scanner.c:1262: warning: cast to pointer from integer of different size [...] I do not get this warnings on a 32bit. Greetings Michael From jan-oliver.wagner at intevation.de Mon Oct 20 09:59:14 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Mon, 20 Oct 2008 09:59:14 +0200 Subject: [Openvas-plugins] cast to pointer from integer of different size In-Reply-To: <20081019163406.GA26224@strato-rz.de> References: <20081019163406.GA26224@strato-rz.de> Message-ID: <200810200959.16756.jan-oliver.wagner@intevation.de> Hi Michael, On Sonntag, 19. Oktober 2008, Michael Meyer wrote: > FYI, on a 64bit: yes, this was discussed on openvas-devel. Stjepan submitted a large patch that uses the GLIB functionality for 64bit cleanness. However, openvas-plugins ist not branched yet as it is compatible with both, OpenVAS 1.x and 2.x. I think, we should first get the patch into the other modules and see how it all works out before migrating openvas-plugins. Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From billypeas at googlemail.com Mon Oct 20 10:48:48 2008 From: billypeas at googlemail.com (Billy Peas) Date: Mon, 20 Oct 2008 09:48:48 +0100 Subject: [Openvas-plugins] Various plugins SMB issue? Message-ID: <6d9c53ea0810200148q65a541a5jec3e16b277a5ccea@mail.gmail.com> Hi List, I've run a scan against a host I had previously tested with a professional feed fo Nessus and am seeing some weird plugins fire that were not present in the Nessus scan. I appreciate and understand the 2 products may find different results but the plugin output was a little weird. Anyway I get multiple plugins firing returning the error below where xxx.xxx.xxx.xxx is the IP: Error getting SMB-Data -> CONNECTION TO xxx.xxx.xxx.xxx FAILED (ERROR NT_STATUS_CONNECTION_REFUSED) and Error getting SMB-Data -> One ofthe plugins doing this is "Windows Vulnerability In DNS Client Could Allow Spoofing (945553)" and another is "Adobe Flash Player 9.0.115.0 And Earlier Vulnerability" It seems like when the plugin errors its (incorrectly?) saying the host is vulnerable. I am using Openvas client 1.0.4, server 1.0.2, libnasl 1.0.1, libraries 1.0.2 and plugins 1.0.2 and have done a fresh nvt-sync. Can anyone suggest why this is happening and how to resolve? I've posted this to the plugins list but I can post to the devel list as well if you think its more suited there. Thanks Billy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20081020/6bc9039c/attachment.htm From c.koch-mauthe at dn-systems.de Mon Oct 20 17:43:52 2008 From: c.koch-mauthe at dn-systems.de (Carsten Koch-Mauthe) Date: Mon, 20 Oct 2008 17:43:52 +0200 Subject: [Openvas-plugins] Various plugins SMB issue? In-Reply-To: <6d9c53ea0810200148q65a541a5jec3e16b277a5ccea@mail.gmail.com> References: <6d9c53ea0810200148q65a541a5jec3e16b277a5ccea@mail.gmail.com> Message-ID: <200810201743.52939.c.koch-mauthe@dn-systems.de> Hi, > I've run a scan against a host I had previously tested with a professional > feed fo Nessus and am seeing some weird plugins fire that were not present > in the Nessus scan. I appreciate and understand the 2 products may find > different results but the plugin output was a little weird. > > Anyway I get multiple plugins firing returning the error below where > xxx.xxx.xxx.xxx is the IP: > > Error getting SMB-Data -> CONNECTION TO xxx.xxx.xxx.xxx FAILED (ERROR > NT_STATUS_CONNECTION_REFUSED) > > and > > Error getting SMB-Data -> These messages are only notes that something went wrong when running the scripts. For example wrong smb credentials for accessing the host. What is the Host OS ? > > One ofthe plugins doing this is "Windows Vulnerability In DNS Client Could > Allow Spoofing (945553)" and another is "Adobe Flash Player 9.0.115.0 And > Earlier Vulnerability" It seems like when the plugin errors its > (incorrectly?) saying the host is vulnerable. The messages should be shown as "Security note" within OpenVAS-Client.This will not mean that this host is vulnerable. In this cases it only means that something went wrong running the scripts and give you a hint what happend. > > I am using Openvas client 1.0.4, server 1.0.2, libnasl 1.0.1, libraries > 1.0.2 and plugins 1.0.2 and have done a fresh nvt-sync. > > Can anyone suggest why this is happening and how to resolve? Probably wrong credentials. These scripts need credentials for administrator or user with administration rights. Firewall active on target host ? -- Gruss ? ? Carsten Koch-Mauthe ? ? ?http://www.dn-systems.de ?mail: c.koch-mauthe at dn-systems.de ?DN-Systems Enterprise Internet Solutions GmbH ?Hornemannstr. 11 31137 Hildesheim, Germany ? ? ?Tel. +49-5121-28989-0 Fax. +49-5121-28989-11 ?21 Sunrise Ct, S.San Francisco, CA 94080, USA ?Tel. +1-650-472-2512 ?Mob. +1-650-430-1219 ?Handelsregister HRB-3213 Amtsgericht Hildesheim ?Gesch?ftsf?hrer Lukas Grunwald From c.koch-mauthe at dn-systems.de Wed Oct 22 00:22:26 2008 From: c.koch-mauthe at dn-systems.de (Carsten Koch-Mauthe) Date: Wed, 22 Oct 2008 00:22:26 +0200 Subject: [Openvas-plugins] How to handle some linux vulnerabilities Message-ID: <200810220022.27027.c.koch-mauthe@dn-systems.de> Hello List, Chandra and i had a disscusion how to handle linux tests. The problem is, that most linux distros provides patches for vulnerabilities which not change the version of the fixed program. So local security checks are not useful in that case. For example cups package on Suse linux 10.3 which is version 1.2.12-22.17 . Last Security announcement for cups says that every version below 1.3.9 is vulnerable. But this Suse Version is a patched non vulnerable version. So checking for Version < 1.3.9 will give a false positive. I think it is nessesary to check which distro is used and the script then have to check for distro specific version numbers like the securityspace debian scripts are doing. Chandra has made the following proposals. === Schnipp === Hello Carsten, This is one of the issue with Linux based scripts. I raised this in IRC, no response came. The issue is, 1. As you have pointed, most of the Linux distros have their own packages and versions and updates are released much later than vulnerabilities are disclosed to the public. 2. There are tar package installations (some might prefer downloading and installing on their own) that are actual package versions. To these, most of the time, as soon as vulnerabilities are disclosed to the public, patch is made available. In my view, both these have to be verified. The way to go about it would be, Option 1: 1. Release the plugin assuming the public release version (not distros package version). 2. When updated packages are made available by each vendor, develop local checks (automated checks) and add a check in #1 to see which Linux distro it is and based on that, either, ?a) exit() if the local check is available. If not, proceed with ? ? checking. or ?b) Launch the local check for the specific distro by adding that as a ? ? dependency Option 2: 1. Maintain a backport version of each package for each Linux distribution in an inc. 2. Check for the backported version based on the Linux distribution 3. Towards the end of the plugin, we can check for manually installed original version. Option #2 would be ideal to do, but requires good amount of work initially to capture versions for each package and keep that up to date every time an update is released. Please let me know your views. Thanks, Chandra. === Schnapp === Please let us know your views. -- Gruss ? ? Carsten Koch-Mauthe ? ? ?http://www.dn-systems.de ?mail: c.koch-mauthe at dn-systems.de ?DN-Systems Enterprise Internet Solutions GmbH ?Hornemannstr. 11 31137 Hildesheim, Germany ? ? ?Tel. +49-5121-28989-0 Fax. +49-5121-28989-11 ?21 Sunrise Ct, S.San Francisco, CA 94080, USA ?Tel. +1-650-472-2512 ?Mob. +1-650-430-1219 ?Handelsregister HRB-3213 Amtsgericht Hildesheim ?Gesch?ftsf?hrer Lukas Grunwald From michael.wiegand at intevation.de Wed Oct 22 10:21:38 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Wed, 22 Oct 2008 10:21:38 +0200 Subject: [Openvas-plugins] New NASL functions available: log_message and debug_message Message-ID: <200810221021.38821.michael.wiegand@intevation.de> Hello, as some of you may have noticed, the change from NTP to OTP brought two new message types: LOG and DEBUG. These message types are intended to improve the communication with the client by complementing the HOLE, NOTE and INFO message types. The idea behind the new message types was to provide the NVTs with the option to send information the client which is not in itself relevant to the security of the target system, but provides information on issues encountered by the NVT while scanning. The philosophy behind most old NASL scripts was to only communicated with the client if the NVT had found a security issue. While this certainly made sense, it also led users to assume that there was no security threat if the NVT did not issue any message at all when in reality the NASL script encountered a problem which prevented it from running at all. This means the "no news is good news" approach is not always a good idea when it comes to security. The main use case for the LOG message type would be informing the client that your NVT was not able to run and, if possible, give a short explanation as to what caused the problem and what the user might do to address this. The DEBUG message could be used to give more technical details about the issue encountered by the NVT. Note that these message types are not intended to alert the client about security issues and might be ignored by the client depending on the options set by the user. Use the security_hole, security_note and security_info for messages relevant to security issues. I would encourage all NVT writers to include these message types in their NVTs. Starting with openvas-libnasl 2.0-beta1, the message types are available to your NASL script with the log_message() and debug_message() function. The syntax for those functions is identical with the security_hole(), security_note() and security_info() functions. Please remember to keep your NVTs backwards compatible and check if these functions are available to your script before using them. You can do this by evaluating the value of OPENVAS_NASL_LEVEL in your NASL script; if the value is 2300 or higher, log_message and debug_message are available and can be used. Note that OPENVAS_NASL_LEVEL has only been set to 2300 in the latest SVN Revision (1598) of openvas-libnasl. This means that you have to use a SVN revision or wait for the upcoming openvas-libnasl 2.0-beta2 if you want to see the new message types in action. The client is able to understand LOG and DEBUG starting with 2.0-beta1. I hope the new functions are useful to you; please let me know if you have any questions or suggestions. Regards, Michael -- Michael Wiegand | OpenPGP key: D7D049EC | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From lists at securityspace.com Wed Oct 22 16:29:56 2008 From: lists at securityspace.com (Thomas Reinke) Date: Wed, 22 Oct 2008 10:29:56 -0400 Subject: [Openvas-plugins] How to handle some linux vulnerabilities In-Reply-To: <200810220022.27027.c.koch-mauthe@dn-systems.de> References: <200810220022.27027.c.koch-mauthe@dn-systems.de> Message-ID: <48FF38E4.9080405@securityspace.com> Carsten Koch-Mauthe wrote: > Hello List, > > Chandra and i had a disscusion how to handle linux tests. The problem is, that > most linux distros provides patches for vulnerabilities which not change the > version of the fixed program. So local security checks are not useful in that > case. For example cups package on Suse linux 10.3 which is version > 1.2.12-22.17 . Last Security announcement for cups says that every version > below 1.3.9 is vulnerable. But this Suse Version is a patched non vulnerable > version. So checking for Version < 1.3.9 will give a false positive. I think > it is nessesary to check which distro is used and the script then have to > check for distro specific version numbers like the securityspace debian > scripts are doing. > Chandra has made the following proposals. > > === Schnipp === > Hello Carsten, > > This is one of the issue with Linux based scripts. I raised this in IRC, no > response came. > > The issue is, > > 1. As you have pointed, most of the Linux distros have their own packages > and versions and updates are released much later than vulnerabilities are > disclosed to the public. > > 2. There are tar package installations (some might prefer downloading and > installing on their own) that are actual package versions. To these, most of > the time, as soon as vulnerabilities are disclosed to the public, patch is > made available. > > In my view, both these have to be verified. The way to go about it would be, > > Option 1: > 1. Release the plugin assuming the public release version (not distros > package version). Many false positives will ensue. > > 2. When updated packages are made available by each vendor, develop local > checks (automated checks) and add a check in #1 to see which Linux distro it > is and based on that, either, > a) exit() if the local check is available. If not, proceed with > checking. > or > b) Launch the local check for the specific distro by adding that as a > dependency A maintenance headache, to say the least. > > Option 2: > 1. Maintain a backport version of each package for each Linux distribution > in an inc. You're kidding, right? > 2. Check for the backported version based on the Linux distribution > 3. Towards the end of the plugin, we can check for manually installed > original version. > > Option #2 would be ideal to do, but requires good amount of work initially > to capture versions for each package and keep that up to date every time an > update is released. It's more than just a good amount of work initially, it's a huge amount of work on an ongoing basis. > > Please let me know your views. I understand the motivation for doing the above, but have to admit, I don't like the approaches, nor do I necessarily agree with the rational. First, to make it clear, local security checks for distributions can be written in a way that there are no false positives. As understood, this requires us to assume the user is using a distribution specific package. The only two reasons to write scripts that go beyond this is because we think a) distributions are late in their delivery of patches, AND that their tardiness is a sufficient security issue to warrant us addressing it. b) enough users build their own software from source and that it warrants us checking for these situations. Re assumption of late delivery of patches: do we really want to be in the business of reporting the tardiness of all packages in all distributions? I wouldn't want to do it for 1 distribution, let alone for 10. Re users building their own packages: I suspect this has become much _less_ common these days than it used to be in the past as software and distributions become more specialized and mature. You probably don't, for example, run Debian if you want the latest and greatest of any and every package, you probably go something like Fedora. If you are looking for long term support and stability, you probably don't go Fedora. Users will probably gravitate to the distribution that meets their needs and use the prebuilt packages that come with that distribution (IMHO). That all being said, you can relatively painlessly check for self-installed packages simply by first checking that the distribution package is NOT installed before proceeding with any specific check for a source built binary. It's going to be a safe bet that distribution binaries and self-built binaries are mutually exclusive in terms of their presence on a system. Thus, use the information already collected by gather-package-list.nasl before proceeding with a source built binary check. Thomas From timb at nth-dimension.org.uk Wed Oct 22 17:33:39 2008 From: timb at nth-dimension.org.uk (Tim Brown) Date: Wed, 22 Oct 2008 16:33:39 +0100 Subject: [Openvas-plugins] How to handle some linux vulnerabilities In-Reply-To: <48FF38E4.9080405@securityspace.com> References: <200810220022.27027.c.koch-mauthe@dn-systems.de> <48FF38E4.9080405@securityspace.com> Message-ID: <200810221633.39298.timb@nth-dimension.org.uk> I've snipped Thomas's comments but I concur entirely with what he has said. Note that the Solaris local checks function in a similar manner to the Debian ones. We extract the patch number for the fixed version and check that it is there. If it it not, we flag an issue. (Actually we do a bit more but for the sake of this argument). I would certainly not recommend checking versions ala ./buggyapp -v and regexing the response. I suppose a minor caveat would be 3rd party apps, but here we do not have to deal with backports. Cheers, Tim -- Tim Brown From bchandra at secpod.com Thu Oct 23 08:09:30 2008 From: bchandra at secpod.com (Chandrashekhar B) Date: Thu, 23 Oct 2008 11:39:30 +0530 Subject: [Openvas-plugins] How to handle some linux vulnerabilities In-Reply-To: <48FF38E4.9080405@securityspace.com> References: <200810220022.27027.c.koch-mauthe@dn-systems.de> <48FF38E4.9080405@securityspace.com> Message-ID: I agree to the points here. If we assume that all are using distribution specific packages (that makes it easy), problem is solved. I have one question though, when vulnerability is reported in a package and vendor hasn't released an update, there's a time window where user is unaware that vulnerability exist. Do we have to report or wait till update is released? Chandra. -----Original Message----- From: openvas-plugins-bounces at wald.intevation.org [mailto:openvas-plugins-bounces at wald.intevation.org] On Behalf Of Thomas Reinke Sent: Wednesday, October 22, 2008 8:00 PM To: openvas-plugins at wald.intevation.org Subject: Re: [Openvas-plugins] How to handle some linux vulnerabilities Carsten Koch-Mauthe wrote: > Hello List, > > Chandra and i had a disscusion how to handle linux tests. The problem is, that > most linux distros provides patches for vulnerabilities which not change the > version of the fixed program. So local security checks are not useful in that > case. For example cups package on Suse linux 10.3 which is version > 1.2.12-22.17 . Last Security announcement for cups says that every version > below 1.3.9 is vulnerable. But this Suse Version is a patched non vulnerable > version. So checking for Version < 1.3.9 will give a false positive. I think > it is nessesary to check which distro is used and the script then have to > check for distro specific version numbers like the securityspace debian > scripts are doing. > Chandra has made the following proposals. > > === Schnipp === > Hello Carsten, > > This is one of the issue with Linux based scripts. I raised this in IRC, no > response came. > > The issue is, > > 1. As you have pointed, most of the Linux distros have their own packages > and versions and updates are released much later than vulnerabilities are > disclosed to the public. > > 2. There are tar package installations (some might prefer downloading and > installing on their own) that are actual package versions. To these, most of > the time, as soon as vulnerabilities are disclosed to the public, patch is > made available. > > In my view, both these have to be verified. The way to go about it would be, > > Option 1: > 1. Release the plugin assuming the public release version (not distros > package version). Many false positives will ensue. > > 2. When updated packages are made available by each vendor, develop local > checks (automated checks) and add a check in #1 to see which Linux distro it > is and based on that, either, > a) exit() if the local check is available. If not, proceed with > checking. > or > b) Launch the local check for the specific distro by adding that as a > dependency A maintenance headache, to say the least. > > Option 2: > 1. Maintain a backport version of each package for each Linux distribution > in an inc. You're kidding, right? > 2. Check for the backported version based on the Linux distribution > 3. Towards the end of the plugin, we can check for manually installed > original version. > > Option #2 would be ideal to do, but requires good amount of work initially > to capture versions for each package and keep that up to date every time an > update is released. It's more than just a good amount of work initially, it's a huge amount of work on an ongoing basis. > > Please let me know your views. I understand the motivation for doing the above, but have to admit, I don't like the approaches, nor do I necessarily agree with the rational. First, to make it clear, local security checks for distributions can be written in a way that there are no false positives. As understood, this requires us to assume the user is using a distribution specific package. The only two reasons to write scripts that go beyond this is because we think a) distributions are late in their delivery of patches, AND that their tardiness is a sufficient security issue to warrant us addressing it. b) enough users build their own software from source and that it warrants us checking for these situations. Re assumption of late delivery of patches: do we really want to be in the business of reporting the tardiness of all packages in all distributions? I wouldn't want to do it for 1 distribution, let alone for 10. Re users building their own packages: I suspect this has become much _less_ common these days than it used to be in the past as software and distributions become more specialized and mature. You probably don't, for example, run Debian if you want the latest and greatest of any and every package, you probably go something like Fedora. If you are looking for long term support and stability, you probably don't go Fedora. Users will probably gravitate to the distribution that meets their needs and use the prebuilt packages that come with that distribution (IMHO). That all being said, you can relatively painlessly check for self-installed packages simply by first checking that the distribution package is NOT installed before proceeding with any specific check for a source built binary. It's going to be a safe bet that distribution binaries and self-built binaries are mutually exclusive in terms of their presence on a system. Thus, use the information already collected by gather-package-list.nasl before proceeding with a source built binary check. Thomas _______________________________________________ Openvas-plugins mailing list Openvas-plugins at wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins From rodrigo at kernelhacking.com Thu Oct 23 12:38:18 2008 From: rodrigo at kernelhacking.com (Rodrigo Rubira Branco (BSDaemon)) Date: Thu, 23 Oct 2008 08:38:18 -0200 Subject: [Openvas-plugins] How to handle some linux vulnerabilities In-Reply-To: References: <200810220022.27027.c.koch-mauthe@dn-systems.de> <48FF38E4.9080405@securityspace.com> Message-ID: <4900541A.3060608@kernelhacking.com> Chandrashekhar B escreveu: > I agree to the points here. If we assume that all are using distribution > specific packages (that makes it easy), problem is solved. I have one > question though, when vulnerability is reported in a package and vendor > hasn't released an update, there's a time window where user is unaware that > vulnerability exist. Do we have to report or wait till update is released? > It's important to report anyway... Security != obscurity... If we know there is a problem, the user should know too... Maybe this will help them to better choose their vendors. cya, Rodrigo (BSDaemon). From jan-oliver.wagner at intevation.de Thu Oct 23 14:56:22 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Thu, 23 Oct 2008 14:56:22 +0200 Subject: [Openvas-plugins] find_service.c In-Reply-To: <20081019120804.GA29983@strato-rz.de> References: <20081019120804.GA29983@strato-rz.de> Message-ID: <200810231456.24011.jan-oliver.wagner@intevation.de> Hello, On Sonntag, 19. Oktober 2008, Michael Meyer wrote: > OpenVAS (openvas_tcp_scanner.nes) found port 3306 open but does not report what is behind port 3306. Kost: I guess this is something for you as you have dealt with the port scanners already a lot... Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Thu Oct 23 15:18:47 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Thu, 23 Oct 2008 15:18:47 +0200 Subject: [Openvas-plugins] How to handle some linux vulnerabilities In-Reply-To: References: <200810220022.27027.c.koch-mauthe@dn-systems.de> <48FF38E4.9080405@securityspace.com> Message-ID: <200810231518.49177.jan-oliver.wagner@intevation.de> On Donnerstag, 23. Oktober 2008, Chandrashekhar B wrote: > I agree to the points here. If we assume that all are using distribution > specific packages (that makes it easy), problem is solved. it is my experience that many services in production mode are not based on official packages, but rather self-compiled, self-pached, self-optimized. I do not have an answer at hand how to handle the situation best. Thomas seems to say, look at practice and majorities and relate to effords. This is a reasonable approach opposed to conquering the whole world in one go. Though I think there might exist cases where minority circumstances that a cheap to solve and of great importance. In such situations where I can not really decide immediately, I create a diagramme or other sorts of drawing to illustrate the work/decision flow, starting with the standard cases. Anyone feels like creating such a figure that explains the scan/decision flow ? Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From lists at securityspace.com Thu Oct 23 18:46:41 2008 From: lists at securityspace.com (Thomas Reinke) Date: Thu, 23 Oct 2008 12:46:41 -0400 Subject: [Openvas-plugins] How to handle some linux vulnerabilities In-Reply-To: References: <200810220022.27027.c.koch-mauthe@dn-systems.de> <48FF38E4.9080405@securityspace.com> Message-ID: <4900AA71.3080208@securityspace.com> My first call would be to wait, on the presumption that the window is usually small enough to not be an issue. In fact, in many cases, important fixes (think Bind, SSH, Apache) are rolled out before the vulnerabilities are even reported. Does anyone have any evidence to suggest that the wait time between vulnerability report and update availability is long enough to justify carving out that niche with OpenVAS? Thomas Chandrashekhar B wrote: > I agree to the points here. If we assume that all are using distribution > specific packages (that makes it easy), problem is solved. I have one > question though, when vulnerability is reported in a package and vendor > hasn't released an update, there's a time window where user is unaware that > vulnerability exist. Do we have to report or wait till update is released? > > Chandra. > > -----Original Message----- > From: openvas-plugins-bounces at wald.intevation.org > [mailto:openvas-plugins-bounces at wald.intevation.org] On Behalf Of Thomas > Reinke > Sent: Wednesday, October 22, 2008 8:00 PM > To: openvas-plugins at wald.intevation.org > Subject: Re: [Openvas-plugins] How to handle some linux vulnerabilities > > Carsten Koch-Mauthe wrote: >> Hello List, >> >> Chandra and i had a disscusion how to handle linux tests. The problem is, > that >> most linux distros provides patches for vulnerabilities which not change > the >> version of the fixed program. So local security checks are not useful in > that >> case. For example cups package on Suse linux 10.3 which is version >> 1.2.12-22.17 . Last Security announcement for cups says that every version > >> below 1.3.9 is vulnerable. But this Suse Version is a patched non > vulnerable >> version. So checking for Version < 1.3.9 will give a false positive. I > think >> it is nessesary to check which distro is used and the script then have to >> check for distro specific version numbers like the securityspace debian >> scripts are doing. >> Chandra has made the following proposals. >> >> === Schnipp === >> Hello Carsten, >> >> This is one of the issue with Linux based scripts. I raised this in IRC, > no >> response came. >> >> The issue is, >> >> 1. As you have pointed, most of the Linux distros have their own packages >> and versions and updates are released much later than vulnerabilities are >> disclosed to the public. >> >> 2. There are tar package installations (some might prefer downloading and >> installing on their own) that are actual package versions. To these, most > of >> the time, as soon as vulnerabilities are disclosed to the public, patch is >> made available. >> >> In my view, both these have to be verified. The way to go about it would > be, >> Option 1: >> 1. Release the plugin assuming the public release version (not distros >> package version). > > Many false positives will ensue. > >> 2. When updated packages are made available by each vendor, develop local >> checks (automated checks) and add a check in #1 to see which Linux distro > it >> is and based on that, either, >> a) exit() if the local check is available. If not, proceed with >> checking. >> or >> b) Launch the local check for the specific distro by adding that as a >> dependency > > A maintenance headache, to say the least. > >> Option 2: >> 1. Maintain a backport version of each package for each Linux distribution >> in an inc. > > You're kidding, right? > >> 2. Check for the backported version based on the Linux distribution >> 3. Towards the end of the plugin, we can check for manually installed >> original version. >> >> Option #2 would be ideal to do, but requires good amount of work initially >> to capture versions for each package and keep that up to date every time > an >> update is released. > > It's more than just a good amount of work initially, it's a huge amount > of work on an ongoing basis. > >> Please let me know your views. > > I understand the motivation for doing the above, but have to admit, I > don't like the approaches, nor do I necessarily agree with the rational. > > First, to make it clear, local security checks for distributions can > be written in a way that there are no false positives. As understood, > this requires us to assume the user is using a distribution specific > package. The only two reasons to write scripts that go beyond this > is because we think > > a) distributions are late in their delivery of patches, AND > that their tardiness is a sufficient security issue to warrant > us addressing it. > > b) enough users build their own software from source and that it > warrants us checking for these situations. > > Re assumption of late delivery of patches: do we really want to be > in the business of reporting the tardiness of all packages in all > distributions? I wouldn't want to do it for 1 distribution, > let alone for 10. > > Re users building their own packages: I suspect this has become > much _less_ common these days than it used to be in the past > as software and distributions become more specialized and mature. > You probably don't, for example, run Debian if you want the latest > and greatest of any and every package, you probably go something > like Fedora. If you are looking for long term support and stability, > you probably don't go Fedora. Users will probably gravitate to the > distribution that meets their needs and use the prebuilt packages > that come with that distribution (IMHO). > > That all being said, you can relatively painlessly check for > self-installed packages simply by first checking that the distribution > package is NOT installed before proceeding with any specific > check for a source built binary. It's going to be a safe bet > that distribution binaries and self-built binaries are mutually > exclusive in terms of their presence on a system. Thus, use the > information already collected by gather-package-list.nasl before > proceeding with a source built binary check. > > Thomas > _______________________________________________ > Openvas-plugins mailing list > Openvas-plugins at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins > > _______________________________________________ > Openvas-plugins mailing list > Openvas-plugins at wald.intevation.org > http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins > From kost at linux.hr Sat Oct 25 08:40:17 2008 From: kost at linux.hr (Vlatko Kosturjak) Date: Sat, 25 Oct 2008 08:40:17 +0200 Subject: [Openvas-plugins] Bunch of free nasl scripts In-Reply-To: <200809291141.32323.jan-oliver.wagner@intevation.de> References: <48DC16C1.3030400@linux.hr> <200809291141.32323.jan-oliver.wagner@intevation.de> Message-ID: <4902BF51.8000504@linux.hr> >> gpl: these scripts are probably working and are GPL, there is few >> scripts by Arboi were he says "GPL..." after his copyright notice, so I >> guess it is released under GPL. > from the whole given context we can assume GNU General Public License v2 > is meant. > I'd say you check the scripts into SVN. As there were no complaint and contest is closed, I've just commited all NASL scripts. There is comment # kst-depend-misc, # kst-depend-rpc, # kst-depend-smb and # kst-gpl respectively. I've just changed the script_id and added tag before committing. So, that we have change trail in SVN on any change we make from original plugins (example is hydra_mysql and hydra_postgresql which I already changed to work with OpenVAS). Feel free to help with adapting the plugins, especially depend-smb, depend-rpc and depend-misc. Kost From kost at linux.hr Sat Oct 25 08:54:22 2008 From: kost at linux.hr (Vlatko Kosturjak) Date: Sat, 25 Oct 2008 08:54:22 +0200 Subject: [Openvas-plugins] Bunch of free nasl scripts In-Reply-To: <200809291143.30799.jan-oliver.wagner@intevation.de> References: <48DC16C1.3030400@linux.hr> <200809291141.32323.jan-oliver.wagner@intevation.de> <200809291143.30799.jan-oliver.wagner@intevation.de> Message-ID: <4902C29E.1080407@linux.hr> Jan-Oliver Wagner wrote: > On Montag, 29. September 2008, Jan-Oliver Wagner wrote: >> I'd say you check the scripts into SVN. > I forgot to mention: please make sure the IDs don't conflict. > Document the ranges in the file openvas-oids.htm4 in case. I assigned them numbers from 8NNNNN tree. But this as a whole is another story. I've just quickly hacked two perl scripts which can help. First one is openvas_find_dup_nasl.pl which you can find here: http://www.linux.hr/openvas/scripts/openvas_find_dup_nasl.pl You need to run it in plugins directory (with nasl files), here's the example run (no news==good news): .../plugins/$ ~/code/openvas_find_dup_nasl.pl eyeos_command_execution.nasl: probably syntax error in script_id def eyeos_command_execution.nasl: no valid script_id definition So, with this script I found out that eyeos_command_execution.nasl had broken script_id for two months which I corrected/commited: http://wald.intevation.org/plugins/scmsvn/viewcvs.php/trunk/openvas-plugins/scripts/eyeos_command_execution.nasl?root=openvas&view=log Maybe we should run it with every bigger plugins commit or when we are planning release of openvas-plugins? Another script is openvas_disp_script_id.pl which you can find here: http://www.linux.hr/openvas/scripts/openvas_disp_script_id.pl You need to run it in plugins directory (with nasl files) as well, here's the example run: /code/openvas_disp_script_id.pl 12planet_chat_server_xss.nasl: 12299 3com_nbx_voip_netset_detection.nasl: 12221 3com_switches.nasl: 10747 404_path_disclosure.nasl: 11714 4553.nasl: 11187 Script will output name and script_id. Very useful for various scriptings involving script_id and scripts itself. Hope it will help! Kost From michael.wiegand at intevation.de Mon Oct 27 12:04:56 2008 From: michael.wiegand at intevation.de (Michael Wiegand) Date: Mon, 27 Oct 2008 12:04:56 +0100 Subject: [Openvas-plugins] Planning openvas-plugins 1.0.4 release Message-ID: <200810271204.56684.michael.wiegand@intevation.de> Hello, as mentioned on openvas-distro, I would like to do a new release of openvas-plugins soon. One reason behind this is that openvas-plugins 1.0.2 has been rejected from Debian since it contained NVTs with an unclear or incompatible license. These NVTs are still present in 1.0.3, but have been since replaced by GPLed NVTs (Thanks to Thomas Reinke!). Apart from this issue, there have been quite a lot of changes and additions in openvas-plugins since the 1.0.3 release that would justify a new release anyway. As I said before, I would like to do this release very soon (today if possible) so the package maintainers can get the new release as soon as possible. Let me know what you think. Regards, Michael -- Michael Wiegand | OpenPGP key: D7D049EC | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Tue Oct 28 21:38:05 2008 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Tue, 28 Oct 2008 22:38:05 +0200 Subject: [Openvas-plugins] Bunch of free nasl scripts In-Reply-To: <4902C29E.1080407@linux.hr> References: <48DC16C1.3030400@linux.hr> <200809291143.30799.jan-oliver.wagner@intevation.de> <4902C29E.1080407@linux.hr> Message-ID: <200810282138.07291.jan-oliver.wagner@intevation.de> Hello kost, On Samstag, 25. Oktober 2008, Vlatko Kosturjak wrote: > Jan-Oliver Wagner wrote: > > On Montag, 29. September 2008, Jan-Oliver Wagner wrote: > >> I'd say you check the scripts into SVN. > > I forgot to mention: please make sure the IDs don't conflict. > > Document the ranges in the file openvas-oids.htm4 in case. > > I assigned them numbers from 8NNNNN tree. But this as a whole is another > story. I've just quickly hacked two perl scripts which can help. > > First one is openvas_find_dup_nasl.pl which you can find here: > http://www.linux.hr/openvas/scripts/openvas_find_dup_nasl.pl > > You need to run it in plugins directory (with nasl files), here's the > example run (no news==good news): > .../plugins/$ ~/code/openvas_find_dup_nasl.pl > eyeos_command_execution.nasl: probably syntax error in script_id def > eyeos_command_execution.nasl: no valid script_id definition > > So, with this script I found out that eyeos_command_execution.nasl had > broken script_id for two months which I corrected/commited: > http://wald.intevation.org/plugins/scmsvn/viewcvs.php/trunk/openvas-plugins/scripts/eyeos_command_execution.nasl?root=openvas&view=log > > Maybe we should run it with every bigger plugins commit or when we are > planning release of openvas-plugins? it would be nice if you could add the script into the extra/ directory of openvas-plugins > Another script is openvas_disp_script_id.pl which you can find here: > http://www.linux.hr/openvas/scripts/openvas_disp_script_id.pl same here. Eventually we implement a "make test" routine with all integrity checks so that at least for the release we'll have consistency. Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From timb at nth-dimension.org.uk Fri Oct 31 23:36:55 2008 From: timb at nth-dimension.org.uk (Tim Brown) Date: Fri, 31 Oct 2008 22:36:55 +0000 Subject: [Openvas-plugins] Solaris Local Security Checks Message-ID: <200810312236.55376.timb@nth-dimension.org.uk> All, This evening I committed >1100 Solaris local security checks to the openvas-plugins-solaris-local-security-checks branch. These checks are automatically generated from the list of security patches published on Sunsolve. You can check out the branch as follows: svn checkout https://svn.wald.intevation.org/svn/openvas/branches/openvas-plugins-solaris-local-security-checks Whilst the plugins themselves (and solaris.inc) are, I believe correct, the limited testing I have done this far, indicates a problem with gather-package-list.nasl which is used to gather the information and set knowledge base entries on which these checks depend. I'm going to be very busy with work for the next 5 weeks and so I'd invite any of you that have access to Solaris boxes to have a play and see if the problems I experienced can be resolved. I should be contactable via email and I'll be online when I can, so if anyone does find the root of the problem, I'm more than happy to merge whatever patches are required (or someone else will). It would be nice to include these checks in OpenVAS 2.0.0 so any assistance would be appreciated. Cheers, Tim -- Tim Brown From billypeas at googlemail.com Mon Oct 20 10:45:46 2008 From: billypeas at googlemail.com (Billy Peas) Date: Mon, 20 Oct 2008 08:45:46 -0000 Subject: [Openvas-plugins] Various plugins SMB issue? Message-ID: <6d9c53ea0810200143l283bdc9ejea963a93b46a2bf9@mail.gmail.com> Hi List, I've run a scan against a host I had previously tested with a professional feed fo Nessus and am seeing some weird plugins fire that were not present in the Nessus scan. I appreciate and understand the 2 products may find different results but the plugin output was a little weird. Anyway I get multiple plugins firing returning the error below where xxx.xxx.xxx.xxx is the IP: Error getting SMB-Data -> CONNECTION TO xxx.xxx.xxx.xxx FAILED (ERROR NT_STATUS_CONNECTION_REFUSED) and Error getting SMB-Data -> One ofthe plugins doing this is "Windows Vulnerability In DNS Client Could Allow Spoofing (945553)" and another is "Adobe Flash Player 9.0.115.0 And Earlier Vulnerability" It seems like when the plugin errors its (incorrectly?) saying the host is vulnerable. I am using Openvas client 1.0.4, server 1.0.2, libnasl 1.0.1, libraries 1.0.2 and plugins 1.0.2 and have done a fresh nvt-sync. Can anyone suggest why this is happening and how to resolve? I've posted this to the plugins list but I can post to the devel list as well if you think its more suited there. Thanks Billy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.wald.intevation.org/pipermail/openvas-plugins/attachments/20081020/1fc53fd0/attachment-0001.htm