Next up: Analytics, an Easy Linux box. Pre-auth RCE on Metabase, Docker escape via environment variable credential leak, and a kernel exploit chain for root.
Machine info
| Name | Analytics |
| Platform | HackTheBox |
| OS | Linux |
| Difficulty | Easy |
TL;DR
- Metabase 0.46.6 vulnerable to pre-auth RCE (CVE-2023-38646)
- Initial shell lands inside a Docker container
- Environment variables leak SSH credentials (
metalytics:An4lytics_ds20223#) - SSH to the host as
metalytics, then kernel exploit CVE-2023-2640 + CVE-2023-32629 (overlayfs) for root
Recon
RustScan + Nmap
| |

Open ports: 22 (SSH) and 80 (HTTP).
The login page redirects to analytical.htb, so I added it to /etc/hosts. Browsing the site reveals a landing page:

The login link redirects to data.analytical.htb - added that to /etc/hosts as well.
| |
Enumeration
Metabase login
Navigating to data.analytical.htb shows a Metabase login page:

Checking the /api/session/properties endpoint in the browser DevTools reveals the Metabase version - 0.46.6:

CVE-2023-38646
A quick searchsploit search confirmed an exploit exists:


CVE-2023-38646 - Metabase 0.46.6 Pre-Auth Remote Code Execution. The vulnerability is in the /api/setup/validate endpoint, which tests database connections during setup but does not require authentication. It accepts arbitrary JDBC connection strings, and the H2 database driver can be abused to fetch and execute a remote SQL file containing OS commands.
The attack flow:
| |
Foothold
Metabase Pre-Auth RCE
| |

RCE confirmed - running as metabase. Set up a more stable reverse shell:

Docker container
Checking the root directory, .dockerenv confirms we’re inside a Docker container:

Found a metabase.db folder with some database files:

Analyzed the files but nothing interesting. Decided to run LinPEAS.
LinPEAS inside the container
| |

LinPEAS found environment variables with credentials:

| |
SSH to the host
These credentials work for SSH on the host machine:

We’re out of the container and on the actual host as metalytics.
Privilege Escalation
Kernel version
Checking the OS version:

Ubuntu 22.04.3 LTS (Jammy Jellyfish) - this version is vulnerable to CVE-2023-2640 and CVE-2023-32629.
CVE-2023-2640 + CVE-2023-32629 - OverlayFS privilege escalation
These two CVEs chain together to exploit a flaw in Ubuntu’s OverlayFS implementation:
- CVE-2023-2640 - Ubuntu patched overlayfs to allow setting extended attributes (xattrs) on files, but failed to check whether the caller actually had the privileges those attributes imply. An unprivileged user inside a user namespace can stamp a file with
cap_setuidcapability. - CVE-2023-32629 - the overlayfs upper layer incorrectly inherits those attributes when the file is “copied up” from lower to upper layer, making them visible and honored outside the namespace, in the host context.
Chained together: create a user namespace, mount an overlayfs with a Python binary, set cap_setuid on it (unprivileged inside the namespace), exit the namespace, and the file now has cap_setuid honored by the host kernel. Call os.setuid(0) from that binary and you’re root.
| |

Root!
Takeaways (for OSCP)
- Check API endpoints for version disclosure.
/api/session/propertiesleaked the exact Metabase version without authentication. Always probe API endpoints. - Docker containers leak secrets through environment variables. When you land in a container, always check
envor run LinPEAS - credentials are often passed as environment variables. - Container credentials often work on the host. Password reuse between containerized services and the host OS is very common.
- Kernel exploits are a last resort but sometimes the only path. Check
cat /etc/os-releaseanduname -rto identify kernel-level vulnerabilities. The overlayfs chain (CVE-2023-2640 + CVE-2023-32629) is specific to Ubuntu.
References
- HackTheBox - Analytics
- CVE-2023-38646 - Metabase Pre-Auth RCE
- CVE-2023-2640 + CVE-2023-32629 - OverlayFS PoC
- Lain Kusanagi list (OSCP prep)
