Reconnaissance with Nmap Scripting Engine

In this previous topic, we have seen how Nmap can be used to perform port scanning against a given target.
Of course, this is just one of the capabilities of this great tool. In fact, another very useful feature is represented by Nmap Scripting Engine (NSE).

NSE allows to include scripts, coded with Lua programming language, inside Nmap and run them to perform networking tasks in an autonomous way: this includes discovery, version detection, vulnerability discovery and even exploitation.

This is the reason why there are different categories for the scripts inside the engine: auth, broadcast, default, discovery, dos, exploit, external, fuzzer, intrusive, malware, safe, version, and vuln. For a description of each one, take a look here.

It is possible to check the complete scripts list here. If you are using Kali Linux, the scripts folder is located at /usr/share/nmap/scripts and scripts have the extension “.nse”.
In order to update scripts database, we can just run nmap --script-updatedb.

As the help section reports, to run the engine with a predefined number of scripts, the parameter to use is “-sC”:

root@kali:~# nmap -h
.....................................................................

SCRIPT SCAN:
  -sC: equivalent to --script=default
  --script=<Lua scripts>: <Lua scripts> is a comma separated list of
           directories, script-files or script-categories
  --script-args=<n1=v1,[n2=v2,...]>: provide arguments to scripts
  --script-args-file=filename: provide NSE script args in a file
  --script-trace: Show all data sent and received
  --script-updatedb: Update the script database.
  --script-help=<Lua scripts>: Show help about scripts.
           <Lua scripts> is a comma-separated list of script-files or
           script-categories.

This will execute all the scripts included in the “default” category against the specified target. It is recommended to use this option with caution, since some of the scripts included in the default category might be particularly intrusive.

Instead of launching the engine using a particular category, we can run a single script by using the --script parameter. This can be done, for example, after a previous scan where we detected an active service on some port that might be of interest.

Since the best way to understand how a tool works is to practice with it, we will see an example of NSE capabilities using a laboratory environment composed by an attacking Kali Linux machine and a vulnerable target, Metaspoitable 2 VM.

Metasploitable 2: NFS misconfiguration

Considering the results of the Nmap scan performed on the target in this article, we can take a look at the following services:

PORT     STATE SERVICE
......................
111/tcp  open  rpcbind
......................
2049/tcp open  nfs

NFS means Network File System: this protocol allows, through Remote Procedure Calls (RPC), to share portion of file systems over a computer network. Since this machine is intentionally vulnerable, the service has been misconfigured on purpose and we can use NSE to detect the misconfiguration.

The script we are interested in is nfs-ls in the “discovery safe” category; to display the description we just use --script-help followed by the name of the script:

root@kali:~# nmap --script-help nfs-ls

Starting Nmap 7.40 ( https://nmap.org ) at 2017-02-18 19:30 CET

nfs-ls
Categories: discovery safe
https://nmap.org/nsedoc/scripts/nfs-ls.html
  Attempts to get useful information about files from NFS exports.
  The output is intended to resemble the output of <code>ls</code>.

  The script starts by enumerating and mounting the remote NFS exports. After
  that it performs an NFS GETATTR procedure call for each mounted point
  in order to get its ACLs.
  For each mounted directory the script will try to list its file entries
  with their attributes.

  Since the file attributes shown in the results are the result of
  GETATTR, READDIRPLUS, and similar procedures, the attributes
  are the attributes of the local filesystem.

  These access permissions are shown only with NFSv3:
  * Read:     Read data from file or read a directory.
  * Lookup:   Look up a name in a directory
              (no meaning for non-directory objects).
  * Modify:   Rewrite existing file data or modify existing
              directory entries.
  * Extend:   Write new data or add directory entries.
  * Delete:   Delete an existing directory entry.
  * Execute:  Execute file (no meaning for a directory).

  Recursive listing is not implemented.

The target has IP address 192.168.1.100 (discovered, for example, using Netdiscover or Nmap itself), so we can start running the NFS discovery script against the machine.
In order to trigger as less alerts as possible, it is always a good idea to scan only ports we are focusing on. The port we are interested in is not the one on which runs the NFS service, but the “rpcbind” one: this service performs the task of routing requests between clients and NFS server.
Then, we can launch Nmap against port 111:

root@kali:~# nmap -p 111 --script=nfs-ls 192.168.1.100

Starting Nmap 7.40 ( https://nmap.org ) at 2017-02-19 09:14 CET
Nmap scan report for metasploitable2 (192.168.1.100)
Host is up (0.00012s latency).
PORT    STATE SERVICE
111/tcp open  rpcbind
| nfs-ls: Volume /
|   access: Read Lookup Modify Extend Delete NoExecute
| PERMISSION  UID  GID  SIZE   TIME                 FILENAME
| -rwx------  0    0    134    2016-02-27T18:28:03  .7RSS8eUhMslnW9Zc
| drwxr-xr-x  0    0    4096   2012-05-14T03:35:33  bin
| drwxr-xr-x  0    0    4096   2016-03-06T13:45:42  home
| drwxr-xr-x  0    0    4096   2010-03-16T22:57:40  initrd
| lrwxrwxrwx  0    0    32     2010-04-28T20:26:18  initrd.img
| drwxr-xr-x  0    0    4096   2012-05-14T03:35:22  lib
| drwx------  0    0    16384  2010-03-16T22:55:15  lost+found
| drwxr-xr-x  0    0    4096   2010-03-16T22:55:52  media
| drwxr-xr-x  0    0    4096   2010-04-28T20:16:56  mnt
| drwxr-xr-x  0    0    4096   2012-05-14T01:54:53  sbin
|_
MAC Address: 00:0C:29:59:72:BC (VMware)

Nmap done: 1 IP address (1 host up) scanned in 0.43 seconds

As the outputs reports, we have the directory listing, with details about permissions, for the NFS share; the mounting point is the root directory “/” (nfs-ls: Volume /).
This can be confirmed with a command for showing mount points:

root@kali:~# showmount -e 192.168.1.100
Export list for 192.168.1.100:
/ *

This shows a really bad configuration: NFS service is useful to share portions of the file system to predefined users or groups, but if it is not configured properly it can turn into a huge security risk like in this case where anyone can access the root directory remotely.

To verify the possibility to mount the volume, we can create a temporary directory and try to mount Metasploitable 2 root directory on it:

root@kali:~# mkdir /tmp/nfs

root@kali:~# mount -o nolock -t nfs 192.168.1.100:/ /tmp/nfs

root@kali:~# ls -l /tmp/nfs/
total 160
drwxr-xr-x  2 root root  4096 May 14  2012 bin
drwxr-xr-x  3 root root  4096 Apr 28  2010 boot
lrwxrwxrwx  1 root root    11 Apr 28  2010 cdrom -> media/cdrom
drwxr-xr-x  2 root root  4096 May 20  2012 dev
drwxr-xr-x 95 root root  4096 Feb 19 09:01 etc
drwxr-xr-x  6 root root  4096 Mar  6  2016 home
drwxr-xr-x  2 root root  4096 Mar 16  2010 initrd
lrwxrwxrwx  1 root root    32 Apr 28  2010 initrd.img -> boot/initrd.img-2.6.24-16-server
drwxr-xr-x 13 root root  4096 May 14  2012 lib
drwx------  2 root root 16384 Mar 16  2010 lost+found
drwxr-xr-x  4 root root  4096 Mar 16  2010 media
drwxr-xr-x  3 root root  4096 Apr 28  2010 mnt
-rw-------  1 root root 65699 Feb 19 09:01 nohup.out
drwxr-xr-x  2 root root  4096 Mar  6  2016 opt
dr-xr-xr-x  2 root root  4096 Apr 28  2010 proc
drwxr-xr-x 13 root root  4096 Feb 19 09:01 root
drwxr-xr-x  2 root root  4096 May 14  2012 sbin
drwxr-xr-x  2 root root  4096 Mar 16  2010 srv
drwxr-xr-x  2 root root  4096 Apr 28  2010 sys
drwxrwxrwt  4 root root  4096 Feb 19 09:01 tmp
drwxr-xr-x 12 root root  4096 Apr 28  2010 usr
drwxr-xr-x 15 root root  4096 May 20  2012 var
lrwxrwxrwx  1 root root    29 Apr 28  2010 vmlinuz -> boot/vmlinuz-2.6.24-16-server

“ls -l” shows the mount operation has been executed successfully. Now, we can read or write files in the compromised machine.
Once we have done with it, we can unmount the volume with:

root@kali:~# umount /tmp/nfs

Conclusions

In this article we have seen how NSE can be used to discover useful information about the target system. Of course, this is just a simple example to give an idea of what you can do with the engine. Since everyone can contribute to the scripts, this project has a lot of potential because you can write your own code and run it in Nmap.
Take your time to practice with this powerful tool taking also a look at the other scripts categories.