Vulnhub Vulnix Walkthrough
I'm surprised I didn't find this one sooner. I was working my way through the Kioptrix series but alas, the final box is from a different hypervisor and while I was able to import it, I could not get networking to function. One day I will setup another machine to work on these other systems but for now, I continue finding lists of must-do boxes. Vulnix has been around for a while but I've never crossed paths with it.
This is a fun box. It is probably more real world than the CTF style boxes because its vulnerability stems from a misconfiguration which is more likely than you might think.
Starting off with an Nmap scan:
Noticing port 111 open, I want to see what's running:
Excellent, let's see if we have any shares:
Looks like we have a home directory, let's try to mount it:
Ok, we have a home directory but in order to access it, I need to create a user and I need to know the userid of the user Vulnix. I need on the box to get that userid, let's see if we can enumerate something from SSH:
Using the stock unix_users.txt list from Kali, I run my scan and I find....
Excellent, hidden in the noise is the user "user". Now let's see if we can brute the password for "user":
Key things I like to change in the options are: Stop_On_Success = true, User_As_Pass = true, and Threads = 5. Once we add the remaining options, we run our brute:
Cool! We have the password, moving to SSH:
We are logged in as user, now I'm going after the uid for Vulnix and we see it's id is 2008. Now we're going to setup this user on our end to match what we've found:
We're going to add our Vulnix user, take note it's id is 1001. We need to edit /etc/passwd:
Changing the id from 1001 to 2008:
Now we need to edit /etc/group:
Same deal, we need to change the id from 1001 to 2008:
Now that we've changed the id, we need to change the ownership on our home directory because it was setup using the original id:
With our id setup correctly, we're going to switch to our user Vulnix and look in the remote home directory:
Nothing of use here but I sort of had an idea as to where this was going because a number of searches on misconfigurations of /etc/exports lead to articles on exploiting ssh authorized keys. We're going to generate ssh keys on our local machine for our local user vulnix:
Now that we have our keys setup, we're going to create a .ssh directory in the remote home directory for Vulnix:
With the home directory created, we've also copied our local user public key file into the remote user's authorized keys file which will essentially allow use to SSH with keys rather than a password we do not know. With this setup, we're going to attempt to ssh using our private key:
Excellent! We have successfully logged in as the user Vulnix. Assuming Vulnix is our path to victory, let's see what sudoers has for us:
Sweet! We have the ability to edit the /etc/exports file as our user Vulnix -- no password required. Editing /etc/exports:
When we look at the share, it's pointing to the home directory of the user Vulnix. It's also setup with "root_squash" which means that remote root users (us, when we access the share over NFS) are unable to change local files. We're going to change the share and we're going to setup with no_root_squash which will allow us to make changes remotely.
I comment the existing line and I replace it with / and I add no_root_squash. Now we need to unmount our share:
Since I am unable to restart NFS, I need to reboot the machine. Perhaps I could have found an exploit to crash the server, or waited for the non-existent admin to reboot the server, but for the sake of making this timely, I'm going to force a reboot from the hypervisor:
Now that we've rebooted the server, I'm going to prepare a simple shell for privilege escalation:
I'm going to mount the / share, drop my shell, compile it, and create a setuid binary:
With all of that done, we can now ssh back in as Vulnix, again using our keys:
Since our shell is setuid, we hit it and we are #root. One last thing to do: