THM - Publisher writeup

Hi,

This is my writeup about the TryHackMe box “Publisher”.

Information gathering

As always we have to know what is in front of us:

nmap -Pn TARGET_MACHINE_IP -oN ports && nmap -Pn -sC -sV -p $(grep -Po '.*(?=/tcp)' ports | tr '\n' ',') TARGET_MACHINE_IP -oN services

This scan reveals only two ports:

I have checked the ssh service for password authentication and it accepts, but bruteforcing ssh is not attractive currently without knowing any usernames. I also take a look at the website, without luck.

All links are empty, except those on “Related Blogs”, but this is out of scope. Don’t attack them!

Next I run gobuster against the machine.

And there is a new page to take a look at! As always, search for version number.

Exploit SPIP

This version of spip is vulnerable to CVE-2023-27372.

I copied the script to my local directory and open it in nvim. The script is not very useful by default. I had to change one thing.

If you got some error because of urllib3<2, then look at this comment on github, it solved my problem with the requests module.

I’ve changed the script by adding this line to the send_payload function, right before the return command:

print(r.content)

After that I just run the script as it was. But the result is not as handy as I wish for…

Playing around with regex101, I was able to create a shell oneliner, which makes the output more handy or “humen readable”.

python ./51536.py -u "http://$target/spip" -c "cat /home/think/user.txt" | ggrep -Po '(?<=value\\="s\\:[0-9]{2}:\\")[^";]*' | awk '{gsub(/\\\n/,"\n")}1'

Result:

This looks way better now! To get the first flag, take a look into the users home directory:

SSH

To get ssh access, I just copied the ssh private key of user think to my local directory.

python ./51536.py -u "http://$target/spip" -c "cat /home/think/.ssh/id_rsa" | ggrep -Po '(?<=value\\="s\\:[0-9]{2}:\\")[^";]*' | awk '{gsub(/\\\n/,"\n")}1' > think_pk

And ssh into it!

PrivEsc

While looking around I found something suspicious:

This is strange, because as ls -la shows, I should be able to read the content of the directory. This discovery was accidental because I was looking for a script or something similar. But with that, I’m on the right track. We remember the instruction to the task:

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.

Because the permissions from the file system doesn’t match the observed behaviour, I decided to check for ACL and SELinux and also for AppArmor.

AppArmor is enabled, this must be the reason for the strange behaviour. AppArmor policies lays in the /etc/apparmor.d/ directory.

One lookup on the directory reveals the problem. The shell of the user think is ash, which has a profile on /etc/apparmor.d/.

When looking at the profile for the ash shell, I observed a hole.

The missing wildcard’s are the problem here. Without that, the deny rule only prevents me from changing a file with that name. But the content of the directory, is not affected by the deny rule. With this in mind and the fact that only the ash shell is restricted by apparmor, the solution is obviously.

The trick is explained on hacktricks: AppArmor Shebang Bypass

I created a file in the directory of /dev/shm/ which contains a bit of shell code.

#!/bin/bash
/bin/bash -pi

By executing the script, I got a restrictionfree shell.

The content of /opt is now readable! And yes, this is a big thing because there is a shell script which can be modified by our user. After my shell was freed from the apparmor profile, I decided to redo some of my previous actions. For example searching for SUID’s. The search didn’t show any useful Information before. But now, without apparmor restrictions, there is a SUID file /usr/sbin/run_container which is directly linked to the /opt/run_container shell script file.

How do I know that, you ask?

Yes there is no symbolic link, which could be revealed by just ls -la it, but like in many reverse engineering CTF’s, the command strings should not be overlooked!

Now there all the needed things to get privilege escalation.

• A script file which can be rewritten by our user: /opt/run_container
• A executable which runs as root and calls our script: /usr/sbin/run_container

After that, the root flag can be found in the /root directory.

Good luck! :)

---