Install Nmap-Vulners & Vulscan

➟ To install the nmap-vulners script, we'll first use cd to change into the Nmap scripts directory.

cd /usr/share/nmap/scripts/

Then, clone the nmap-vulners GitHub repository by typing the below command into a terminal. That's it for installing nmap-vulners. There's absolutely no configuration required after installing it.

git clone https://github.com/vulnersCom/nmap-vulners.git

➟ To install vulscan, we'll also need to clone the GitHub repository into the Nmap scripts directory.

git clone https://github.com/scipag/vulscan.git

Vulscan utilizes preconfigured databases that are stored locally on our computer. We can view these databases in the root of the vulscan directory. Run the below ls command to list the available databases:

ls vulscan/*.csv

vulscan/cve.csv
vulscan/exploitdb.csv
vulscan/openvas.csv
vulscan/osvdb.csv
vulscan/scipvuldb.csv
vulscan/securityfocus.csv
vulscan/securitytracker.csv
vulscan/xforce.csv

Vulscan supports a numbered of excellent exploit databases:

➥ scipvuldb.csv;

➥ cve.csv;

➥ osvdb.csv;

➥ securityfocus.csv;

➥ securitytracker.csv;

➥ xforce.csv;

➥ expliotdb.csv;

➥ openvas.csv.

To ensure that the databases are fully up to date, we can use the updateFiles.sh script found in the vulscan/utilities/updater/ directory. Change into the updater directory by typing the below command into a terminal.

cd vulscan/utilities/updater/

Then, make sure the file has the proper permissions to execute on your computer with the below chmod command.

chmod +x updateFiles.sh

We can then execute and run the script by entering the below command into our terminal.

./updateFiles.sh

With that done, we're now ready to start using the NSE scripts.

❚ Scan Using Nmap-Vulners

Using NSE scripts is simple. All we have to do is add the --script argument to our Nmap command and tell Nmap which NSE script to use. To use the nmap-vulners script, we would use the below command. Of course, change the # to the port of your scanning.

nmap --script nmap-vulners -sV -p# 10.0.0.1

The -sV is absolutely necessary. With -sV, we're telling Nmap to probe the target address for version information. If Nmap doesn't produce version information, nmap-vulners won't have any data to query the Vulners database. Always use -sV when using these NSE scripts.

nmap --script nmap-vulners -sV -p80 10.0.0.1

PORT    STATE   SERVICE VERSION
22/tcp  open    http    nginx 1.0.15
|_http-server-header: nginx/1.0.15
| vulners:
|   cpe:/a:igor_sysoev:nginx:1.0.15:
|       CVE-2013-4547           7.5             https://vulners.com/cve/CVE-2013-4547
|_      CVE-2013-0337           7.5             https://vulners.com/cve/CVE-2013-0337

❚ Scan Using Vulscan

We can use the vulscan NSE script in the same exact way as nmap-vulners:

nmap --script vulscan -sV -p# 10.0.0.1

By default, vulscan will query all of the previously mentioned databases at once! As we can see in the below code box, it's an overwhelming amount of information to digest. It's really more information than we need.

nmap --script vulscan -sV -p22 10.0.0.1

PORT    STATE   SERVICE VERSION
22/tcp  open    ssh     OpenSSH 4.3 (protocol 2.0)
| vulscan: scip VulDB - http://www.scip.ch/en/?vuldb:
| [44077] OpenBSD OpenSSH up to 4.3 Signal denial of service
| [39331] OpenBSD 4.3p2 Audit Log linux_audit_record_event unknown vulnerability
| [32512] OpenBSD OpenSSH up to 4.3 unknown vulnerability
| [43307] OpenBSD 4.0 unknown vulnerability
| [41835] OpenBSD up to 4.8 unknown vulnerability
| [38743] OpenBSD up to 4.6 unknown vulnerability
| [36382] OpenBSD OpenSSH up to 4.6 information disclosure
| [32699] OpenBSD OpenSSH 4.1 denial of service
| [2667] OpenBSD OpenSSH 4.4 Separation Monitor Designfehler
| [2578] OpenBSD OpenSSH up to 4.4 Singal race condition
| [32532] OpenBSD OpenSSH 4.5 packet.c denial of service
| [1999] OpenBSD OpenSSH up to 4.2pl scp system() Designfehler
| [1724] OpenBSD OpenSSH 4.0 GSSAPIDelegateCredentials Designfehler
| [1723] OpenBSD OpenSSH 4.0 Dynamic Port Forwarding Designfehler
| [26219] OpenBSD OpenSSH up to 4.1 pl information disclosure
| [16020] OpenBSD OpenSSH 4.5 Format String
|
| MITRE CVE - http://cve.mitre.org:
| [CVE-2009-2904] A certain Red Hat modification to the ChrootDirectory feature in OpenSSH 4.8, as used in sshd in OpenSSH 4.3 in Red Hat Enterprise Linux (RHEL) 5.4 and Fedora 11, allows local users to gain privileges via hard links to setuid programs that use configuration files within the chroot directory, related to requirements for directory ownership.
| [CVE-2008-4109] A certain Debian patch for OpenSSH before 4.3p2-9etch3 on etch
| [CVE-2008-1483] OpenSSH 4.3p2, and probably other versions, allows local users to hijack forwarded X connections by causing ssh to set DISPLAY to :10, even when another process is listening on the associated port, as demonstrated by opening TCP port 6010 (IPv4) and sniffing a cookie sent by Emacs.
| [CVE-2007-3102] Unspecified vulnerability in the linux_audit_record_event function in OpenSSH 4.3p2, as used on Fedora Core 6 and possibly other systems, allows remote attackers to write arbitrary characters to an audit log via a crafted username. NOTE: some of these details are obtained from third party information.
| [CVE-2010-4755] The (1) remote_glob function in sftp-glob.c and the (2) process_put function in sftp.c in OpenSSH 5.8 and earlier, as used in FreeBSD 7.3 and 8.1, NetBSD 5.0.2, OpenBSD 4.7, and other products, allow remote authenticated users to cause a denial of service (CPU and memory consumption) via crafted glob expressions that do not match any pathnames, as demonstrated by glob expressions in SSH_FXP_STAT requests to an sftp daemon, a different vulnerability than CVE-2010-2632.
| [CVE-2008-3844] Certain Red Hat Enterprise Linux (RHEL) 4 and 5 packages for OpenSSH, as signed in August 2008 using a legitimate Red Hat GPG key, contain an externally introduced modification (Trojan Horse) that allows the package authors to have an unknown impact. NOTE: since the malicious packages were not distributed from any official Red Hat sources, the scope of this issue is restricted to users who may have obtained these packages through unofficial distribution points. As of 20080827, no unofficial distributions of this software are known.

Is highly recommend querying just one database at a time. We can achieve this by adding the vulscandb argument to our Nmap command and specifying a database as shown in the below examples.

nmap --script vulscan --script-args vulscandb=database_name -sV -p# 10.0.0.1
nmap --script vulscan --script-args vulscandb=scipvuldb.csv -sV -p# 10.0.0.1
nmap --script vulscan --script-args vulscandb=exploitdb.csv -sV -p# 10.0.0.1
nmap --script vulscan --script-args vulscandb=securitytracker.csv -sV -p# 10.0.0.1

Here's an example of one of those in use:

nmap --script vulscan --script-args vulscandb=exploitdb.csv -sV -p22 10.0.0.1

PORT    STATE   SERVICE VERSION
22/tcp  open    ssh     OpenSSH 4.3 (protocol 2.0)
| vulscan: exploitdb.csv:
| [2444] OpenSSH <= 4.3 pl (Duplicated Block) Remote Denital of Service Exploit
| [21402] OpenSSH s.x/3.x Kerberos 4 TGT/AFS Token Buffer Overflow Vulnerability
| [3303] Portable OpenSSH <= 3.6.1p-PAM / 4.1-SUSE Timing Attack Exploit
|
|_

As lead architect of VulDB, the vulscan developer usually finds time to update the scipvuldb.csv database file. Querying that database will probably produce the best results when using the vulscan NSE script.

❚ Combine into One Command

NSE scripts significantly improve Nmap's versatility, range, and resourcefulness as a security scanner. To get the most out of Nmap's version scans, we can use both nmap-vulners and vulscan in one command. To go this, type the below command into your terminal.

nmap --script nmap-vulners,vulscan --script-args vulscandb=scipvuldb.csv -sV -p# 10.0.0.1