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?

The Entry Point

There is no _start from a C runtime. The binary’s entry point is a minimal trampoline that sets up the stack pointer and jumps to the main loop:

.globl _start
_start:
    ldr sp, =stack_top
    bl main_loop
    mov r7, #1
    svc #0

The stack is allocated in .bss — 4kB, zeroed at load time by the kernel. The svc #0 after main_loop returns is the exit syscall; if the loop ever falls through, the process terminates cleanly.

The REPL Loop

The shell presents a peachykeen32> prompt, reads a line from stdin, and parses it into up to three null-terminated argument buffers. Command dispatch is a series of better_strcmp calls against known command strings.

check_cmd:
    ldr r0, =cmd_buf
    ldr r1, =str_exit
    bl better_strcmp
    cmp r0, #1
    beq exit_handle
    ldr r0, =cmd_buf
    ldr r1, =str_help
    bl better_strcmp
    cmp r0, #1
    beq help_handle
    ...

better_strcmp compares two null-terminated strings byte by byte and returns 1 on match, 0 otherwise. It’s not optimised — it doesn’t need to be. The input is at most a few dozen bytes per line.

Commands

The rand command is the most interesting because it touches three different syscall interfaces: openat (to get a file descriptor), read (to get entropy), and write (to display it). The syscall numbers are defined as equates at the top of the file.

.equ sys_read,   3
.equ sys_write,  4
.equ sys_openat, 322

Why Assembly

There is no practical reason to write a shell in assembly. The point is to understand exactly what happens between svc #0 and the kernel’s return. Every instruction is visible, every syscall is explicit, and there is no magic — no printf buffering, no errno, no dynamic linker. The entire binary is a static ELF with no PT_INTERP segment.

Building and Running

The project includes scripts for cross-compilation from x86:

arm-linux-gnueabihf-as src/m_peachykeen32.s -o build/peachykeen32.o
arm-linux-gnueabihf-ld -Ttext=0x10000 --no-dynamic-linker \
    -nostdlib build/peachykeen32.o -o build/peachykeen32

Run under QEMU or copy to an ARM board:

qemu-arm ./build/peachykeen32

There are also dependency installers for Arch, Debian, and Gentoo, plus GDB scripts for single-stepping through the syscall interface.

What I Learned

The Linux syscall ABI on ARM32 is straightforward — arguments in r0–r5, syscall number in r7, trap with svc #0. The return value is in r0. Negative values indicate errors, but without errno you either check the raw value or ignore it. String parsing in assembly is tedious but mechanical. The hardest part was managing the fixed-size argument buffers — a line longer than 256 bytes silently truncates, which is fine for a toy but would be exploitable in anything real.