Hello everyone! In my English-language telegram chat avleonovchat, the question was asked: “How to find zero day vulnerabilities with Qualys?” Apparently this question can be expanded. Not just with Qualys, but with any VM solution in general. And is it even possible? There was an interesting discussion.

Alternative video link (for Russia): https://vk.com/video-149273431_456239109

Image generated by Stable Diffusion 2.1: “calendar on the wall cyber security vulnerability zero day”

The question is not so straightforward. To answer it, we need to define what a Zero Day vulnerability is. If we look at wikipedia, then historically “0” is the number of days a vendor has to fix a vulnerability.

“Eventually the term was applied to the vulnerabilities that allowed this hacking, and to the number of days that the vendor has had to fix them.”

If an irresponsible researcher publishes a complete vulnerability study (full disclosure) without informing the vendor at all, it will be a classic Zero Day. There are no questions here. But let’s take a closer look:

• Is such a vulnerability Zero Day until the moment of public disclosure?
• If a responsible researcher informs the vendor, is the vulnerability Zero Day from the moment the researcher discovers it, until the moment it is reported to the vendor, and during patch development by the vendor?
• If the vulnerability was Zero Day, then is it correct to continue calling such a vulnerability Zero Day after the release of the patch by the vendor?

There are different opinions and definitions:

1. Trendmicro: “A zero-day vulnerability is a vulnerability in a system or device that has been disclosed but is not yet patched“.
2. Kaspersky: “A zero-day vulnerability is a software vulnerability discovered by attackers before the vendor has become aware of it.”
3. Portswigger: “A zero-day (0day) vulnerability refers to a security vulnerability for which no mitigation or patch is available at the time it is disclosed or made public“.
4. ScienceDirect: “Zero-day vulnerability is defined as a security flaw that has not yet been disclosed to the vendor or developers”.

As we can see, according to some definitions, disclosure is required to classify a vulnerability as a Zero Day, but according to others, it is probably not.

• The NIST glossary does not contain the term “zero day vulnerability”.
• In the FSTEC glossary “Уязвимость нулевого дня” (Zero-day vulnerability) is “a vulnerability that becomes known before the information system software developer releases information protection measures to eliminate it, bug fixes or appropriate updates”. Here it is not quite clear “becomes known” to a wide circle of people or even to one researcher?

Personally, I do NOT like the idea of naming a vulnerability Zero Day only at the time of its publication. Why? Let’s say we define it this way. And someone was covertly maliciously exploiting a vulnerability (like Eternalblue before the NSA leak). We cannot say that this was a Zero Day vulnerability exploitation. There was no publication (yet)! Although obviously it was precisely the exploitation of the Zero Day vulnerability.

Ok, we can tweak the definition. We can say that either publication or exploitation is needed. And what type of exploitation? Here is a researcher who found a vulnerability. During the research, this researcher obviously somehow exploited / tested this vulnerability. It turns out that we need not ordinary exploitation, but malicious one. How to define maliciousness? This creates confusion.

Therefore, it seems to me that it is easier and more consistent to consider any vulnerability as a Zero Day until a fix from the vendor (patch or workaround) appears. After the publication of the fix, calling the vulnerability Zero Day is justified only if we are talking about some past events when the fix did not yet exist.

If we agree to interpret Zero Day vulnerabilities so broadly, then we can consider the following types:

1. Public vulnerabilities for which there was no patch from the software vendor at the time of its publication (for example, ProxyNotShell). Such vulnerabilities can sometimes be detected by Vulnerability Management solutions. BUT the VM vendor has to put extra effort into this. Most vulnerability detection rules work by checking the installed patches or by checking the software/package versions. Since there is no patch that fixes the vulnerability yet, it means that the vulnerability needs to be detected in some other way. For example, a VM solution may attempt to exploit a vulnerability. Developing such detection rules is manual work that requires a lot of effort.
2. Non-public vulnerabilities that someone knows about and may be exploiting, but not known to the software vendor (e.g. EternalBlue before the NSA leak). Such vulnerabilities are likely to be found in some private vulnerability databases. It is impossible to detect such vulnerabilities using a VM solution. EDR solutions and SOC techniques can help detect exploitation of such vulnerabilities to some extent.
3. Non-public vulnerabilities that no one knows about at all. The VM solution will also not be able to detect such vulnerabilities. This is about software research and SAST/DAST/IAST solutions.

So can VM solutions detect Zero Day vulnerabilities? Yes, in some cases VM solutions can detect some Zero Day vulnerabilities. It will be an ordinary vulnerability scan with filtering by “vulnerability without a patch”. But the vulnerabilities detected in this way will be only a small part of all Zero Day vulnerabilities (in the sense that we defined them above). VM solutions are designed to work with known vulnerabilities for which patches have already been released. It is these vulnerabilities (and not Zero Day!) are the main reason why companies are hacked. Zero Day vulnerabilities are still used quite rarely and mainly in targeted attacks.