Pre Foothold
nmap scan is taking a long time so I curled the IP and included the header
Updated the /etc/hosts file
nmap still taking long. Decided to just try to ssh in to see if the port was open. It was.
On a live engagement I wouldn’t recommend this of course
Generally I try to scan for all of the ports that are possible open and this can take a while but it taking much longer than anticipated. I decide to just run default scans to find common ports and versions. I get back confirmation.
I start running a directory scan as well in the background using gobuster. I’m going to check on that but my son has requested we build a robot. I’ll be back as soon as we’re done.
Got back to ffuf being done having found one subdomain.
I updated my /etc/hosts file to also include this subdomain. Once I do I visit the page and get a login page for something called Metabase
Tried “I seem to have forgotten my password” and it sends me to my admin. Oh dang.
I go back to the main page because I remind myself that there were team members listed
Any one of these could be a login user. I also discover a domain schema possibly for their email system, which could lead to a login name
I then ask, what exactly is metabase?
This makes sense for what the business is claiming they do.
I poke around for a bit, attempting default creds and looking for the chance for SQL injection. Eventually I happen across a recent RCE for Metabase, however it is for a specific version set, so I need to figure out what version of Metabase is running and what exactly the exploit is doing.
This is ALWAYS recommended practice, so let’s dive in.
First, a description of the Vuln
I find a PoC on GitHub based on the CVE number.
Looking at the Check for the leak of the setup-token the python code is making a request to a specific URL. Upon getting a 200 response it checks for the setup-token and if it is there alerts the instance is vulnerable.
The reverse shell script uses that leverage to execute a reverse shell on the machine and get it to reach out to a listener I setup. It POST a base64 encoded bash reverse shell as the payload.
Let’s see how we can find out what version of Metabase is running. Took a bit of scrolling through the source of the login page but I found the current version number
Looking back at the description of the RCE it looks like this version is vulnerable as all versions before 0.46.6.1 are vulnerable, so this instance was right before it. I also learn that this is an open source tool based on the version number starting with 0.
Ok, with that confidence let’s go ahead and run the check anyway.
According to the response and based on the README from the checker it looks like we have a vulnerable instance here.
I tried the revshell code that came with that repo but it wouldn’t work. I tried to replace the reverse shell with different versions and it wasn’t executing, so I found another shell that exploited the same vulnerability but this one worked!
We aren’t in userland though. Judging by the Username of the shell we dropped into, I believe this is a docker container. I confirmed that with listing all files.
I also find the metabase.db file, which is interesting. However I have NO tools to view or check out the file. I also do not have python to setup a webserver…but I do have netcat (nc)!
So I setup a listener and send the database file back to my machine.
And send the file
Now I need to view the file. I use SQLite database viewer…but the db seems empty…
Hmmm. Could be a dead end…Could also be an issue with how the file was transferred. After looking at the files size and seeing 0 I am going to assume that file transfer was unsuccessful.
It wasn’t that it was unsuccessful, it just wasnt a file, it was a directory. However pulling both of the .db files in that directory via netcat again and tried to open the files via sqlite database viewer. Got an error saying the file was not a database. Sadness.
I feel like I’m in a rabbit hole, so I backtrack to the beginning. I know I am in a docker container…what do my environmental variables look like?
Now…that is interesting. I try to use these creds on the webpage to login with no success. I then try them on ssh and…
Foothold complete :)
Post-Foothold
Well if we know one thing, we know docker is running here with containers running as well…
But I quickly find out that I cannot run or access any docker commands via the user I am.
I poke around for a while and decide I’m overthinking this, so I check some basic information from linpeas. I find that this version of Linux is out of date!
A quick google search finds this version is vulnerable to CVE-2023-32639! It looks like it’s using a tool called ‘unshare’ which allows the generation of a root shell using python. I run the exploit locally and…
pwned :)