Tre

1. Ran a TCP scan via NMAP

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

1. I checked the target at port 8082 and found the same web page as above.

2. The next step was to brute-force directories which I did using Gobuster.

3. 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 a writeup for this and then used a different wordlist.

4. I found a /cmd subdirectory and visiting it returned the following website.

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

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

2. Out of all the subdirectories found, two of them could be put to use.

   /adminer.php
   /mantisbt

3. I visited adminer.php and found the following.

Adminer is (or was) a database management tool solely written in PHP. Here I had a login page for the same.

1. 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 too.

1. I tried logging in via default mantisbt credentials which were adminstrator:root but it didn't work.

2. Next I ran a directory brute-force scan inside the mantisbt directory and found a config directory.

1. Here a.txt seemed a little off relative to the other files present here.

2. Upon opening the file I found the following database credentials.

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

2. 
3. 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.

4. 
5. I tried using the administrator and tre credentials in the Mantis login but none of them worked.

6. Next I tried using both the credentials in SSH but it didn't work too.

7. After a while I tried logging in to SSH again but this time using the realname values as the password.

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

Privilege Escalation and root

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

1. 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.

2. After that I ran pspy https://github.com/DominicBreuker/pspy , to check the running processes on the target.

1. A file named check-system inside /usr/bin was running every second. This seemed interesting.

2. I listed out the code inside the file and got the following.

1. It also had write permissions.

2. I overwrote the file with chmod +s /bin/bash which would give the SUID sticky bit to /bin/bash and hence I could then access the shell as root.

3. I ran echo "chmod +x /bin/bash" > /usr/bin/check-system and then shutdown the system using sudo /sbin/shutdown -r now

4. After starting the system again I used /bin/bash -p with -p for privileged mode and immediately got a proper root shell.

5. The only step left was to get the root flag from proof.txt .