Publisher
Writeup by FzF_StormZ
Last updated
Writeup by FzF_StormZ
Last updated
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.
I use Exegol inside WSL 2.0 Ubuntu to have a full and working environment to perfom the challenges
First of all, we will launch a complet Nmap scan to try to discover possible services:
As you can see, we have 2 open ports (22 and 80). The SSH port can be interesting if we find credentials to have a legit shell with the machine. But, for now, we will focus on the 80 port.
When I have a website during a challenge, i like to run 2 commands:
During the scan, I will walk around on the website. Every buttons are fake. We can get some informations like possible authors. As you can see below, the article was posted by "Admin" and talk about technology like Spip. Keep in mind
Go back to our commands. Gobuster find interesting directories to explore:
Directories to explore:
/images: nothing to continue to this path
/spip: the entire blog with login page !
When you have a web techno like Spip, we try to know the version. With the Wappalyzer Firefox extension, we obtain this information: Spip 4.2.0 !
Everytime I have a version service, I like to run this command:
Perfecto ! There is an exploit to have a RCE ... UNAUTHENTICATED ! So we don't need to find or bruteforce an account to perfom this exploitation.
Before trying to run the exploit with the script, we can search if the exploit is inside the database of Metasploit to gain time and maybe get a meterpreter session.
As you can see, we have an output result which is close to our exploit (the second one):
Choose it, complete options like:
TARGETURI = /spip/
RHOSTS = [IP target]
LHOST = [IP attacker]
And run it !
We have now an access to the machine with the www-data user. We can get the user flag to go to the /home/think directory.
Now, I will upload an automatique script to enumerate possible privilege escalation which are possible with the web user. I can also try to have the control to the think user which can have more privileges to reach the root user.
After running linpeas.sh, I have this crucial information:
We have the private SSH key of the think user.
We download the SSH key, change permissions on it and run this command:
We have access to the think user now !
With the hint, they talked about "AppArmor". This is a system to control what the user can do (so, that's why we can't write with the think user.
We can check if there is really an AppArmor profile:
So, we have to do find a way to perform a privilege elevation by searching manually (we can't upload linpeas.sh because of the AppArmor).
The first command we can run is this one (to check SUID bit on a file):
We can donwload it and do some reverse engineering on it to firstly understand what actions this binary performs.
With Ghidra inside the main function, we can see some interesting strings (we can also just run strings run_container):
So, the bash binary and the run_container.shscript are executed. We can see the contents of the script to find something interesting.
The only thing you must see after reading it, it's the command docker use multiple times inside the script but not with tha absolute path. As an attacker, we think directly to a possible PATH injection. The problem is we can't write anywhere to create our custom binary docker...
Go back to our AppArmor profile. Because, we want to replace the script with a custom script for example but we don't have the permissions to achieve it.
We need to check our profile to know which restrictions are enabled:
As you see above, we have specific write denies on specific directories like /opt/** . But, this is not the case for /var/tmp/**
Next steps:
PATH injection
create our docker custom binary inside the /var/tmp
run /opt/run_container.sh
with a bash shell now, replace /opt/run_container.sh with your docker binary
run /usr/sbin/run_container to have a bash shell with root privileges
Honestly, it was quite difficult to see this at the first sight. I lost a lot of time to really understand what we have to do to get a root shell.
What we learned during this room:
SPIP CVE exploit RCE
AppArmor security kernel module
understand the profile system
PATH injection
It's my first writeup for a TryHackMe challenge. So, please be kind if you find some errors or bad explaination during your reading
We did it
