Labs

BrineDock

A web foothold that leads to local access and a SUID misconfiguration on a non-standard binary.

Difficulty: Medium

BrineDock looked like a routine web target at first, but it turned into a clean lesson on why unusual SUID entries deserve immediate attention. Most of the path was simple enumeration and patient filtering, with a ==blue:backup lead== and a ==red:high-impact SUID mistake==.

!![amber] The chain was realistic: exposed backup -> reused creds -> unusual SUID -> root.

Reconnaissance

I started with a full TCP sweep so I would not miss secondary services.

nmap -sC -sV -Pn -p- 10.10.11.41 -oN nmap-brinedock.txt
Nmap scan report for 10.10.11.41
Host is up (0.11s latency).
Not shown: 65532 closed tcp ports (reset)

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.11
80/tcp   open  http    nginx 1.18.0 (Ubuntu)
8080/tcp open  http    Werkzeug/2.1.2 Python/3.10.6

Port 8080 looked more promising than port 80. I first tested a search endpoint for SQL injection, but responses were static and did not give any useful behavior. That dead-end pushed me back toward ==amber:content discovery==.

I also ran a focused header check to understand the application stack before brute forcing paths:

curl -i http://10.10.11.41:8080/
HTTP/1.1 200 OK
Server: Werkzeug/2.1.2 Python/3.10.6
Content-Type: text/html; charset=utf-8
X-Powered-By: Flask

That confirmed it was worth hunting for leftover development files.

Initial Access (Sanitized)

I moved to content discovery and found a backup path on the Flask service.

gobuster dir -u http://10.10.11.41:8080 -w /usr/share/wordlists/dirb/common.txt -x txt,bak,zip
/backup               (Status: 301)
/backup/app.bak       (Status: 200)
/login                (Status: 200)

The backup contained environment-style config values. One credential pair was reused for SSH by a low-privileged user, which became the ==blue:foothold pivot==.

ssh marin@10.10.11.41
marin@brinedock:~$ whoami
marin

Once I had shell access, I stabilized the session and captured quick host context:

python3 -c 'import pty; pty.spawn("/bin/bash")'
export TERM=xterm
hostnamectl
pwd
   Static hostname: brinedock
         Icon name: computer-vm
Operating System: Ubuntu 20.04.6 LTS

Privilege Escalation (Sanitized but Insightful)

I started with standard local checks.

id
sudo -l
find / -perm -4000 -type f 2>/dev/null

sudo -l was not useful, but the SUID list included a non-standard entry that caught my attention.

/usr/bin/passwd
/usr/bin/su
/usr/bin/find
/usr/bin/chfn
/usr/bin/chsh
ls -l /usr/bin/find
-rwsr-xr-x 1 root root 224848 May  2  2024 /usr/bin/find

This is vulnerable because SUID makes the binary execute with elevated privileges, and find can invoke helper actions. I initially checked for writable system scripts out of habit, but the ==red:SUID path== was the direct issue.

!![red] Non-standard SUID binaries should be treated as priority findings.

I validated there were no simpler alternatives before using that path:

sudo -l
getcap -r / 2>/dev/null | head
cat /etc/crontab

sudo policy was locked down, capabilities were uninteresting, and cron did not expose a writable root script. At that point, the SUID misconfiguration was clearly the intended escalation route.

I then used the standard documented SUID abuse workflow for find to transition from user context to root.

Proof (Sanitized)

whoami
root
cat /root/root.txt
flag output intentionally omitted to preserve the lab challenge

Key Takeaways

  • Non-standard SUID binaries should be prioritized during local enumeration.
  • Backup artifacts often contain credentials that survive into production.
  • Quick dead-end checks are fine, but pivot fast when evidence is weak.
  • find / -perm -4000 remains one of the highest-value manual commands.