TryHackMe Publisher CTF Write Up
I will tell you the solution of the Publisher machine.
Note: Trials and errors made on this machine will not be covered in this article.
Port Scanning
FLAG 1
I did a directory scan with Dirbuster and found a directory called spip.
When I visited the Spip directory, I got a page like the one below.
I started scanning this directory and found many more subdirectories like the one below. I went through them one by one.
And there it was ! Under /tmp/cache/spip_versions_list.json it said spip version 4.2
I used Searchsploit to check if there was an exploit for this version. There I found the exploit that allowed me to make an RCE.
Using msfconsole, I ran the exploit by giving it the desired options and thus I was able to get a Meterpreter session.
To make it easier for me to go to the SSH directory, I copied the id_rsa file and made an ssh connection through my own kali machine.
I connected with SSH and the User Flag was there.
FLAG 2
When I checked the SUID bits, I saw a binary called run_container and it caught my attention.
With the help of a python http server I got this binary to my kali machine for review.
When I examined its contents with the strings command, I saw a bash file named /opt/run_container.sh, which means that this bash file is used by the binary binary.
I immediately went to the victim machine to examine this file. But there was a problem, I was getting the permission denied error even though I normally have read authorization on the /opt file. What was the reason for this?
The reason for this is of course App Armor. App armor is a tool that allows us to restrict a tool with rules. You can access this information with a short search on Google.
I went to look at App Armor’s rule files to better understand the rules written on the App Armor tool and to see which directories are restricted by which permissions.
As I have shown above, it seems that some restrictions have been made on ash.
NOTE: ash is the shell we are using right now.
When we look at the restrictions as I show below, respectively;
/opt/ directory reading is blocked
/opt/** with /opt/** blocked from writing to everything under /opt
…
But here we are allowed to write under the /var/tmp directory because the blocking should be done in /var/tmp/**.
I created a file called myfile to see if I could create a file here.
Then I check the rules again and I see that there is no read permission for /opt/, but this only prevents us from reading below it with the “ls” command. So I can still read /opt/run_container.sh.
This rule should normally be written as “deny /opt/** r”.
When I read this sh file as I show below, I see that it runs docker, but I see something else, do you see it too?
Docker is not given as a path, it is just written as docker. This is very dangerous because the attacker, which is us here xD, can use this situation by doing PATH injection.
So I immediately used this situation by doing PATH injection. So how did I use it?
When we look at the rules, we remember that they are written for the shell called ash, right?
First, I do PATH injection and add the /var/tmp folder that I have write rights to among the default paths.
Then I create a binary file called docker and authorize it to run. This file contains “/bin/bash -p” so I want to use bash command with privileged mode. I used this file first to switch to the bash shell and then to become root using the SUID bit.
If you pay attention, when I print the $PATH value, the shell we see at first is ash, but after doing the operation, it becomes bash.
Then I copy my docker file into /opt/run_container.sh and run my /usr/sbin/run_container binary with SUID bit and I’m ROOT!!!
If you look at the profile we just created using /bin/bash without running the suid bit file to become root, you can see that all App Armor permissions have been removed. As below, I can now do all the write and read operations not allowed by App Armor because I created a new shell profile.
Ty for reading CYA next !!
