Tag Archives: nuclei

The Vulners team has released nmap-vulners 2.0

Leave a reply

The Vulners team has released nmap-vulners 2.0

The Vulners team has released nmap-vulners 2.0. This plugin (an NSE script) turns the popular Nmap port scanner into a black-box vulnerability scanner. Simply run $ nmap -sV --script vulners <target> to get a prioritized report on vulnerabilities and exploits. And all of this is available for free with no limitations. 🆓😉

How exactly does this plugin work?

To find vulnerabilities, the software is identified first:

🔹 The service's CPE identifier may be provided by Nmap itself (using the -sV option).

🔹 If Nmap fails to identify the service, the plugin attempts to determine the CPE identifier from the raw banner using rules for FTP, SMTP, SSH, MySQL, DNS, NTP, LDAP, and other services. Starting with version 2.0, the fingerprint catalog is updated weekly based on Recog, Wappalyzer, WhatWeb, FingerprintHub, and nuclei-templates. The latest catalog is automatically fetched when the plugin runs.

🔹 If an HTTP service is detected, nmap-vulners also attempts to identify the web stack, including the framework, CMS, or PHP version behind a reverse proxy. It analyzes Server and X-Powered-By headers, cookies, the page title, meta tags, filenames in script src, and page content. The plugin includes more than 700 rules. In version 2.0, the number of HTTP path fingerprints increased from 125 to 939, while parallelization kept the processing time at around 6 seconds per port.

🔹 If a product is identified but its version is unknown, the plugin makes a single request to a known file that contains version information, such as /CHANGELOG.txt for Drupal or /administrator/manifests/files/joomla.xml for Joomla. This works with Concrete5, Drupal, Jira, Joomla, Apache Tomcat, and WordPress.

🔹 Finally, if a service cannot be identified, Smart Audit can be used. The raw banner is sent to the Vulners server, which identifies the software and its version and then looks for related vulnerabilities. This is the only paid feature! Each unique request costs 1 credit, and results are cached. The number of requests is limited by the vulners.max_items parameter, which defaults to 32. Smart Audit can be disabled entirely with --script-args vulners.max_items=0.

The service data is then sent to the Vulners server, which returns a prioritized vulnerability report. For each vulnerability or exploit, the report includes its ID, SEVERITY level, CVSS and EPSS scores, Vulners AI score, KEV and EXP flags, and a link to its page on the Vulners website.

So, is an API key actually required?

🔹 The plugin can work without an API key. However, detection will use the legacy endpoint, and some vulnerability and exploit data will not be available.

🔹 Adding an API key, even without credits, enables the "EXP" flag for vulnerabilities and the "KEV" flag for both vulnerabilities and exploits. It also adds an EPSS score column, providing more complete prioritization: KEV → CISA SSVC Exploitation Active → exploits → EPSS → CVSS. So, an API key is recommended. 😉

🔹 If your API key has credits, the Smart Audit feature is also available (see above).

Installation

To install the plugin, simply run the one-line script. The installer automatically finds Nmap and its NSE script directory, installs the latest vulners.nse version, and removes old 1.x files. It then runs nmap --script-updatedb and verifies the installation. The --user and --prefix options let you specify the installation directory, while --uninstall removes the plugin. If needed, the installer prompts for a Vulners API key, validates it, and saves it to ~/.nmap/vulners.key with permissions set to 600.

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

Leave a reply

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

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.

На русском