Analytics

User flag

Initial nmap:

$ nmap -sC -sV analytical.htb
Starting Nmap 7.93 ( https://nmap.org ) at 2023-10-08 18:35 CDT
Nmap scan report for analytical.htb (10.10.11.233)
Host is up (0.047s latency).
Not shown: 998 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 3eea454bc5d16d6fe2d4d13b0a3da94f (ECDSA)
|_  256 64cc75de4ae6a5b473eb3f1bcfb4e394 (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 8.85 seconds

The only service that we can see right away is a webserver on port 80. If we go the the page, there's a site without anything that appears exploitable, until you click on the Login button, which redirects to data.analytical.htb

On that site we see a metabase login page. Metabase is a service that doesn't have default credentials, and the few sets I tried did not succeed, so I figured there was an exploit to use.

By searching, I found CVE-2023-38646, with a proof of concept script at https://packetstormsecurity.com/files/174091/Metabase-Remote-Code-Execution.html .

I copied the script into ~/.msf4/modules/exploits/ and ran msfconsole, set the correct ip and port, then ran the exploit, which gave me a shell.

After poking around a bit, it became evident that this was inside of a container (the most obvious part was the /.dockerenv file). There didn't really appear to be anything of interest except for potentially the database. I didn't see any config files with anything useful, but the documentation indicates that that passwords may be stored in environment variables.

Running env in the current shell didn't reveal much of interest, except that SHLVL=1, so I was in a subshell. To get the pid of the metabase process, I ran:

ps | grep java

And saw that the pid was 1, then grabbed the environment variables with

cat /proc/1/environ

And saw a username and password with META_USER and META_PASS (note that the variables are separated by null bytes, which are not displayed by the shell).

We can then ssh into the box using those credentials and get the user flag.

Root flag

When enumerating the box, I didn't find anything interesting--the user can't run sudo, there were no unusual suid or sgid binaries, no processes running automatically, etc.. I ran linpeas.sh for good measure and didn't find anything useful there.

I then went looking for kernel security notices (the version was 6.2.0-25) at https://ubuntu.com/security/notices?order=newest&release=jammy&details=kernel then searched for any that had a proof of concept on Github.

After a lot of failed exploits, I found that CVE-2023-2640 seemed to work. The first time I ran it, it appeared to give me a root shell, but for some reason all files were owned by nobody and I could not read any of them. After restarting the box, the exploit worked successfully and I was able to get the root flag.