Ist Nessus von Verzeichnispfaden abhängig, um Versionen zu bestimmen?

Question

Ich habe ein bisschen Verwirrung hier bei der Arbeit. Ich und eine Handvoll Ingenieure sind der Meinung, dass nessus (soweit wir wissen, dass es sich um einen Portscanner handelt) sich nicht darum kümmern wird, dass ich das Tomcat-Verzeichnis auf unserem Server von /usr/java/apache-tomcat-5.5.33 umbenennen möchte nach/usr/java/apache-tomcat.

Ich möchte dies tun, um das Leben für die nächste Zeit zu erleichtern, wenn wir gezwungen sind, unsere Server zu aktualisieren, wenn ein Kunde "Vulnerability!" Ruft.

Also noch einmal, wenn ich den Tomcat-Server-Pfad generisch machen möchte, wird Nessus ein Bit nicht interessieren. Dieses Produkt (Nessus) wird in der Lage sein, die Produktversion gut zu verstehen.

Ist das korrekt?

Vielen Dank für die Hilfe.

-dklotz

-edit- Hier ist der Scan uns durch den Kunden berichtet.

Apache Tomcat 5.5.x < 5.5.34 Multiple Vulnerabilities Category: Web Servers 
Description: 

According to its self-reported version number, the instance of Apache 
Tomcat 5.5.x listening on the remote host is earlier than 5.5.34 and 
is affected by multiple vulnerabilities: 

    - Several weaknesses were found in the HTTP Digest 
    authentication implementation. The issues are as 
    follows: replay attacks are possible, server nonces 
    are not checked, client nonce counts are not checked, 
    'quality of protection' (qop) values are not checked, 
    realm values are not checked and the server secret is 
    a hard-coded, known string. The effect of these issues 
    is that Digest authentication is no stronger than Basic 
    authentication. (CVE-2011-1184, CVE-2011-5062, 
    CVE-2011-5063, CVE-2011-5064) 

    - An error handling issue exists related to the 
    MemoryUserDatabase that allows user passwords to be 
    disclosed through log files. (CVE-2011-2204) 

    - An input validation error exists that allows a local 
    attacker to either bypass security or carry out denial 
    of service attacks when the APR or NIO connectors are 
    enabled. (CVE-2011-2526) 

    - A component that Apache Tomcat relies on called 'jsvc' 
    contains an error in that it does not drop capabilities 
    after starting and can allow access to sensitive files 
    owned by the super user. Note this vulnerability only 
    affects Linux operating systems and only when 'jsvc' is 
    compiled with libpcap and the '-user' parameter is 
    used. (CVE-2011-2729) 

    - Specially crafted requests are incorrectly processed by 
    Tomcat and can cause the server to allow injection of 
    arbitrary AJP messages. This can lead to authentication 
    bypass and disclosure of sensitive information. Note 
    this vulnerability only occurs when the 
    org.apache.jk.server.JkCoyoteHandler AJP connector is 
    not used, POST requests are accepted, and the request 
    body is not processed.(CVE-2011-3190) 

Note that Nessus did not actually test for the flaws but instead has 
relied on the version in Tomcat's banner or error page. 

    Vuln Publication Date: 6/27/2011 
Plugin Publication Date: 9/26/2011 
Easy to Exploit: Exploits are available 
Exploit Available: true 
CVSS Vector: CVSS2#AV:N/AC:L/Au:N/C:P/I:P/A:P 
CVSS Base Score: 7.5 
CVSS Temporal Vector: CVSS2#E:F/RL:OF/RC:C 
CVSS Temporal Score: 6.2 
CVE: CVE-2011-1184 
CVE-2011-2204 
CVE-2011-2526 
CVE-2011-2729 
CVE-2011-3190 
CVE-2011-5062 
CVE-2011-5063 
CVE-2011-5064 

Cross Reference: OSVDB:73429 
OSVDB:73797 
OSVDB:73798 
OSVDB:74541 
OSVDB:74818 
OSVDB:76189 

See Also: http://tomcat.apache.org/security-5.html#Fixed_in_Apache_Tomcat_5.5.34 

Bug Traq ID: 48456 
48667 
49143 
49353 
49762 

Answer 1

:: Antwort Kommentar machen ::

, dass die tatsächliche Verwundbarkeit Bericht ist. Wenn es die Informationen vom Tomcat-Banner bekommen hat, könnte es das über den offenen Web-Service-Port getan haben, in diesem Fall gibt es keine Zugangsdaten und es ist egal, wo das Tomcat-Verzeichnis tatsächlich lebt. Das bedeutet nicht, dass es keine Anmeldeinformationen gibt, aber es bedeutet einfach, dass es diese Informationen ohne sie erhalten hat. Sie könnten versuchen, es zu verschieben und erneut zu scannen, um zu sehen, ob es den Fehler entdeckt, oder den Scan bearbeiten und den Abschnitt "Richtlinie/Berechtigungsnachweis" auswählen. Sie können sehen, ob für diesen bestimmten Scan Anmeldeinformationen angegeben sind.

Credentialed Scans haben Login-Informationen, uncredentialed Scans nicht.

Ich sehe, dass Sie auch das Tenable Discussion Portal gefunden haben - ich wollte Sie als nächstes darauf hinweisen! :-) Ich stimme dem letzten Beitrag von George zu - "remote check" = "uncredentialed" in den Begriffen, die ich benutzt habe. HTH!