📚 My GitHub

*️CMesS

Discovering a virtual host that leads to a compromised CMS with subsequent sudo privesc.

Room

CMesS

OS

Level

Medium

Link

https://tryhackme.com/room/cmess

Reconnaissance

After booting up the target and adding cmess.thm to the /etc/hosts we find two open ports with our portscanner of trust:

Following up on that with a more verbose nmap scan we can quickly rule out ssh as a point of entry - which leaves us with a single web port.

sudo nmap -A -p22,80 --script=default,vuln cmess.thm

It appears that we've got a webserver running on port 80 hosting a CMS called GilaCMS.

Service Enumeration

Starting off with some manual enumeration, http://cmess.thm does not seem to contain much. We do find a reference to the CMS creators and a single "Hello World" post but that's about it. Running gobuster yields quite a few routes though:

gobuster dir -w /usr/share/wordlists/dirb/common.txt  -u http://cmess.thm/

Amongst some forbidden and uninteresting paths, we do find a login panel at /admin/. Since the room description on TryHackMe states that "no brute forcing is required" one of the first things we can try is to google for default credentials.

Not having found any, whilst on google, we can also search for known vulnerabilities (utilizing searchsploit as well). We discover a few exploits that require authentication and one unauthenticated remote code execution for Gila CMS < 2.0.0.

However, so far we've not been able to reliable discover the exact version of the CMS and after modifying the exploit for our linux target it does not appear to work.

As part of more enumeration we can also test for subdomains or rather virtual hosts (vhosts) on the target using wfuzz:

wfuzz -c -u http://cmess.thm -H "Host: FUZZ.cmess.thm" -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt --hw 290

So there appears to be something different at: dev.cmess.thm. Adding this to the /etc/hosts we can access the development log:

We found credentials for the andre user.

Initial Access

Using these credentials on the admin panel we discovered earlier we are now authorized:

From here on we could attempt to use an exploit or, and that seems a bit easier, just modify one of the template pages (e.g. the footer.php) and inject a php reverse shell (such as this one).

Reloading any page on http://cmess.thm will spawn us a shell in our listener as the www-data user.

Privilege Escalation

As www-data we unfortunately don't have sudo permissions nor access to other users home directories. However, we can see that the user andre exists and while looking for scheduled jobs on the machine we also find an interesting cronjob:

In order to abuse that cronjob we'll have to become andre first though. After looking at running processes and SUID binaries we come across an interesting file with very lax permissions:

We were lucky that this file wasn't hidden very well but otherwise a script such as linpeas or a special find would have done the work for us.

Now as andre we have access to the backup directory in our home folder and can exploit the cronjob. For those who haven't seen this tar wildcard exploitation before: a mix of GTFOBins and google will teach you that we can create files with names such as --checkpoint=1 that will be caught by the wildcard (*) and then interpreted as actual flags to the tar command. Since the command runs as root we can (for example) simply craft flags that will add the SUID bit to /bin/bash for easy privilege escalation. Here are the commands:

cd /home/andre/backup
touch ./--checkpoint=1
touch ./--checkpoint-action=exec=bash\ exec.sh
echo chmod +s /bin/bash > exec.sh
chmod +x exec.sh

We saw the */2 in the crontab which means that the job will run once every 2 minutes. So after waiting a short period of time, we should be able to see that the permissions of /bin/bash have been altered:

Now we simply execute /bin/bash with the -p flag (to disable the privilege squashing) and gain root access:

Submit the final flag and enjoy root.

Mitigations

Although these challenges aren't aimed at being perfectly realistic, it's always interesting to enumerate the weaknesses that led to the full compromise of the system. So here's what i think were the main issues that would need to be addressed:

  • Accessible development server -> this should most likely be an internal server and even then at least be secured

  • Cleartext depiction of sensitive information -> although this goes together with the first point, sensitive information, especially passwords should not be sent or stored in cleartext (if at all)

  • Admin access on the CMS -> if not absolutely necessary, andre should not be an administrator on the CMS, i.e. apply principle of least privilege

  • Unsafe permissions -> backup files should not be readable by everyone and scheduled tasks should only run with the least required privileges

PreviousBinexNextOlympus

Last updated