Dear users,
I’m having a problem regarding detecting a certain vulnerability on a host. I’ll explain the situation to you.
I ran a scan on a first IP address:
xxx.xxx.xx.17 with both Nessus and OpenVAS and here the vulnerability CVE-2016-2183(SWEET32) is detected by both, cataloged by both as a critical vulnerability.
I ran a second scan on another host:
xxx.xxx.xx.40, here the vulnerability is detected only by Nessus, and not by OpenVAS (but openVAS already knows it and is able to find it, because it is present in its database and because in the host xxx.xxx.xx. 17 is found and detected). Scans were performed without credentials and unauthenticated scans, for both .40 and .17
These are the steps I took to try to resolve, and I still haven’t succeeded:
I lowered the scan quality up to 30% (my thought was that the vulnerability was found by OpenVAS but not reported because it was “afraid” of not being too accurate, i.e. I thought that opnVAS detected it as a false positive)
I changed and inserted all the ports
-Full and fast scanning
-Updated OpenVAS to the latest version
-Tried a scan on both hosts with both tools at the same time
I have the latest version
Can you help me?
When these cases occur, where OpenVAS does not detect certain vulnerabilities, even critical ones, which however are present in its database, what can I do?
the port is in the used port list and the service is identified by the previous port scan
no outdated version of the scanner / software stack affected by this is in use
a few guesses:
the service in question is “overloaded” during a scan and doesn’t respond in an adequate time
network congestion, IPS/IDS or WAF devices and similar network security equipment can play a role
the service in question is not a HTTP(s) one
About Nr. 3:
As the name of the VT “SSL/TLS: Report Vulnerable Cipher Suites for HTTPS” (OID: 1.3.6.1.4.1.25623.1.0.108031) which is detecting and reporting systems affected by SWEET32 “remotely” says a reporting is only happening for HTTP(s) services.
To the best of our knowledge there are no real world attacks / scenarios for this flaw against Non-HTTP services so SWEET32 itself is only reported for HTTP(s) services currently / until otherwise proofed.
Note that DES / 3DES ciphers (the ones actually affected by SWEET32) are also generally reported by the following and for all services as well:
Hi @cfi, thank you very much for your availability and for the completeness of your answer.
Indeed, in the host xxx.xxx.xx.41, these vulnerabilities are reported:
So the one you mentioned is present, and looking at the port it is 3389/tcp, so it is not an http(s) service
In host xxx.xxx.17, where both Nessus and OpenVAs detect the SWEET32 vulnerability (complete with CVE reported in the header), we are talking about port 443
So it is an https service, in fact it is found by openvas
Now I’ll ask you one last question, just for completeness and curiosity: why and how does Nessus detect it and mark it as SWEET32 (complete with CVE) if we are not actually talking about an HTTPS(s) service? What is the logic behind it?
Unfortunately i don’t have any insights in the rationales / background decisions done for other scanners / tools which would be required for answering this question.
