TryHackMe: CMesS Walkthrough

Can you root this Gila CMS box?

Introduction

I found this box irritating and attempted it three times before finally getting all two flags. You may notice the box’s IP address changing during this walkthrough. There is not much of a theme per se, but it does require patience and a fair amount of enumeration.

Budding pentesters are given two hints - (1) don’t bother brute-forcing (the Gila CMS and SSH login passwords are good), and (2) enumerate for sub-domains.

You can access the free CMesS box from TryHackMe’s platform: https://tryhackme.com/r/room/cmess

TL;DR;

The box's initial weakness is that the subdomain reveals credentials, which, in turn, grants low-level shell access to the box. Low-level shell access was gained via the Gila CMS version 1.10.9 Authenticated Remote Code Execution vulnerability. The passwords in this box are fairly strong and will not easily be brute forced.

Further enumeration on the box reveals the SSH password for a registered user - Andre. Through this user, we can elevate our privileges by using the wild card in the scheduled cron task.

Required Tools:

Penetration Testing OS - Kali or Parrot OS (or whichever security-focused OS you prefer)
LinPEAS.sh (optional): https://github.com/peass-ng/PEASS-ng/tree/master/linPEAS

Stage One: Enumeration

Skipping ahead of my usual ‘quick and dirty’ Nmap scan, there are two open ports for this box - 22 (SSH) and 80 (HTTP).

Nmap enumeration

We can already tell Gila CMS is running on the target for the latter, but we know that we need to enumerate for sub-domains.

Gila CMS home page

To proceed with sub-domain enumeration, we must edit the Linux /etc/host file and add an entry to resolve the target IP address to the cmess.thm domain as indicated at the top of the room page.

Amend /etc/host file

s the idiom goes, ‘The devil’s in the detail”. I made a mistake with the /etc/host entry and threw off all my enumeration for about one and a half hours instead of cmess.thm I added an entry for cmess.htm.

When I realised my mistake, I opted to take a break and return when ‘cooler minds’ can reason. Fortunately, I found several methods of enumerating sub-domains, but the most effective for this box was wfuzz.

Subdomain enumeration

We now have a second (sub) domain: dev.cmess.thm. Navigating this domain, we get a page displaying communication between the support team and a user, Andre. Fortunately for us, support reset Andre’s password and included it in plaintext during this exchange (brute-force would take a very long time for this password).

CMesS subdomain main page

Fortunately, I did not discard my previous ‘incorrect’ enumeration using the target IP address and confirmed that the Gila CMS had several directories worth reviewing, including http://cmess.thm/login. I also confirmed that the Gila CMS has several vulnerabilities via searchsploit.

Gila CMS web directory enumeration

Gila CMS searchsploit

I already know brute-forcing credentials will not work on this page, and my earlier attempts at SQL injection were unsuccessful. As CTFs go, most likely the subdomain credentials (andre@cmess.thm and KPFTN_f2yxe%.) grant access to the CMS backend.

Gila CMS backend login

When testing out SQL injection, I would receive an error indicating my credentials were incorrect. Strangely enough, I did not get an error when using the credentials I found but was redirected to the Gila CMS home page. Perhaps the .htaccess file messed up authentication, but I was automatically logged in when I accessed the http://cmess.thm/admin page.

Normally, when I access a web application backend, I look for a way to upload a reverse shell script. While I did find a potential way to create files on the Gila CMS backend (Content > File Manager), I could not figure out how to access the reverse shell script.

Gila CMS PHP reverse shell script

Stage Two: Exploit

At this point, I remembered the version numbers from my earlier searchsploit review and explored this path instead.

Gila CMS searchsploit exploit

The vulnerability takes advantage of the credentials gathered from the subdomain and requires setting up a listening Netcat port to receive a reverse shell.

Exploit the Gila CMS Authenticated RCE

Reverse shell Gila CMS RCE exploit

The www-data account is low-level and does not provide access to any useful information (no permission to access Andre’s home directory), but I confirmed there are two users on the box: Andre and root. Thus, there are two possible solutions:

Elevate privileges all the way to ‘root’ level to gain access to both the user and root flags or
Elevate privileges to Andre, then use his access to elevate privileges to ‘root’ level.

Manual enumeration was not getting me anywhere, so I brought out the big guns—LinPEAS. If you need a quick refresher on how to get the LinPEAS script over to your target and execute it, check out my earlier post.

I hoped to go for solution number one—elevate straight into root and conclude the box.

A Kernel-level vulnerability on this box reminded me of an earlier TryHackMe room I completed - Sudo Buffer Overflow (CVE-2019-18634). The sudo version on this box—version 1.8.16, and the LinPEAS Linux Exploitation Suggester matched the criteria highlighted in the earlier box.

Sudo version

Kernel exploit via Linux exploit suggester

I followed the same steps from the Sudo Buffer Overflow room but did not succeed in elevating my privileges on the CMesS box. Face-palm: I also remembered that for this Kernel exploit to work, the pwfeedback option needs to be enabled. So much for low-hanging fruit.

I still feel like there is a way to execute solution number one with trial-and-error of the suggested exploits, so I will probably come back and try a different approach

Download, compile, and transfer kernel exploit

Kernel exploitation failed

It is time to move on to solution number two—elevate my permissions to Andre and proceed with further enumeration. Returning to my LinPEAS results, I found an interesting password backup file in the Linux /opt directory containing a password for Andre’s account. The second password: UQfsdCB7aAP6

Password file

User password retrieved

We already have Andre’s Gila CMS credentials, so these credentials are most likely credentials for the SSH port we found earlier. Bingo! We are in and found the user flag.

SSH login and user flag retrieved

Stage Three: Privilege Escalation

Next, I must figure out how to elevate from Andre to root, but Andre is not part of the sudoers group.

During manual enumeration and when using LinPEAS, I found a scheduled task that included a wildcard (*). Unfortunately, the www-data account did not have enough privileges to take advantage of this vulnerability, but hopefully, Andre’s account does.

Wildcard injection vulnerability

The scheduled task backs up and archives Andre’s entire backup directory every two minutes.

To exploit this vulnerability, the first step is to create a Bash script—runme.sh with the following commands:

#Copy and rename the Bash executable and place it in /tmp directory

cp /bin/bash /tmp/cmbash

#Change the SUID bit of the new bash

chmod +s /tmp/cmbash

I placed this script under the /home/andre/backup directory and followed up with these commands. Refer to Recipe for Root’s explanation of this vulnerability (reference section below).

#create a file that will be interpreted as an argument

touch /home/andre/--checkpoint=1

#create a second file that will be interpreted as an argument

touch /home/andre/--checkpoint-action=exec=sh\runme.sh

After executing the commands above, I had to wait a minute or two for the cron task to execute and create the cmbash executable under the /tmp directory.

Once the cmbash executable appears, execute the command /tmp/cmbash -p to elevate privileges.

Finally, I retrieved the root flag!

Elevating privileges via wildcard injection on the scheduled cron task.

Mitigation Measures

I think the mitigation measures are fairly straightforward for this scenario:

Web developers and administrators - DO NOT leave credentials on web pages and secure files and directories to prevent exfiltration. This applies to both production and development systems.
Web developers and administrators - update all applications to the latest version and implement mitigation measures for any known vulnerability where possible.
System administrators - DO NOT store passwords (especially simple passwords) in plaintext on a system.
Cron Job Wildcards Injection - place the full directory path before the wildcard to prevent this vulnerability.

Conclusion

This box has a Medium difficulty rating, and I can understand why. It requires patience, lots of enumeration, and paying attention to details.

During my brief web development career, I don’t recall placing (or hiding) user credentials on a web page, and this vulnerability seems highly unlikely. However, setting up a subdomain for a demo application or developing a custom client application is common.

All in all, the box presented an interesting escalation path that I had not encountered before, and it definitely added a few more tools to my toolset.

References

Cover Image: https://linuxiac.com/how-to-use-cron-and-crontab-on-linux/

Gila CMS Authenticated Remote Code Execution: https://www.exploit-db.com/exploits/51569

Cronjob Wildcard Injection: https://rootrecipe.medium.com/cron-jobs-part-2-ce559bbcfc9d

Linux Privilege Escalation via Cron Jobs: https://juggernaut-sec.com/cron-jobs-lpe/

Cron Job Wildcard Mitigation: https://materials.rangeforce.com/tutorial/2019/11/08/Linux-PrivEsc-Wildcard/#:~:text=sh shell.sh"-,Mitigation,-Although wildcard injection

Google Sites

Report abuse