Does Nessus depend or use directory paths for determining versions?
문제
I have a bit of confusion going on here at work. I and a handful of engineers believe that nessus (being a port scanner as far as we know) won't care one bit that I wish to rename the tomcat directory on our server from /usr/java/apache-tomcat-5.5.33 to /usr/java/apache-tomcat.
I wish to do this to make life easier for the next time we are forced to upgrade our servers when a customer cries "Vulnerability!".
So again, if I wish to make the tomcat server path generic, Nessus won't care one bit. That product (Nessus) will be able to sniff out the product version just fine.
Is that correct?
Thank you for the help.
-dklotz
-edit- Here is the scan reported to us by the customer.
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
해결책
::making answer from comment::
That's the actual vulnerability report. If it got the info from the tomcat banner, it could have done that through the open web service port, in which case there are no credentials and it doesn't care where the tomcat directory actually lives. That doesn't mean that there aren't credentials, though, it just means it's possible it got that info without them. You could try moving it and rescanning to see if it detects the vuln, or edit the scan and select the "Policy / Credential" section, you can see if there are credentials specified for that particular scan.
Credentialed scans have login information, uncredentialed scans do not.
I see you also found the Tenable Discussion Portal - I was going to point you there next! :-) I agree with George's last post - "remote check" = "uncredentialed" in the terms I've been using. HTH!