Capture the Flag

Capture the Flag: A walkthrough of SunCSR’s Tre

December 3, 2020 by Thomas Herrell

Introduction

Welcome to my write-up for the Tre machine from VulnHub. This is an intermediate-level, intentionally-vulnerable virtual machine created for the purposes of testing and strengthening one’s abilities. I hope you enjoy reading this as much as I enjoyed rooting and writing!

Setup

The download page is here. Always read the description to see if there’s anything the author shared that they think is important! In this case, it mentions that this machine works better with VMware Workstation, so let’s follow their advice and run it in VMware. DHCP is also enabled, so we will need to discover the host’s address after it boots.

We download the .zip file and import the .vmx into VMware as usual. I then like to ensure the network setting is set to a “host-only” network so that it is not exposed to anyone except my attacking machine. My attacking machine is also in VMware, so we just need to ensure it also has a network interface connected to the host-only network.

With that out of the way, we are ready to start scanning this machine!

Scanning

I like to start off with an nmap ping scan to find the vulnerable host. I know some people prefer netdiscover, but it never seems to run properly for me. It’s easy to identify our target in the output of the scan, as its IP address is the only one found besides my attacker’s (VMware’s host-only network doesn’t work the same as VirtualBox’s, where you also see your host machine and the virtual network’s DHCP server addresses). This machine is located at 172.16.0.128, and with that information, we can scan for some open ports.

Of note here are the web services on ports 80 and 8082. I ran gobuster on each to see if there were any interesting files or directories, and we found a directory called “system” under port 80. If we attempt to visit this directory, we are prompted for a username and password.

This is what’s known as HTTP Basic authentication, and we could try to use a dictionary attack with thc-hydra to get the credentials, but we should try a few common usernames and passwords first. Common default credentials for a given service could include (format: username/password): admin/admin, admin/password and admin without any password. We could also try substituting “root” or “administrator” as the username in the above guesses. In this case, we can simply enter “admin” for both username and password and we will be brought to this site:

This is the login page for Mantis Bug Tracker, an open-source bug tracking system running on our victim machine. Our “admin/admin” trick doesn’t work for this page, so we will need to see if there’s another way into this MantisBT instance.

Exploitation

Utilizing the searchsploit command, we find that some versions of MantisBT are vulnerable to a “pre-auth remote password reset” vulnerability, which means we can reset passwords without first needing to authenticate. I couldn’t find a good way to identify the version on this site, but I figured it was worth trying to see if it was vulnerable. 

The document says that by visiting the page “/verify.php?id=1&confirm_hash=” we can reset the password for the user with the ID of 1. In many applications, it is common that the first user is an administrator user, as they would have been the first user configuring the system, so targeting IDs of 0 or 1 could be useful.

We find that user 1’s name is “XiBejMub” and we can reset their password to any value we like, and once we do that, we are logged in as them! This turns out to be a name, while the account we log into is actually the MantisBT administrator account.

After exploring a bit, we find some juicy information in the user management section.

The value for tre’s “Real Name” field looks a lot like a password, and it’s possible this user typed this info into this field mistakenly when signing up. This works out well for us, as it is indeed the password for the tre user and we can get a shell through SSH with these credentials.

Now it’s time to look into privilege escalation. After some manual recon, I ran a linpeas.sh scan on the box to see what it could find. I like to run it by redirecting the output to a file (something like ./linpeas.sh > lpe.txt) and viewing it later with less -r lpe.txt, which allows the coloring to be shown. 

The scan found two interesting things. Firstly, our user is able to run /sbin/shutdown as sudo without a password. Secondly, there is a file (/usr/bin/check-system) owned by root that we have read and write permissions to.

It seems the check-system script will be run by systemd when the machine is booted. How convenient for us that we can reboot the machine with sudo! Almost like it was planned. We can insert a command into this script to give us a reverse shell when the machine is rebooted, and then we can issue the reboot command with sudo /sbin/shutdown -r now. After a minute, we are presented with our root shell!

I’ve shown the length of the flag.txt file instead of reading it so as to not spoil all of the fun for you, so go ahead and try this machine out for yourself!

Lessons learned

In rooting this machine, I re-learned the importance of trying some basic things manually before resorting to scripts and tools. While I didn’t run linpeas.sh immediately like in a previous writeup, I ran thc-hydra against the basic auth-protected webpage and it got the admin/admin creds, which is something I could have tried first which would have saved some time.

Did you attempt this machine as well? Did this guide help you if you got stuck? Let me know in the comments — I’d love to hear about it!

Posted: December 3, 2020
Articles Author
Thomas Herrell
View Profile

Thomas Herrell is dedicated to constantly learning new things. He is working in information technology currently, and looking to move into the security field. He enjoys many technical and non-technical hobbies, such as writing, building (and breaking) things, security conferences, CTFs, and grilling.


Notice: Undefined index: visitor_id12882 in /www/resourcesinfosecinstitute_601/public/wp-content/plugins/infosec-user-info/infosec-user-info.php on line 117