TL;DR

It's a combination of the previous boxes, relating to PDF generation & Openfire. There are a few dummy rabbit holes making this machine less interesting. As a requirement from the HTB team, I will set a password for this writeup but you can join the discord to gain the secret.

USER

Use NMAP, Naabu, Dirsearch, FFuf, or other similar tools to perform information gathering, we will have this valuable information that is related to our target:

80/tcp open http     nginx 1.24.0
|_http-title: SolarLab Instant Messenger
|_http-server-header: nginx/1.24.0
445/tcp open microsoft-ds?
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows
6791/tcp open hnm

Actually, there's nothing interesting on Port 80; it though introduces we are dealing with a target that hosts an IM (instance messenger) service. And we can have some information for their team members:

Port 445 allows anonymous access meaning we can easily look up some documents via smbclient login with the -N flag:

With limited privileges at the beginning, we can only access the share Documents. There are some files in it, and then we can just download all of them using mget * to see if there's valuable information:

Then I found out there's a password file, Wow! Even though the target claims that they are professional in security on their introduction page:

There are a bunch of user/password creds listed. However, none of them are valid when I tried to login to port 6791, which is hosting a ReportHub web application on http://report.solarlab.htb:6791. Then I think there could be some pitfalls in this looks-like-simple password file. We can notice that there are the same usernames like [email protected], which is unusual; and the name black.byte is strange; AlexanderK and ClaudiaS are of same format. And Alexanderk = Alexander Knight?

They may try to fool around with a hacker. But we have the smb available here, so we can use it to enumerate users on the target via crackmapexec smb ${ip} -u anonymous --rid-brute 10000:

SMB 10.xx.xx.xx 445 SOLARLAB [+] solarlab\anonymous:
SMB 10.xx.xx.xx 445 SOLARLAB [+] Brute forcing RIDs
SMB 10.xx.xx.xx 445 SOLARLAB 500: SOLARLAB\Administrator (SidTypeUser)
SMB 10.xx.xx.xx 445 SOLARLAB 501: SOLARLAB\Guest (SidTypeUser)
SMB 10.xx.xx.xx 445 SOLARLAB 503: SOLARLAB\DefaultAccount (SidTypeUser)
SMB 10.xx.xx.xx 445 SOLARLAB 504: SOLARLAB\WDAGUtilityAccount (SidTypeUser)
SMB 10.xx.xx.xx 445 SOLARLAB 513: SOLARLAB\None (SidTypeGroup)
SMB 10.xx.xx.xx 445 SOLARLAB 1000: SOLARLAB\blake (SidTypeUser)
SMB 10.xx.xx.xx 445 SOLARLAB 1001: SOLARLAB\openfire (SidTypeUser)

Now we know we can access the machine using the usernames Administrator, blake, openfire. But the blake's credential does not allow us to login to the machine directly, neither for the ReportHub page.

I will then have to trial and error. The final answer is blakeb:ThisCanB3typedeasily1@, which takes the name of blake.byte and the format of AlexanderK/ClaudiaS:

On the ReportHub page, it allows us to request a leave, training or home office, and approving these requests, which match the files we downloaded from smb shares.

We can do a little search for ReportHub on the internet. But it's nothing like the one called ReportHub irl. So if you search through for open CVEs, ReportHub won't give you anything. We will have to look for entrances that allow us to 'talk' to this web app.

The last one, named Travel Approval, allows us to approve the requests for the stuff by generating a PDF with the image of our signature:

For exploitation related to PDF file, we should always download the file to check its metadata or signature (this is the 3rd PDF related box on HTB). Then I found out the name ReportHub is a rabbit hole! It's the ReportLab we need to focus on:

Reportlab is a Python library for generating PDFs and graphics. Attackers can inject malicious code into an HTML file that will later be converted to PDF using software that relies on the ReportLab library. The aka CVE-2023-33733 has a POC that we can directly utilize:

We can intercept the POST request to API travelApprovalForm. Then inject the malicious HTML for the travel_request parameter. The only thing we need to modify is the command we want to execute in the POC. Since it's a windows machine, just grab one of the windows reverse shell script that would work for the target.

Then we get the reverse shell of blake who owns the user flag: type c:\users\blake\desktop\user.txt.

ROOT

As a usual habbit, I would like to use msf to generate a stable shell:

We can run winpeas on this machine. But it seems the connection is bad, stucking at the point where winpeas trying to read the database files (in my situation). I just went through manual information gathering. With local port scanning we know the openfire service is available, which could be similar to the JAB box in last season:

I've found some sqlite database files, but there's no sqlite app installed on the machine. And They won't take part in our future exploitation. But I just go practising the base64 file transfering skill (in case there's a very limited-access situation irl). You can skip this part because I just want to note it down here for myself.

We can base64 encode the target into a txt file:

$content = Get-Content -Path 'users.db' -Encoding Byte
$base64 = [Convert]::ToBase64String($content)
$base64 | Set-Content -Path 'users_b64.txt'
Get-Content -Path 'users_b64.txt'

And decode it on our attack machine:

base64 --decode users_b64.txt > users.db

We own the creds of ClaudiaS and AlexanderK now, but they won't be helpful. The python app source code tells us that the web app runs on local port 5000, then is reversed to outside network by nginx.

Now let's check the openfire service, because it tends to be vulnerable all the time. The interface of Openfire runs on localhost:9090 by default, and we can also easily discover this with the command netstat -ano on a windows machine. In order ot access the GUI on the local ports in a reverse shell, we need to perform Port Forwarding. There are many options for this, i.e. msf, chisel, proxychains4, etc. As you may know by reading my previous posts, I like Ligolo-ng (not gonna explain this. Just check for its documentation for usage if you are interesting):

It indeed runs openfire on 127.0.0.1:9090. And we can discover that it's running the 4.7.4 version:

The JAB box runs the version of 4.7.5, which is vulnerable. And this is even older... Just leverage CVE-2023-32315, we can easily create an admin account to execute arbitrary command:

In the previous JAB box, I crafted a plugin to exploit. Therefore, I will use the jar file provided by the POC author to play this box. Simply upload the jar file as a plugin on Openfire:

Then we can check the server setting to discover this newly added management tool. Enter the password provided above and we can now access the openfire account for the machine:

There are many ways we can perform the attack to get a reverse shell now. I prefer upload a msfvenom shellcode to the target, getting a stable reverse shell for future exploitation:

And we have the user openfire on metasploit:

Now we can enter the openfire directory under C:\, which we did not have the privilege as blake. And I see the embedded-db folder which contains the authentication logs and database configuration of Openfire. It stores important information such as login credentials:

Just a quick scanning, I found some juicy finding locates at the openfire.script file:

The credential of Administrator has been recorded inside the script file. We can easily identify it's the Administrator of domain solarlab.htb, not only the admin of the Openfire. It indicates the password hash of administrator used to set up the Openfire service. This could be the same password for Administrator uses to login the local machine as well:

But the hash are under certain encryption by Openfire. It requires a SecretKey (salt) to encry to password that stores on the server. Go down the script, the SecretKey (named passwordKeyhere) is just in plain text:

We can use hashcat to crack this, but it requires certain extra steps with the salt. There's a convenient tool on github that automatically decrypts the Openfire hash.

Download the tool, compile the java source code and run. We will then get the password of Administrator. From now on, there are many ways to login as Administrator as well. I have generated 2 msfvenom shellcodes in this game, so I am just lazy to create another one. I use Runascs to prove the creds to work on the local machine first, then we can just type the root.txt using straight forward command:

ROOT.

Are you watching me?