Hey everyone, back again with another CTF writeup from TryHackMe. This time we’ll be looking at Vulnnet. Vulnnet is a medium-level room which involves exploiting a local file inclusion vulnerability to access credentials to a restricted subdomain. Once the attacker has accessed the restricted subdomain, they will exploit an application vulnerable to unauthenticated arbitrary file upload to gain a shell on the target. Once initial access has been established, the attacker must find SSH credentials exposed in a backup file. Finally, the privilege escalation to root requires the attacker to exploit wildcards.
Vulnnet is linked here: https://tryhackme.com/room/vulnnet1
Initial Scans & Enumeration
Alright, first thing’s first. Add the target IP address to your hosts file with the name “vulnnet.thm”. Now we can run a rustscan or nmap scan against the target IP address to probe for open ports and services running on them.
From our nmap output, we see the classic combo of port 22 (SSH) and port 80 (HTTP). This is a common combo that you will often see when doing these types of CTF challenges. Lets first enumerate the website on port 80. While we do that though, lets also run some tools to enumerate subdomains and subdirectories.
I utilized gobuster in vhost mode for subdomain enumeration. Using the command “gobuster vhost -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt –url vulnnet.thm” will accomplish this. We can also use ffuf as pictured below to enumerate subdirectories.
While browsing around on the website for a couple minutes, nothing really immediately stands out. But before we go further, lets check on our gobuster vhost enumeration. We see a subdomain called “broadcast.vulnnet.thm”, so let’s go ahead and add “broadcast.vulnnet.thm” to our hosts file, right behind the “vulnnet,thm” entry. As soon as we make a request to the page hosted on the broadcast subdomain, we are presented a login prompt.
Hmm, we can try the usual admin:admin and similar well-know default credentials but none of those work unfortunately. Let’s go back to the page that we do have access to, and look at the page source to look for comments, or any interesting looking code.
Now we can take the original request and abuse the referer parameter by adding “?referer=/etc/passwd” after “GET /index.php”. Now we can send the request and view the response, which will hopefully expose the contents of /etc/passwd.
And there we go! So now we know that we have a local file inclusion vulnerability on our hands. What else can we do with this? Well. we can look for the apache server credentials in the /etc/apache2/.htpasswd file.
So now we have a username and a hashed password. We can copy the username and hash over to a text document and save it with the name “hash.txt”. Now use john to crack the hash by using the command “john hash.txt –wordlist=/usr/share/wordlists/rockyou.txt”
With these credentials, we can now try to log in to the page hosted at the broadcast.vulnnet.thm subdomain. Go back to the page and use the credentials when given the login prompt. Success.
Now we need to enumerate this Clipbucket service and find out what exactly we’re looking at. Clicking around doesn’t yield any useful information such as a version number or anything like that, but when we view the page source, we do find a version number for Clipbucket.
Now it’s time to use the most powerful hacking tool of all…. Google! A quick search for “Clipbucket v4.0” reveals that the application is vulnerable to multiple vulnerabilities, including unauthenticated arbitrary file upload, basically meaning that anybody can upload whatever file they want without even having to login. That’s pretty dangerous. The page linked HERE from Exploit Database details the vulnerabilities present in multiple versions of Clipbucket, including v4.0. All we really have to do now is get the PHP Reverse Shell from pentestmonkey (https://github.com/pentestmonkey/php-reverse-shell/blob/master/php-reverse-shell.php), modify it to connect back to our IP and a port of our choosing, and then upload it to the Clipbucket application by following the instructions laid out on Exploit Database. You’ll notice that I covered a portion of the command line below, as that portion contained the plaintext password that we uncovered earlier in the /etc/apache2/.htpasswd file, and then cracked using john. You should be able to complete the upload without supplying the credentials like I did, but if that fails, you can use the credentials. Before we upload the PHP reverse shell though, we need to start a netcat listener on the same port that we specified in that reverse shell.
In the image above, there are two files because I uploaded the reverse shell twice. You should only see one, assuming that you only uploaded one of course. Once the netcat listener is started, open the uploaded file, and you will have a shell waiting for you back in your terminal.
Privilege Escalation to User
Now that we have a reverse shell as www-data, we need to start enumerating some more to figure out how we’re going to move forward from here. I first checked for SUID/SGID binaries for easy wins, but nothing was available for us to exploit. We can check crontab, sudo privileges, etc., but the thing we’re looking for is a zip file in the /var/backups folder. As we can see in the screenshot below, there is a zipped backup file named “ssh-backup.tar.gz”, and owned by the user server-management. That definitely sounds interesting.
Let’s first copy the file to the /tmp directory, as we have write privileges there. Use the command “cp ssh-backup.tar.gz /tmp”. Now that the zipped file is copied to the /tmp directory, we can cd /tmp, and then unzip the file using “tar -xzvf “ssh-backup.tar.gz”.
Once the file is unzipped, we are able to read the id_rsa key for the server-management user. Let’s copy the rsa_key to a text document on our local machine and save it, named “id_rsa”. Now we need to use “chmod 600 id_rsa” to change the permissions to an acceptable type for use in SSH. We also need to use the ssh2john.py tool to convert the key to a format that john can use to crack it’s password.
Now we can take the output from ssh2john.py and place it into a new text file named “sshhash.txt”, and then use john to crack it.
Now we can use the cracked password, along with the id_rsa key, to get an SSH session as the server-management user.
From here, it’s a pretty straightforward path to get the user flag.
Privilege Escalation to Root
Alright, we’re on the homestretch. It’s taken a while to get here, but let’s finish strong. First, we can read the cronjobs present on this machine by using the command “cat /etc/cron*”. The output from this command shows us a cronjob running every two minutes, triggering a script called “backupsrv.sh”. This script is using a wildcard (*) in conjuction with the tar archiving tool to backup all files in the Documents directory of the server-management user. In short, wildcards are used to denote a range/class of characters. The asterisk character, specifically, is used to match any number of characters in a filename. In this case, that means that the script will archive all files in the documents directory, since the asterisk is denoting files containing any combination of all possible characters or none at all.
There are three key characteristics of the script and its functionality which will allow us to escalate to root:
- The script is owned by root, and therefore run with root privileges.
- The script is using wildcards.
- We have write access to the directory in which the files being archived by the script are located.
Knowing these three facts, we know we can use a method called wildcard injection to escalate ourselves to root. Entire articles have been written about wildcard injection, and there is a lot to it, which is why I will direct you to this awesome article by Raj Chandel at hackingarticles.in: https://www.hackingarticles.in/exploiting-wildcard-for-privilege-escalation/
There is a section of the article titled “Tar Wildcard Injection (1st method)” which will explain exactly what you need to do to escalate to root. Follow those steps and you will have a root shell in just a short time.
Conclusion and Takeaways
This was actually a tough one for me. I had to refer to several different articles to figure out my next steps as I went along on this challenge. I did get a little frustrated with myself for feeling a little lost at a couple points, but that is just part of the journey of learning. Everybody will have days where they seem to struggle, and that’s totally normal. As always, I really enjoyed this room and I can honestly say that I learned a lot from it. TryHackMe and its contributors are always providing excellent content to learn from, and I can’t really overstate the value of it.
I hope you enjoyed this writeup and got some value from it, and I hope you come back to read some more writeups/blog posts in the future as well. Thank you!