Vulnhub machines walkthrough series - Vulnix

Today we'll be continuing with our series on Vulnhub virtual machine exercises. In this article, we will see a walkthrough of an interesting Vulnhub machine called Vulnix.

Note: For all of these machines, I have used the VMware workstation to provision the virtual machines (VMs). Kali Linux VM will be my attacking box. And please remember: the techniques used here are solely for educational purposes. I am not responsible if these techniques are used against any other targets.

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

VM details

Download

Description from Vulnhub: 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:

Architecture: x86

Format: VMware (vmx & vmdk) compatibility with version 4 onwards

RAM: 512MB

Network: NAT

Extracted size: 820MB

MD5 Hash of Vulnix.7z: 0bf19d11836f72d22f30bf52cd585757

The goal; boot up, find the IP, hack away and obtain the trophy hidden away in /root by any means you wish – excluding the actual hacking of the vmdk

Walkthrough

1. Download the Vulnix VM from above link and provision it as a VM.

2. Following established routine from this series, let's try to find the IP of this machine using Netdiscover. Below, we can see that the IP address is 192.168.213.140.

3. Now since we know the IP address, let's start enumerating the machine with Nmap. Below is the initial output from the Nmap scan. We can see that lot of ports are opened on this machine such as 22, 25, 79, 110, 143, 512, 513 and so on.

4. Since port 25 is opened, let's try to make connection to it using Netcat. Below is an output for the same. We have also confirmed that Vulnix is a user present on the machine:

5. Can we enumerate all the users based on this service? Yes, we can, and Nmap comes to our rescue again. It has a script (smtp-user-enum) to which we will pass a well-curated username list shipped with Metasploit. Below we can see all the usernames that exist on this VM.

6. Now since we have so many users, what can we do to verify which user has logged into the machine? Go back to enumeration. We have port 79 opened, which is for Linux finger service. There is a well-laid-out script to take a list of usernames as arguments, which suits our case. Below is a snippet from the script, as we need to specify the target server inside.

7. After running the above script we found out that user with name 'user' has logged on recently, so that might be worth trying for.

8. So let's recap: what do we have so far? A couple of usernames. Heh. Let's go back to enumeration result and see what other services we have. Port 2049 is opened as per Nmap; let's see what is running there.

We have an NFS share! We are back in the game if we have some shares that we can connect to.

9. Using showmount with the --exports option we can see that we have a share. Let's try to mount it. For that I have created a directory named remote and used the mount command to mount the remote share, but all we got was permission denied. (This is mostly due to the root squash flag bit set). But what if we try to access the same share with same user ID remotely?

10. So what can we do now? Running out of ideas, I tried brute-forcing the username we found earlier with hydra and rockyou — and we got a hit!

11. With that information we are able to successfully log into the box and can see another user there named Vulnix, which is a user we discovered very early. (And it was expected from the information collected above.)

12. Building on the above idea , let's grab the UID of Vulnix and create a new user on our Kali box with the same UID.

13. Below is the user created on Kali box with the same UID.

14. Changing user to vulnnix on local box and trying to access the previously mounted remote share results in a success this time.

15. So now, let's create keys for this user on the Kali box, create a .ssh directory on the remote share and upload keys there.

16. Below we have created the directory and copied the contents of public keys to the authorized keys on the newly-created .ssh directory.

17. After logging onto the system, one of the first commands I always run is to check what the user can run as sudo. Below we can see that the user is allowed to edit /etc/exports.

18. Below are the changes done to /etc/exports. Notice first we have changed the root squash flag to no root squash, which will give us the ability to mount this share as root remotely. But that will not serve our purpose so let's try to offer /root with no_root_squash.

19. But we have a major roadblock here. How to get these settings into effect? I looked into other avenues for this machine but could not find anything and had to resort to restarting this machine. (BAD, VERY BAD solution.)

20. Once we came back up, we can see that the new share is available.

21. We created a new directory r00t, mounted the /root share and can view the flag (trophy.txt).

Victory!

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

This a fun VM with some serious limitations and dependencies. First is the identification of username 'user,' and then restarting of the VM. Probably not for beginners. But there are some effective things to learn here about root/no_root squash and how to exploit a remote share.