Ignite — TryHackMe Writeup

A walkthrough of the Ignite TryHackMe room — an easy Linux box running an outdated Fuel CMS with a public RCE, escalated via the PwnKit (CVE-2021-4034) pkexec vulnerability.

Enumeration

I first started with enumeration, since we are already given the target IP when doing TryHackMe boxes there is no need to perform much host discovery. How I usually start is by scanning the target using NMAP, a simple fast scan using the -F flag is enough here to see that there is a web server running on port 80 HTTP. Sometimes I’d perform a scan over all the ports just to make sure using nmap -T4 -Pn -sV -sC -O -p- IP but this time since it’s an easy box and the description already hinted a faulty web server configuration I opted to just trust my gut and use the fast scan.

After I took a look at the index page the server was hosting, I immediately spotted that a CMS called “Fuel CMS” is installed. Not only that, it seems like it was still in the installation phase, being able to see the setup screen and everything. I also found out that they were using version 1.4 which is pretty old. Before looking up if there are any exploits, I dug deeper into the system by logging in with the default credentials which are comfortably admin/admin.

Exploitation

I was sent to the management dashboard of the CMS and found a bunch of menus to look at. I found a page to upload assets and instantly thought about uploading some kind of reverse shell to get access to the server. After some attempting I resulted to looking up any exploits that might be applicable for this version of the CMS.

Indeed I found one — CVE-2018-16763 — that allows unauthorized Remote Code Execution, bingo. I started up my netcat listener and ran the python script to invoke a reverse shell. It hit.

I was in, got a reverse shell onto the server and I was logged in as www-data on an Ubuntu machine. I knew from here I won’t have any root privileges and the task was to find the user and the root flag on the machine. First one was pretty easy, I found the user flag in the home directory of my user.

Privilege Escalation

The second one I knew I had to do some privilege escalation, since it’s a root flag I was prepared to do some horizontal pivoting. I first took a look at the crontab and the SUID binaries, seeing if anything is misconfigured or there is anything interesting that has the SUID bit set and is running as root.

After some looking around I didn’t find any interesting SUID binaries but after running the LinEnum script I always keep up my sleeve I found out that the pkexec binary is pretty old, so old in fact that it predates version 0.117 meaning, we just found our way in.

After looking up some pkexec exploits, I found CVE-2021-4034 aka PwnKit, a classic privilege escalation. It roughly works by abusing the way arguments are stored in C. Effectively there is a way to just not pass any arguments to pkexec so argv is empty, the program then skips proper security checks. pkexec tries to recover by reading from environment variables like GCONV_PATH to find error handling paths. By leaving argv empty, so not providing arguments, and manipulating the aforementioned environment variables we can force pkexec to execute any code we want, but with root privileges!

Another problem I had was: how do I get the exploit onto the machine? curl wasn’t installed and wget also didn’t work to just pull it. I ended up copy-pasting the C code and Makefile onto the target machine and then compiling it myself using gcc. Since we had missing components on the system, it wasn’t able to compile for 32-bit targets but since our machine was a 64-bit target it didn’t really matter. I stripped the 32-bit targets from the Makefile using sed. Compiled and executed the binary and boom, we’re in.

Now that we got a root shell, it was just as simple as going into the root home directory and grabbing that sweet root.txt flag.

Remediation

To counteract such an attack it’s crucial to keep the system and its components up to date. Patching polkit to >= 0.117 and removing any unnecessary SUID bits will prevent attacks like this from happening. And of course don’t just let any old CMS lie around open and unconfigured but who would do that, right?

• exploitation
• linux
• security