Thanks a lot Jonas. While I cannot comment on the content, I am cross-posting to the openvas-plugins mailinglist.
On Friday 08 January 2010 13:17:56 Jonas Andradas Jonas <[email protected]> wrote: > Hello, > > I am using OpenVAS 2 Debian packages, versions: > > libopenvas2 2.0.4-2 > libopenvasnasl2 2.0.2-2 > openvas-client 2.0.5-1intevation1 > openvas-plugins-base 1.0.7-5+svn20090920 > openvas-plugins-dfsg 1.0.7-5+svn20090920 > openvas-server 2.0.3-3 > > I work as a security auditor, and at my company we are using Nessus 4, and > introducing OpenVAS (hopefully, soon it will replace our Nessus). > > Related to the false positive Fidel Castro reported on December 18th, I > wanted to share a "false negative". I am scanning an APC Smart-UPS 1000 RM > device (with version 3.5.5 of APC OS). On port 80 , there is a web server > which, upon an empty GET request, freezes or, at least, becomes > unresponsive. This also makes unresponsive the Telnet server running on the > device. After a while, services are restored. OpenVAS did not report this > issue, but Nessus 4 did report it as "Linksys WRT54G Empty GET Request > Remote DoS". Another host, running OpenSuse 11 and TightVNC 1.2.9, > presents the same issue on the VNC-HTTP port 5801. This was also not > identified by OpenVAS. It seems that more than only the WRT54G has these > issues, so maybe a generic result could be done so that if safe checks are > disabled, and the server does freeze after sending an empty GET, it gets > reported, even if the host is not identified as an WRT54G router or any > other device where this vulnerability might be known. > > > The other issue I would like to comment and ask about is that on some of my > recent scans, I've seen that, when there is an SNMP service with default > credentials ("public" and/or "private", for example), sometimes I get a > result in the report for a Security Hole on port 32789 UDP, which states > that an SNMP server responds to these default community names. I was not > scanning that UDP port on the Options (and I have checked the parameter > that makes consider all unscanned ports as closed). Later, I am unable to > manually verify the existance of this SNMP service listening on port 32789, > nor using SNMP polling software, nor running NMAP against UDP port 32789 > (it appears as "closed"). I don't know if this is an OpenVAS false > positive or if the execution of some plugins somehow makes the remote host > answer SNMP requests on this port. I have seen this behaviour on APC > Smart-UPS and Allied Telesyn 8326GB switches. > > Best Regards, > > Jonás Andradas. -- Felix Wolfsteller | ++49 541 335083-783 | http://www.intevation.de/ PGP Key: 39DE0100 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 _______________________________________________ Openvas-plugins mailing list [email protected] http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins
