Nmap

Like always, I’m going to scan the IP Address by using nmap but I’m going to scan the full port first. Then, I’m going to scan the only open ports.

# Nmap 7.94 scan initiated Sun Oct  8 09:57:09 2023 as: nmap -p22,80 -sCV -oN nmap/analytics 10.10.11.233
Nmap scan report for 10.10.11.233
Host is up (0.026s latency).

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: Did not follow redirect to http://analytical.htb/
|_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 at Sun Oct  8 09:57:25 2023 -- 1 IP address (1 host up) scanned in 15.92 seconds

The Nmap scan results show that only two ports are open, SSH and HTTP. Based on the OpenSSH version, the target is most likely running Ubuntu 22.04 LTS, codename Jammy Jellyfish.

Additionally, Nmap discovered the hostname analytical.htb, which I added to my /etc/hosts file.

add hostname

Http: analytical.htb

I navigated to port 80 in my browser and was greeted by a simple, static website. I then attempted directory busting using Gobuster, but it did not reveal anything useful.

analytical.htb index

Http: data.analytical.htb

Next, I used ffuf to enumerate virtual hosts on the machine. This revealed a virtual host called data. I added this hostname to my /etc/hosts file.

add data hostname

When I navigated to data.analytical.htb in my browser, I was greeted by the Metabase login page. As usual, I tried various credential combinations (such as [email protected]:admin and [email protected]:root), but none were successful.

metabase login page

Metabase: v0.46.6

I then viewed the page source and searched for the Metabase version number. Thankfully, I found that it is running version v0.46.6.

metabase v0.46.6

After a quick search, I found a blog post from Assetnote which explains that Metabase version v0.46.6 is vulnerable to a pre-authenticated remote code execution (RCE), identified as CVE-2023-38646.

Metabase open source before 0.46.6.1 and Metabase Enterprise before 1.46.6.1 allow attackers to execute arbitrary commands on the server at the server’s privilege level. Authentication is not required for exploitation.

Additionally, I found an exploit on GitHub for this vulnerability. After successfully executing the exploit, I managed to gain a foothold on the machine.

Shell: metabase

I obtained a shell as the metabase user. However, based on the machine’s hostname, it appears that I am inside a Docker container.

shell as metabase

I then transferred the linpeas script to the machine and executed it. Linpeas revealed credentials stored in the environment variables that belong to the metalytics user.

linpeas found metalytics credentials

SSH: metalytics

Since port 22 is open, I attempted to log in via SSH using metalytics’s credentials, which was successful. After logging in, I checked for sudo permissions using the sudo -l command. Unfortunately, the metalytics user cannot run sudo commands on this machine.

ssh metalytics

I ran linpeas again, but it did not reveal any further useful information. Puzzled, I checked the kernel version, which is 6.2.0-25-generic.

OverlayFS: CVE-2023-2640 CVE-2023-32629

After a brief search, I discovered a blog post from WIZ discussing a vulnerability in the OverlayFS module in Ubuntu. This vulnerability has been assigned CVE-2023-2640 and CVE-2023-32629.

CVE-2023-2640: On Ubuntu kernels that include both c914c0e27eb0 and the patch “UBUNTU: SAUCE: overlayfs: Skip permission checking for trusted.overlayfs.* xattrs”, an unprivileged user may set privileged extended attributes on mounted files, causing these attributes to be applied to the upper files without proper security checks.

CVE-2023-32629: Local privilege escalation vulnerability in Ubuntu kernels where OverlayFS’s ovl_copy_up_meta_inode_data function skips permission checks when calling ovl_do_setxattr.

Shell: root

I found an exploit on GitHub targeting these vulnerabilities. I transferred the exploit to the machine and executed it. After successful execution, I managed to escalate my privileges and become root.

becoming root