Detection of known (CVE) vulnerabilities without authentication (in Pentest mode): overkill or necessity? There is an opinion that when detecting vulnerabilities in internal infrastructure, scanning without authentication is not necessary at all. That it is enough to install agents on the hosts. And those hosts where agents cannot be installed, for example network devices, just need to be scanned with authentication. They say scans without authentication are always less reliable than scans with authentication, and they are needed only for perimeter scanning or primary network inventory. In my opinion, this is not completely correct. Scanning without authentication for known vulnerabilities is mandatory, especially when the target is a host running a web application.
And this is due to the peculiarities of detecting vulnerabilities during scanning with authentication. Let’s take Linux hosts. Typically, VM vendors when scanning Linux hosts with authentication, limit themselves to detecting vulnerabilities in packages from the official Linux vendor repository. 🤷♂️ Simply because these vulnerabilities are described in publicly available security bulletins or even as formalized OVAL content. It’s convenient. If you have learned to work with such content, you can check the box that the Linux distribution is supported by the VM solution. What about vulnerabilities for software that is not in the official Linux vendor repository? This is where things get more complicated.
This software can be installed:
🔹 From a connected third-party Linux software repository
🔹 From a package (made by some vendor or selfbuilt) of the standard package system for this Linux distro (deb, rpm), brought to the host manually
🔹 From alternative packages for software distribution (snap, flatpak, appimage, etc.)
🔹 From module distribution tools (pip, conda, npm, etc.)
🔹 From a container image (docker, podman, etc.)
🔹 From software source codes; the software can be built directly on the target host or can be transferred there as binary files.
Ideally, no matter how the software is installed on a host, a vulnerability scanner should correctly detect that software installation, determine the version, and identify associated vulnerabilities based on the version. 🧙♂️ But in practice, due to the fact that there are many ways to install software, this is a very non-trivial task. 🧐
As a result, we get a situation: let’s say we have some kind of commercial or open source software on a Linux host (Zabbix, GitLab, Confluence, Jira). This software is not easy to reliably find simply by exploring the host from the inside via SSH. And when looking at the host from the outside, searching for this software is trivial: we scan the ports, find the web-GUI, often find the version directly on the main page and use it to detect vulnerabilities. At the same time, we are not at all dependent on the specific method of installing and running the software on the host. The main thing is that we see the web interface of the application itself. 🤩
Such “external” rules for detecting vulnerabilities are much easier to develop. You can also use ready-made expertise. Fingerprinting to obtain a CPE ID combined with a CPE lookup in NVD is, of course, a dirty path. But this allows you to add vulnerability detection rules in large quantities. 😏 And if you can tweak both the fingerprint and the CPE detection rules, then the number of errors can be reduced to an acceptable level. And if you also add validation of vulnerabilities with an exploitation attempt (for example, using nuclei), then a significant set of vulnerabilities can be detected more than reliably. 😉
So, scanning for known vulnerabilities without authentication (“pentest”) is a must have for internal infrastructure as well, especially for hosts with web applications.