Dear users,
I’m running scans with OpenVAS and another paid commercial software, on the same host to see if they both find the same vulnerabilities.
I attach an image:
Where you see the table cells on the left and right it means that both have detected the same vulnerability (it doesn’t matter if they catalog it differently). I also brought you the doors.
Where you don’t see anything, for example only the writing on Nessus and not on OpenVAS means that in the report of this host I found nothing referring to the vulnerability.
In the case I presented above, Nessus detects vulnerabilities that relate to X.509 SSL certificates that cannot be trusted, Self Signed certificates, certificates with incorrect hostnames, and there is also a vulnerability related to NLA.
OpenVAS only detects that deprecated versions of SSL and TLS are being used.
My question is: why doesn’t OpenVAS refer to X.509 certificates or CAs? How can I solve it?
I tell you that:
I have the latest version of OpenVAS installed, 22.7.5, gvm-libs 22.7.1
I updated the plugins
Performed scans on the same host at the same time or at very close intervals
OpenVAS scan QoD at 40%
I would like to know this, how to solve this problem.
What I thought is that when OpenVAS mentions SSL/TLS: Deprecated TLSv1.0 and TLSv1.1 detection it also refers to untrusted X.509 certificates…but if you also look at the ports where Nessus and OpenVAS detect vulnerabilities, they are also they are different, there are some different ones.
Please note most of the certificate findings are NOT a security Issues. Note that all these finding with the Score from Nessus have a wrong Score.
6.5 Medium and 5.3 is more or less with CVE metric BS then a vulnerability.
You might be able to find the certificate meta-data as “Log-” within your GVM toolchain.
As well there is NO singe authority to tell you what root CA is trusted and what is not, so all this results are BS as well.
I see Lukas’ point here. Is a self-signed certificate a security vulnerability? Not really. It’s used to setup an encrypted connection and a weak algorithm or certificate type (aka strength) is more significant to security but not whether it’s self signed. Greenbone identifies these weaknesses on par with Nessus.
For example of how self-signed is very secure, SSH keypairs are self-generated and the verifying the fingerprint on first connection is sufficient to establish a secure connection - many critical connections depends on this.
Unless you are talking about a public service such as a website that depends on validating the domain so you know you are connecting to the actual domain you think you are. That’s more of a user-level issue than the type of concern that a sysadmin or security team would have when scanning their own services for vulnerabilities. The admins should know whether the certs are self-signed already and saying self-signed is a security vulnerability sounds like a way to just sell certs from “trusted CAs”.
Once you start to consider users surfing the web into the equation, they should care the cert is not only issued by a trusted certificate authority, but actually, whether the certificate has changed since the last time you visited the website - or service and especially whether the issuer has changed. Some countries have state-sponsored certificate authorities that are included in major browsers’ trusted certificate cache. This means the state-sponsored ISP could swap out the website’s cert and MiTM a connection and your browser wouldn’t raise a red flag. In this case a VPN tunnel with a self-signed certificate to an endpoint in a country without surveillance would prevent this. In other words, what is considered the “trusted CA” (at least for major browsers’ trusted CA cache) is very untrustworthy and an actual security risk.
However, these types of security issues are not typically the concern of sysadmins or vulnerability scanners. What security teams should do is verify that they recognize all of the certificates from the scan report’s certificate tab.
Especially reading the description of the MEDIUM SSL “Certificate Cannot Be Trusted” vulnerability, these three scenarios presented are completely different and it doesn’t make sense to lump them into a single umbrella and assign a CVSS score.
