tryhackme-ignite

Description: A new start-up has a few issues with their web server.

Tags: ctf, boot2root, privesc, exploit

Difficulty: Easy

Host: TryHackMe | Ignite (by DarkStar7471) — https://tryhackme.com/room/ignite

Deploy an easily hackable machine in the cloud and follow along with a walkthrough.

A note on screenshots:

I do these write-ups over the course of several days and because of the nature of how tryhackme spins up virtual servers they will get a different IP address each time. If you look closely at my screenshots you will occasionally see different IP addresses for the same target. Don’t get hung up on this — the tools and techniques work exactly the same regardless of which IP address the target has.

don’t get distracted

Initial Recon :

This is always the first step, and this is one of the most important steps a Penetration Tester takes.

Initial Recon

Nmap :

The first thing to do is to use the ( nmap ) tool, this is to find out all the open ports, find out what services are running on them, and find out the version of these services ..

sudo nmap -Pn -T5 -A 10.10.51.25

Nmap Scan

We see that only port 80 is working ..

1. The target is an Apache web server
2. Like a lot of web servers it has a robots file
3. It appears to be running the Fuel CMS (Content Management System)

Robots.txt :

Let’s briefly talk about the robots file. Website owners can use this file to tell web robots (a.k.a. “bots” or “crawlers”) whether certain pages on the site can be scanned or indexed. Naturally the bots can ignore those instructions and honestly the robots file usually just winds up being a target to tell attackers (and us) where to enumerate first. If you want more details about the robots file in general you can visit the The Web Robots Pages.

The target’s robot file only had one entry for “/fuel” and when we browse to that page we get redirected to the admin login page for the CMS.

Gobuster :

To further enumerate the machine I want to scan it for any, maybe some hidden, directories. For this I’m using ( GoBuster ) with the machine IP address and the wordlist with commonly used directory names:

gobuster dir -u http://10.10.51.254/ -w /usr/share/wordlists/dirb/common.txt

Gobuster (Dir)

A lot of directories! Went through all of there and one useful result was

(/fuel )

HTTP-Enum :

Now we will open the target IP from the browser ….

CMS

Now we see that we have the special version of this CMS

Version 1.4

We will not search for vulnerabilities for this version in this step

Now we will move to this DIR ( /fuel ) to know more information about this system

/fuel

Login

Now we see a login page …

We need credentials to access this system …..

We’ll quickly search for “ fuel cms default password ” the Internet ..

The default credentials for a lot of applications are “admin:admin” and this page confirms it. Sure enough, when we use those creds at the admin page we are brought to the admin dashboard. As you see

Default Credential vulnerability

Admin Dash

This is the dead end . Once you have access to the admin dashboard you can poke around a bit but there really isn’t much to do here. That being said, a skilled attacker or pentester could likely find ways to use this access to dig deeper and/or compromise the machine entirely. Also keep in mind that attackers are not always intent on total compromise or data theft — a script kiddie who got in here could easily deface the site and cause just as much headache…

I remember that we have the special version of this cms and now we will move to the solution to search for the vulnerability of this version ….

Version 1.4

Exploit :

In this step we try to use all the information we have collected to reach and control the target ..

exploit

Let’s turn on searchsploit to find out if this system is infected or not …

We’ll look for public exploit ….

using the command :

searchsploit cms fuel 1.4

searchsploit

As we can see we have 3 rce vulnerabilits

We will use this command to get the exploit code

1- First, we need to know the path of the exploit code in the device, so we will use this command.

locate linux/webapps/47138.py

This path will appear :

/usr/share/exploitdb/exploits/linux/webapps/47138.py

2- Now we need to include this file to the path we are in now , so we will use this command.

cp /usr/share/exploitdb/exploits/linux/webapps/47138.py .

Now when we open the exploit file, we see the following ….

exploit_code

Now we see the type of vulnerability : ( RCE )

Date: 2019–07–19

CVE : CVE-2018–16763

Now we need some modifications in the exploitation code …

If you don’t want to use a using proxy (burp or any other proxy software) comment out the proxy code in the exploit.

It will be as follows ..

1- We need to run the burp to read the request

2- We need to modify the variable in the code (url) for our target

It will be as follows ….

url = “Targrt_Url "

• Executed the code and got a shell…..

We will change the code and inject the ls command and see what the request looks like from burp ….

It will appear as follows …..

As we can see that the parameter filter is the one that is infected. It looks like this after we injected the ls . command ..

?filter=%27%2Bpi%28print%28%24a%3D%27system%27%29%29%2B%24a%28%27ls%27%29%2B%27

We will decode the url to know more about the payload ….

We’ll use a burp …

‘+pi(print($a=’system’))+$a(‘ls’)+’

Well we can have a reverse shell

https://www.exploit-db.com/exploits/47138