Walkthrough TartarSauce

Drx

CTF Walkthrough: TartarSauce

Introduction

The machine to pwn

Specifications of the box

  • Target OS: Linux
  • Services: HTTP
  • IP address: 10.10.10.88
  • Difficulty: Hard

Weakness

  • Plugin WP GwolleContents

The following writeup shows the process I used to capture the user and root flags on TartarSauce machine at @ 10.10.10.88

This document contains my field notes I took when I was working through the box. Several intrusions were needed to catch the flags….

My way of thinking

The first step consists of the reconnaissance phase as ports scanning, banner grabbing, misconfigurations and so on. The second one to find the weakness, then, the attack itself, finally the privileges escalation called “post exploitation phase”.

Network configuration

Before doing some investigation, we configured our network like this:

Network configuration

After the configuration, we are going to check it before working.

Network configuration check

As we can see, the network is well setting up. The resolution is well done and give us the IP address of the box. That’s pretty cool.

Ports scanning: Recon

During this steep we are going to identify the target to see what we have behind the IP address. At first, we checked the TCP then UDP ports.

BTW, the results of the TCP ports are above:

The nmap output_1
The nmap_output_2

Explanations of the TCP scan

  • A web server under Apache on port 80
  • The box is also under Linux OS.

Then, we wanted the UDP open ports as well. A full ports scans will help us in our road. More ports are open more we are able to get in!!

The output Nmap UDP ports

Explanations of the UDP scan

No UDP ports are open, only TCP one.

For more clarity, we are going to make a summary in MSF.

Summary in MSF — TCP ports

So we have only one open port. Let’s focus on it

Enumeration

In this step, we are going to go more deeply on our findings above.

Step 1 The web service

  1. The check in our Browser
The browser’s answer

The result shows us the webpage. Also, it’s a picture of a Ketchup bottle. Nothing interesting for us at the moment.

So, It’s a basic web page without any information. Let’s see the source code of that page.

We would like to know if there are some leaks in it!

Source code_1
Source code_2

OK, so as we can see, there are no more information in the source code. Let’s continue ;)

Further enumeration

During this step, we are going to analyze more in deep the website. We are surly find the weakness during the process.

To manage it, we are going to use Burp and Gobuster and also CmsMap So, let’s go ;)

  1. Brute force of the Web page

We are searching some hidden directories and files that could give us a hint.

The hidden directories of the website

The result shows us a 403-error code for “webservices” that cannot allow us to check and an 301-error code for “Webservices” that we are going to check.

  1. Burp: Find the tree of the website

During this test, we would like to have more information about the target as much as possible.

The tree of the website

Ok, at this step, the result of our test shows us the tree of the website’s challenge. We can see some subfolders (“monstra”) and an admin page. Another interesting link, the robots.txt file.

Let’s check that and dig deeper.

Let’s check the robots.txt file

The robots.txt file

Ok, we have it. We can see that we have the upload system with “easy-file-uploader” and the “Database administration panel “. The other is not interesting for us.

Let’s check these pages. The first one is the “Welcome page” and the other “the admin”

Welcome page of the challenge

Then, let’s have a look at the admin page.

The Monstra admin page

With this information when know a little more about his functionality. The last step is to know the CMS!

In this topic, we are going to search the CMS of the website. Let’s see how we managed it:

The CMS investigation

As we can see the website has as a CMS WordPress. That’s a huge info for us. That’s the wood of the website. At this point, let’s dig more in WP.

5.1 Enumeration of the CMS : Plugins

Let’s check and found the plugins of the CMS. Please find the results above:

WP enumeration_1
WP enumeration_2

Ok, we have now the modules and the vulnerability of them. They are some of them are not updated!

As you can see there is one module that is screwed up. It’s “Gwolle Guestbook”. It’s our entry point for the intrusion!! Let’s continue our way ;)

  1. Summary of the enumeration

In this topic we are going to give a brief summary of the web section

Info of the target_1
Info of the target_2

As you can see from the screenshots, we have the resume info of the website and of the system.

So, the last step is to talk about the vulnerability

The Weakness

In this part, we are going to talk about the weaknesses to get into the box.

That is our entry point of the intrusion.

In other word, the vulnerability is a plugin of WP called Gwolle Guestbook

This flaw allows us to execute arbitrary code and gives us an RCE on the remote machine. To be clearer it’s an RFI in the plugin.

For more details, let’s see the links bellow:

Weakness WP’s plugin

In this capture you will find some more details about the weakness to break the machine.

The details of the vulnerability

Exploitation: Houston, We Have a Shell

With all information we’ve got, we can make our intrusion on the remote system. We are going to enter by the web site.

We have:

  • The website: A CMS with WP
  • The flaw: Gwolle Guestbook
  • Port: 80

To get the foothold we are going to setting up our exploit time. To do that , we need a PHP reverse shell to upload to the target then, the Netcat to control the remote machine.

So, let’s screw up the box ;)

Let’s go at first with the website URL. We went to the weakness path then, had our attacker’s IP with port. In our case IP: 10.10.14.7 and port: 80

The path of the exploitation

Just load the page with the all path to get the reverse shell

Nb: First Upload attempt

Upload of our first reverse Php shell

As we can see, we tried to upload our Php reverse shell, but we got an error (cf error 404). We can see that the error gave us the correct name to be uploaded! It’s “wp-load.php”.

So, we changed the name of it and bingo it worked.

The Php reverse shell contains the IP of the attacker and the HTTP port!!

  1. Php reverse Shell with Ncat

Let’s go with the correct extension of the reverse Php Reverse Shell!!

The intrusion

Let’s explain a little the capture a little. So we have :

  • On the top we have the directory of the Php reverse shell. ( Nb:The Rport of our reverse shell configuration was 4444)
  • On the left we have our local python web server to do the upload
  • On the right we have the reverse shell with NetCat ( Connected to the port 4444)

Once in, we can check the remote system:

The remote system
The ID

We are in, that’s great ;) and we have the remote info of the system we intruded

Privilege Escalation

Once in we had to find some flags. The first one was the user flag, and the second one, the root flag of the machine.

- The user flag (Not easy cause there was a protection on the user account).

- The root flag (system admin), more complex!

Catch the user flag

Always know where you are and where you want to go!!

Ok, so we browsed the user (onuma) directory to catch his flag.

The user directory

At this step, we were screw up! A protection under /bin/tar/ when I did sudo -l

Sudo protection

So, I had to bypass this shit!!

To did this, I did like that:

Bypass of sudo

Ok, after that the way is cooler for us. Let’s continue our road.

Then, just list the home of the user

The user flag

Let’s go for the root flag.

Catch the root flag: Priv escalation

In this last part we gonna see how to get root. Let’s talk about this topic.

At first let’s have a nicer shell to work

Nicer shell configured

Then, let’s investigate ;)

After lunching the script procmon.sh we have a nicer info about a directory called: “ backuperer”.

The backuperer script

The backups are found under /var/ as you can see :

The backups

Let’s see the backups script

The script

After that I executed it on my local machine to see where the backup went even with some errors!

So, let’s see that:

Local execution

Ok, so we can see that the backup went to /var/tmp/check/var/www/html

Let’s move to the root directory and the flag will be in the same path to catch it !

cp -r /var/www/html

cd html

rm index.html

ln -s /root/root.txt index.html

Then,

cat /var/backups/onuma_backup_error.txt

The root flag

Drx

Written by

Drx

Pentester |#WhiteHat | |#Pentester | #Pentesting |#Cybersecurity |#Linux | |#debian | |#kalilinux |#infosec | |#GNU | drx51@protonmail.com

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade