As you probably know by now, the applications of NSE cover a wide range of tasks. Nmap gives access to NSE developers to a "host and port" table containing relevant information collected during the scan, such as service name, operating system, protocol, and so on. The information available depends on the options used during the scan.
Unfortunately, there is not enough space in one chapter to cover all the great NSE scripts. If you are interested in learning more applications, I recommend checking out my previous book named Nmap 6: Network Exploration and Security Auditing Cookbook, Paulino Calderón Pale, Packt Publishing, where I covered in detail over 120 different tasks that can be done with Nmap. Its official website is at http://nmap-cookbook.com.
Information-gathering is one of the strengths of NSE, and the collection of scripts available is astonishing. These scripts use different techniques and data sources to obtain additional host information such as virtual hosts, service versions, user lists, and even geolocation. Keep in mind that some of these scripts query external services, and the accuracy of the information depends on each database.
UPNP protocols were designed to allow network devices to find each other, and some serious flaws have been discovered in a lot of implementations of these sets of protocols. The upnp-info script was designed to query a UPNP service to obtain additional information about the device:
#nmap -sU -p1900 --script upnp-info <target>
If the preceding command runs successfully, the amount of information returned by the service depends on the type of device and UPNP implementation:
Nmap scan report for 192.168.1.1 Host is up (0.067s latency). PORT STATE SERVICE 1900/udp open upnp | upnp-info: | 192.168.1.1 | Server: Custom/1.0 UPnP/1.0 Proc/Ver | Location: http://192.168.1.1:5431/dyndev/uuid:3872c05b-c117-17c1-5bc0-12345 | Webserver: LINUX/2.4 UPnP/1.0 BRCM400/1.0 | Name: Broadcom ADSL Router | Manufacturer: Comtrend | Model Descr: (null) | Model Name: AR-5381u | Model Version: 1.0 | Name: WANDevice.1 | Manufacturer: Comtrend | Model Descr: (null) | Model Name: AR-5381u | Model Version: 1.0 | Name: WanConnectionDevice.1 | Manufacturer: Comtrend | Model Descr: (null) | Model Name: AR-5381u |_ Model Version: 1.0
The hostmap-* set of scripts lists all the hostnames pointing to the same IP address. This is useful when working with web servers that return different content depending on the hostname header. Currently, there are three scripts:
hostmap-bfkhostmap-robtexhostmap-ip2hosts
We can run them at the same time with the following command:
$nmap -sn --script "hostmap*" <target>
If there are any records on the external databases, they will be shown in the results:
Nmap scan report for packtpub.com (83.166.169.228) Host is up (0.13s latency). Host script results: | hostmap-bfk: | hosts: | packtpub.com |_ 83.166.169.228 | hostmap-robtex: | hosts: |_ packtpub.com | hostmap-ip2hosts: | hosts: | www.packtpub.com | packtpub.com |_ 83.166.169.228
The flexibility of allowing pre-scanning and post-scanning scripts gives us the ability to include targets on-the-fly, analyze scan results, and even launch additional probes to detect more target hosts. The broadcast NSE category collects a very interesting set of scripts that doesn't send traffic directly to the target host using multicast requests. On the other hand, some scripts (such as targets-sniffer) merely listen to the local network to find new targets, without generating any traffic.
The broadcast-ping script attempts to discover hosts by sending a ping request to the broadcast address, 255.255.255.255. The machines configured to respond to broadcast requests will reveal themselves:
# nmap --script broadcast-ping Pre-scan script results: | broadcast-ping: | IP: 192.168.1.202 MAC: 08:00:27:16:4f:71 | IP: 192.168.1.206 MAC: 40:25:c2:3f:c7:24 |_ Use --script-args=newtargets to add the results as targets WARNING: No targets were specified, so 0 hosts scanned. Nmap done: 0 IP addresses (0 hosts up) scanned in 3.25 seconds
All the hosts that responded to the broadcast ping will be shown. Additionally, using the newtargets argument, these hosts will be added to the scan queue:
# nmap --script broadcast-ping --script-args newtargets Starting Nmap 6.47SVN ( http://nmap.org ) at 2014-11-30 22:05 CST Pre-scan script results: | broadcast-ping: |_ IP: 192.168.0.8 MAC: 6c:ad:f8:7b:83:ab Nmap scan report for 192.168.0.8 Host is up (0.0083s latency). Not shown: 998 closed ports PORT STATE SERVICE 8008/tcp open http 8009/tcp open ajp13 MAC Address: 6C:AD:F8:7B:83:AB (Azurewave Technologies)
The targets-sniffer script is very peculiar because it is one of the few scripts that actually sniff a LAN network in order to discover new local targets. This script requires privileged mode and that you set the interface for use with the -e Nmap option:
#nmap -sL --script=targets-sniffer -e <interface> Starting Nmap 6.47SVN ( http://nmap.org ) at 2014-11-30 22:11 CST Pre-scan script results: | targets-sniffer: Sniffed 4 address(es). | 17.172.239.128 | 192.168.0.2 | 239.255.255.250 |_192.168.0.8 WARNING: No targets were specified, so 0 hosts scanned. Nmap done: 0 IP addresses (0 hosts up) scanned in 10.20 seconds
Optionally, these targets can also be added to the scanning queue on the fly:
#nmap -sL --script=targets-sniffer --script-args=newtargets -e <interface> Starting Nmap 6.47SVN ( http://nmap.org ) at 2014-11-30 22:15 CST Pre-scan script results: | targets-sniffer: Sniffed 5 address(es). | 224.0.0.251 | fe80::7a31:c1ff:fec1:9c0a | 192.168.0.8 | 192.168.0.2 |_239.255.255.250 Nmap scan report for 192.168.0.8 Host is up (0.0066s latency). Not shown: 98 closed ports PORT STATE SERVICE 8008/tcp open http 8009/tcp open ajp13 MAC Address: 6C:AD:F8:7B:83:AB (Azurewave Technologies) Nmap scan report for 192.168.0.2 Host is up (0.0033s latency). Not shown: 99 closed ports PORT STATE SERVICE 49152/tcp open unknown MAC Address: 00:18:F5:0F:AD:01 (Shenzhen Streaming Video Technology Company Limited) Nmap done: 4 IP addresses (2 hosts up) scanned in 16.01 seconds
Brute-force password-auditing scripts have grown to cover a lot of different services, thanks to the brute NSE library. This library allows NSE developers to easily launch dictionary attacks by implementing a simple class that uses other NSE libraries such as unpwd, which gives access to a username and password database. If any credentials are found during the execution, they will be added to a credentials database that can be read by other scripts.
The mysql-brute script will help us perform brute-force password auditing against local or remote MySQL servers. In most configurations, MySQL will not impose a limit of login retries, so this is a good vector for exploiting weak passwords:
$nmap -p3306 --script mysql-brute <target>
If any credentials are found, they will be included in the script output:
3306/tcp open mysql | mysql-brute: | root:<empty> => Valid credentials |_ test:test => Valid credentials
The smtp-brute script was written to help perform brute-force password-auditing attacks against SMTP servers, as the name states:
$nmap -p25 --script smtp-brute <target>
The output of this script is similar to that of other scripts that depend on the brute library:
PORT STATE SERVICE REASON 25/tcp open stmp syn-ack | smtp-brute: | Accounts | acc0:test - Valid credentials | acc1:test - Valid credentials | acc3:password - Valid credentials | acc4:12345 - Valid credentials | Statistics |_ Performed 3190 guesses in 81 seconds, average tps: 39
NSE offers a great framework for penetration testers who need to create tools to detect and exploit vulnerabilities. Nmap offers a lot of options such as low-level packet creation and handling, libraries used to communicate with the most popular protocols, and an interface to report vulnerabilities. For those who don't need to write new tools but simply want to scan their network, there are very useful scripts to detect common misconfigurations and automate tedious tasks such as finding forgotten backup files and performing security checks.
The mysql-audit script inspects the configuration of your MySQL server against a list of security controls. This script requires that you set up some arguments:
$nmap -p3306 --script mysql-audit --script-args 'mysql-audit.username="<username>",mysql-audit.password="<password>",mysql-audit.filename=/usr/local/share/nmap/nselib/data/mysql-cis.audit' <target>
Each control in the database will be audited. The following are the results of a clean MySQL server installation on an Ubuntu server:
PORT STATE SERVICE 3306/tcp open mysql | mysql-audit: | CIS MySQL Benchmarks v1.0.2 | 3.1: Skip symbolic links => PASS | 3.2: Logs not on system partition => PASS | 3.2: Logs not on database partition => PASS | 4.1: Supported version of MySQL => REVIEW | Version: 5.1.41-3ubuntu12.10 | 4.4: Remove test database => PASS | 4.5: Change admin account name => FAIL | 4.7: Verify Secure Password Hashes => PASS | 4.9: Wildcards in user hostname => PASS | 4.10: No blank passwords => PASS | 4.11: Anonymous account => PASS | 5.1: Access to mysql database => REVIEW | Verify the following users that have access to the MySQL database | user host | root localhost | root builder64 | root 127.0.0.1 | debian-sys-maint localhost | 5.2: Do not grant FILE privileges to non Admin users => PASS | 5.3: Do not grant PROCESS privileges to non Admin users => PASS | 5.4: Do not grant SUPER privileges to non Admin users => PASS | 5.5: Do not grant SHUTDOWN privileges to non Admin users => PASS | 5.6: Do not grant CREATE USER privileges to non Admin users => PASS | 5.7: Do not grant RELOAD privileges to non Admin users => PASS | 5.8: Do not grant GRANT privileges to non Admin users => PASS | 6.2: Disable Load data local => FAIL | 6.3: Disable old password hashing => PASS | 6.4: Safe show database => FAIL | 6.5: Secure auth => FAIL | 6.6: Grant tables => FAIL | 6.7: Skip merge => FAIL | 6.8: Skip networking => FAIL | 6.9: Safe user create => FAIL | 6.10: Skip symbolic links => FAIL | |_ The audit was performed using the db-account: root
Slow denial-of-service attacks open as many connections as possible and send the minimum amount of data, taking the longest possible time to attempt to consume all available network resources. The http-slowloris and http-slowloris-check scripts allow the detection of web servers vulnerable to these attacks. Robert Hansen, better known as "RSnake," has published a tool and documented this vulnerability very well at http://ha.ckers.org/slowloris/. Also, a security researcher named Hugo Gonzalez discovered that these attacks can be ported to IPv6 as well.
Running the http-slowloris script with a high number of concurrent connections will launch a slow denial-of-service attack:
#nmap -p80 --script http-slowloris --max-parallelism 300 <target>
If the host is vulnerable, the output will return something similar to this:
PORT STATE SERVICE REASON 80/tcp open http syn-ack | http-slowloris: | Vulnerable: | the DoS attack took +5m35s | with 400 concurrent connections |_ and 1900 sent queries
The vulnerability known as CVE-2014-3566, also known as Poodle, allows decryption of secure communications using SSL version 3. Although there are newer security protocols, downgrade attacks can be performed on modern web browsers to force connections to fall back to SSLv3. Therefore, SSLv3 is considered obsolete and insecure now.
To detect services that allow SSLv3 CBC ciphers, we could use the ssl-poodle NSE script:
nmap -sV --version-all --script ssl-poodle -p- <target>
Vulnerable services will return the following output:
PORT STATE SERVICE REASON 443/tcp open https syn-ack | ssl-poodle: | VULNERABLE: | SSL POODLE information leak | State: VULNERABLE | IDs: CVE:CVE-2014-3566 OSVDB:113251 | The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and | other products, uses nondeterministic CBC padding, which makes it easier | for man-in-the-middle attackers to obtain cleartext data via a | padding-oracle attack, aka the "POODLE" issue. | Disclosure date: 2014-10-14 | Check results: | TLS_RSA_WITH_3DES_EDE_CBC_SHA | References: | https://www.imperialviolet.org/2014/10/14/poodle.html | http://osvdb.org/113251 | http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566 |_ https://www.openssl.org/~bodo/ssl-poodle.pdf