Let's understand one use case.
Apache published a new version of HTTP server i.e. v2.4.55 (https://httpd.apache.org/download.cgi). Now, if you check the version of Apache HTTP servers which are shipped with Redhat, you would find upstream versions are on or below v2.4.53 (https://access.redhat.com/solutions/445713).
Now, Tenable started detecting versions 2.4.x < 2.4.55 as vulnerable to CVE-2006-20001, CVE-2022-36760, CVE-2022-37436 (https://www.tenable.com/plugins/nessus/170113). But these web servers are only vulnerable when "mod_proxy_ajp" module is in use. Solution to this vulnerability is to disable the module (https://access.redhat.com/security/cve/cve-2022-36760). However, even after disabling the module, Tenable will continue to flag the vulnerability as it is not checking whether the module is in use or not.
You can use the command "apache2ctl -M" to check for loaded modules of Apache in Linux systems (https://www.tecmint.com/check-apache-modules-enabled/).
Hence, from my perspective you have the following options:
1. Recast the risk of the vulnerability from "Critical" to "Medium"/"Low" so that it doesn't get counted in any KPI metric
2. Provide temporary exception for 4 or 6 months
So, whenever you come across detections based on application's self-reported version number, be vigilant and perform proper vulnerability analysis.
Happy Learning !!
No comments:
Post a Comment