> For the complete documentation index, see [llms.txt](https://bunring.gitbook.io/ctf-writeups/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://bunring.gitbook.io/ctf-writeups/try-hack-me/2024/publisher.md).

# Publisher

{% embed url="<https://tryhackme.com/r/room/publisher>" %}

## Recon

Let's start with a nmap scan. We find two ports open. Port 22 with SSH and port 80 with an Apache web server.                                                                                                                                                                                                                                 &#x20;

{% code overflow="wrap" %}

```bash
┌──(kali㉿kali)-[~]
└─$ nmap -p- publish.thm -T4          
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-07-08 11:41 IST
Nmap scan report for publish.thm (10.10.91.245)
Host is up (0.15s latency).
Not shown: 65530 closed tcp ports (conn-refused)
PORT      STATE    SERVICE
22/tcp    open     ssh
80/tcp    open     http

Nmap done: 1 IP address (1 host up) scanned in 101.71 seconds

┌──(kali㉿kali)-[~]
└─$ nmap -sC -sV -p 22,80 publish.thm -T4
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-07-08 12:00 IST
Nmap scan report for publish.thm (10.10.91.245)
Host is up (0.15s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 44:5f:26:67:4b:4a:91:9b:59:7a:95:59:c8:4c:2e:04 (RSA)
|   256 0a:4b:b9:b1:77:d2:48:79:fc:2f:8a:3d:64:3a:ad:94 (ECDSA)
|_  256 d3:3b:97:ea:54:bc:41:4d:03:39:f6:8f:ad:b6:a0:fb (ED25519)
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))
|_http-title: Publisher's Pulse: SPIP Insights & Tips
|_http-server-header: Apache/2.4.41 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

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

{% endcode %}

We start a directory scan using feroxbuster. Here we discover the directory `spip`.

```bash
┌──(kali㉿kali)-[~]
└─$ feroxbuster -u http://publish.thm/ -w /usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-medium.txt -n
                                                                                                                                                                                                                                            
 ___  ___  __   __     __      __         __   ___
|__  |__  |__) |__) | /  `    /  \ \_/ | |  \ |__
|    |___ |  \ |  \ | \__,    \__/ / \ | |__/ |___
by Ben "epi" Risher 🤓                 ver: 2.10.3
───────────────────────────┬──────────────────────
 🎯  Target Url            │ http://publish.thm/
 🚀  Threads               │ 50
 📖  Wordlist              │ /usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-medium.txt
 👌  Status Codes          │ All Status Codes!
 💥  Timeout (secs)        │ 7
 🦡  User-Agent            │ feroxbuster/2.10.3
 💉  Config File           │ /etc/feroxbuster/ferox-config.toml
 🔎  Extract Links         │ true
 🏁  HTTP methods          │ [GET]
 🚫  Do Not Recurse        │ true
 🎉  New Version Available │ https://github.com/epi052/feroxbuster/releases/latest
───────────────────────────┴──────────────────────
 🏁  Press [ENTER] to use the Scan Management Menu™
──────────────────────────────────────────────────
404      GET        9l       31w      273c Auto-filtering found 404-like response and created new filter; toggle off with --dont-filter
403      GET        9l       28w      276c Auto-filtering found 404-like response and created new filter; toggle off with --dont-filter
200      GET      354l      770w     5959c http://publish.thm/style.css
200      GET      142l      610w    69796c http://publish.thm/images/image_02.jpg
301      GET        9l       28w      311c http://publish.thm/images => http://publish.thm/images/
200      GET       32l      224w    17917c http://publish.thm/images/ads.jpg
200      GET      237l     1368w   110318c http://publish.thm/images/image_01.jpg
200      GET      150l      766w     8686c http://publish.thm/
301      GET        9l       28w      309c http://publish.thm/spip => http://publish.thm/spip/
[####################] - 13m   207638/207638  0s      found:7       errors:102    
[####################] - 13m   207629/207629  269/s   http://publish.thm/  
```

We do not discover anything on the index page.

<figure><img src="/files/TUd7Z4743r7azPr77Mk0" alt=""><figcaption></figcaption></figure>

In the spip directory, we find a blog created with SPIP, a free and open-source content management system (CMS). SPIP is designed for managing web-based publications and enabling collaborative work.

<figure><img src="/files/9kZT5nnK0aoHfZOapFEX" alt=""><figcaption></figcaption></figure>

Examining the source code, we identify that version 4.2.0 is in use. This might be our entry point.

<figure><img src="/files/UznmsqLVjpgxM1G8ydJq" alt=""><figcaption></figcaption></figure>

## Initial Access

After some research on SPIP 4.2.0, we discover an exploit that allows for remote code execution (RCE) without authentication.

{% embed url="<https://www.exploit-db.com/exploits/51536>" %}

Let's try using the Metasploit framework. We find an RCE exploit for SPIP that was disclosed around the same time as the one on exploitdb. This could be the same exploit.

<figure><img src="/files/PsjbAS704vl9u9Su7m5z" alt=""><figcaption></figcaption></figure>

After we have set the necessary parameters and run the exploit, we get a meterpreter session.

<figure><img src="/files/rwfM10FiudjJvDKuLVTg" alt=""><figcaption></figcaption></figure>

In the session, we can spawn a `shell`, and we are the user `www-data`. This user has permission to access the home directory of the user think and read the files there, allowing us to obtain the first flag.

<figure><img src="/files/911Rj0HcDK54VPyaOMpQ" alt=""><figcaption></figcaption></figure>

In the home directory of the user think, we find a private SSH key. We copy this key and adjust the permissions accordingly.

<figure><img src="/files/vc6UPhr71R8Elsu14zM1" alt=""><figcaption></figcaption></figure>

After setting the permissions, we use the key to log in to the machine via SSH as the user think. Initially, it seems we now have a more stable shell. However, we quickly notice some restrictions: we can't write in the home directory, other writable directories like /tmp are also inaccessible, and the /opt directory is not readable. It appears our access is more limited than we expected.

<figure><img src="/files/DrsIvRKWB3z5XS4LxAhN" alt=""><figcaption></figcaption></figure>

## Privilege Escalation

During enumeration, we discover a custom binary with the SUID bit set, meaning it executes in the context of the owner, which is root.

<figure><img src="/files/WmR9AgJQNbwUaCSu5GC1" alt=""><figcaption></figcaption></figure>

We can quickly inspect the binary using `strings` or `cat`, which reveals that it only executes a script located at `/opt/run_container.sh`. Notably, this script is run with `bash -p`, meaning it executes with root privileges.

<figure><img src="/files/knNrinvCvXq8NVXRE6Hn" alt=""><figcaption></figcaption></figure>

The `/opt` directory should be readable, suggesting another mechanism might be restricting access.

<figure><img src="/files/GNODC8249255BWDW3jRW" alt=""><figcaption></figcaption></figure>

We can read the script located in `/opt` but cannont not identify any vulnerabilities or entry points for injecting commands or parameters.

<figure><img src="/files/eKHEDcoPMgLRrkZoyS3C" alt=""><figcaption></figcaption></figure>

It seems like we'll need to bypass our current shell restrictions. One possible approach could involve modifying the contents of run\_container.sh.

It appears that AppArmor is imposing restrictions, particularly on the shell `ash` and programs in `/usr/bin` and `/usr/sbin`. The rules deny access to `/opt/` and apply a ruleset inherited by `/usr/bin/**` and `/usr/sbin/**` which restricts certain operations.

Interestingly, there is a flaw in the AppArmor profile: while `/dev/shm/` and `/dev/tmp/` have deny rules, they lack the `/**` wildcard, unlike `/tmp/`. This allows us to still write to `/dev/shm` and `/var/tmp`.

<figure><img src="/files/7dka5tcqM93QtpgmhHZa" alt=""><figcaption></figcaption></figure>

The user's shell, as listed in `/etc/passwd`, is set to `ash`.

<figure><img src="/files/HZxhZt2FshVdx3nAOr0J" alt=""><figcaption></figcaption></figure>

We copy `/bin/bash` to `/var/tmp` and run it. We can now access `/opt`.

<figure><img src="/files/mK7baQoPY9WTJytw4pw1" alt=""><figcaption></figcaption></figure>

Fortunately, we are allowed to write on `run_container.sh`.

We'll create a script that copies `/bin/bash` to `/var/tmp` and sets the SUID bit. This way, when executed, the script runs with root privileges, allowing us to obtain a root shell.

<figure><img src="/files/hs9bR006ZKfYHOuHjZKw" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/9w2PdSkm8MIzeuH1QDp7" alt=""><figcaption></figcaption></figure>

After running the `bash1` binary inside `/var/tmp` with the tag `-p` we gain a root shell and find the final flag in `/root/root.txt`.

<figure><img src="/files/JIP9WkFu2OSkymkI0fxt" alt=""><figcaption></figcaption></figure>
