This box was referred to my by a friend who said I had to get more experience with NFS, so that kind of spoiled a bit. Due to that, I already knew the attack vector and as a result, did not perform any enumeration on the other ports.
I really enjoyed trying this box. I really wanted to finish it. I was only able to get a low-level user due to the box being broken or misconfigured somehow (more on that when we come to it). So when I get to the root privilege escalation part of this writeup, I'm going to have to refer to someone elses blog post for that. Enjoy the writeup!
This box can be found at Vulnhub's Website. The website lists the description as:
Here we have a vulnerable Linux host with configuration weaknesses rather than purposely vulnerable software versions (well at the time of release anyway!)
The host is based upon Ubuntu Server 12.04 and is fully patched as of early September 2012. The details are as follows:
Format: VMware (vmx & vmdk) compatibility with version 4 onwards
- Enumeration of NFS
- Privilege Escalation using mount
- SSH Keys
So, to start, we don't know the IP address of the box but we know the subnet that our VMs are in so we can start with an
nmap of that subnet.
nmap -sC -sV -oA nmap/scans 192.168.196.0/24
After that runs, we get the following:
Lots of nmap! Ignore the blog.thm domain name, that was for a room I made for TryHackMe.
We see a lot of ports open like SMTP and POP3, but we see that it's running NFS which we know is vulnerable. For those that don't know, NFS allows remote hosts to mount the directories over the network. This means that on Linux, we can directly mount the NFS directory. More information can be found here.
To show what is mounted to the NFS, we can do that with
sudo showmount -e 192.168.196.129. If you get an error when trying to perform this, you need to install the
nfc-common package. We get back
Great! So we can see that a user's home directory is being shared via NFS. Let's get to mounting! To do this properly, let's create a directory where anyone has read and write access to..like
/tmp. We'll do a quick
mkdir /tmp/test so we have a place to mount Vulnix's home directory to then
Then we need to actually do the mounting of the NFS. We can do that with
sudo mount -t nfs 192.168.196.129:/home/vulnix /tmp/test. After we execute that, if we do an
ls -la and a
stat test we can see some interesting things...
The share seems to be owned by uid 65534 and gid 4294967294. The way NFS works is that in order to access the locally mounted share, you need to have the same uid and gid as that on the remote share. But these don't look right so after a bit of Googling we find that if we mount it as version 3, it will show the proper uid and gid.
sudo mount -t nfs -o vers=3 192.168.196.129:/home/vulnix /tmp/test
So the user is vulnix and they're uid 2008 and gid 2008. So we need to create a user and group. That's easy enough. Let's give them a home directory and uid and gid of 2008. First we need to create the group for vulnix.
sudo groupadd --gid 2008 vulnix
sudo useradd -m vulnix -g vulnix --uid 2008 -s /bin/bash
You also need to set them up with a password so that you can login/
su to them but we'll skip that and just assume you know how to do it. Once you have a password set and the user fully set up, we can login as vulnix and start setting up how we're going to gain access.
Setting up SSH Keys & Doing the Thing
In order to properly gain access, one thing we can do is add SSH keys to the mounted NFS share. To do this, we need to use
ssh-keygen as vulnix. Once the keys are created you should have a
.ssh directory, as well as
To be able to SSH over to the vulnerable machine, we'll copy the id_rsa.pub key over to the mounted NFS
Note: You can actually see that my folder isn't called test. And this is actually because I got this working originally as
test but forgot to take a screenshot for the writeup and attempting the root privesc actually breaks it (you'll see) so
You may want to make sure that your permissions for your
.ssh folder and SSH keys are set properly. This tripped me up but this StackExchange post helped.
Once the key is copied, we can ssh to the machine.
Root Privilege Escalation
So this is where I actually have to stop. I was able to get to the point right before you're able to escalate privileges.
tl;dr you run
sudo -l to see that you can use sudoedit on
/etc/exports which contains the definitions for NFS shares. Once you get into here you see:
The second line is what we add, and the first line is what already existed.
no_root_squash means that remote users are able to change any file on the shared file system (see here.).
However, once you make these changes, the only way to make them take effect is to restart the VM. But when I did it, and was expecting to mount my new share...NFS didn't start and there is no way that I could find to restart the service.
So if you'd like to find out how it should be done, check out abatchy's blog and their writeup of this VM.
Overall, this was fun and I did learn about how vulnerable NFS is. It's just a shame that I couldn't get the root privilege escalation to actually work. But that's all for now.
See ya Cyber Cowboy