The Machine
Cap is a Linux machine running a Python/Gunicorn-based security dashboard. The dashboard lets authenticated users run network captures and download the resulting PCAP files. The intended path is IDOR on the download URL, then credential extraction from the PCAP, then Linux capability abuse for root.
It is a straightforward box but it covers two of the most common real-world issues that appear in web application assessments: insecure direct object references and plaintext protocol credential capture. The privilege escalation via capabilities is an excellent reminder to always run getcap after foothold.
| Port | Service | Notes |
|---|---|---|
21 | FTP (vsftpd 3.0.3) | Anonymous login disabled |
22 | SSH (OpenSSH 8.2p1) | Shell vector once credentials obtained |
80 | HTTP (Gunicorn) | Security dashboard, logged in as nathan |
Enumeration
$ nmap -sC -sV --min-rate 1000 -oA cap 10.129.9.89
Three open ports: FTP, SSH, and HTTP. Anonymous FTP login failed immediately. The web application on port 80 is where the attack surface is.
Directory enumeration reveals three endpoints: /ip, /netstat, and /data.
The /data endpoint runs a security snapshot and presents a download link for the resulting PCAP file. The dashboard itself is a Python/Gunicorn security monitoring web app.
The URL pattern for the PCAP download is:
/data/1A sequential integer ID with no authorisation check. That is an IDOR waiting to be tested.
IDOR: Accessing Another User's Capture
The current session generates /data/1. Changing the ID to /data/0 returns a different PCAP file from an earlier session belonging to another user. No error. No redirect. No authorisation check whatsoever.
GET /data/0 HTTP/1.1
Host: 10.129.9.89200 OK
Content-Disposition: attachment; filename="0.pcap"PCAP files are stored at sequential integer IDs with no ownership check. Any authenticated user can retrieve any other user's packet capture by decrementing the ID. This violates OWASP A01:2021 (Broken Access Control).
PCAP Analysis: Extracting FTP Credentials
Opening 0.pcap in Wireshark and filtering by the FTP protocol exposes a full authentication session in plaintext.
Wireshark filter: ftp
220 (vsFTPd 3.0.3)
USER nathan
331 Please specify the password.
PASS Buck3tH4TF0RM3!
230 Login successful.
FTP transmits credentials in cleartext. The username nathan and password Buck3tH4TF0RM3! are visible to anyone who can intercept the traffic, or in this case, anyone who can access the PCAP file via IDOR.
Initial Access: SSH with FTP Credentials
The next question is whether these credentials work on other services. Password reuse is common. SSH is the most valuable target given port 22 is open.
$ ssh nathan@10.129.9.89
nathan@10.129.9.89's password: Buck3tH4TF0RM3!Welcome to Ubuntu 20.04.2 LTS
nathan@cap:~$
FTP credentials accepted on SSH. The same password was reused across two different services with no isolation. This is OWASP A07:2021 (Identification and Authentication Failures).
User flag retrieved from /home/nathan/user.txt.
2da49c5d84c383e1e13abec0da018f30
Privilege Escalation: cap_setuid on Python 3.8
With a shell as nathan, the next step is privilege escalation. Standard checks: sudo permissions, SUID binaries, cron jobs. All clean. Linux capabilities are the next vector.
$ getcap -r / 2>/dev/null/usr/bin/python3.8 = cap_setuid,cap_net_bind_service+eip
/usr/bin/ping = cap_net_raw+ep
cap_setuid+eip on Python 3.8 means the binary can call setuid() to change its effective user ID. There is no setuid bit on the file itself, so find -perm -4000 would miss it. Capabilities are invisible without getcap.
With cap_setuid present, the exploit is a one-liner: call os.setuid(0) to become root, then drop into a shell.
$ python3.8 -c 'import os; os.setuid(0); os.system("/bin/bash")'root@cap:~#cap_setuid+eip misconfigured on /usr/bin/python3.8. A single Python one-liner sets UID to 0 and spawns a root shell. No password required. No SUID bit visible. Capabilities are a silent privilege escalation vector.
6169994c702f3b70e1c876a51c0dd169
Attack Chain
| Step | Technique | Result |
|---|---|---|
| 1 | Nmap scan | FTP, SSH, HTTP on Gunicorn identified |
| 2 | Web enumeration | Security dashboard with /data/<id> PCAP download |
| 3 | IDOR on /data/0 | Downloaded another user's PCAP file |
| 4 | Wireshark FTP filter | Extracted nathan:Buck3tH4TF0RM3! in plaintext |
| 5 | SSH with FTP credentials | Shell as nathan, user flag captured |
| 6 | getcap -r / | cap_setuid+eip on Python 3.8 discovered |
| 7 | os.setuid(0) one-liner | Root shell, root flag captured |
Vulnerabilities Found
| Vulnerability | Location | Impact |
|---|---|---|
| IDOR | /data/<id> | Access to any user's packet capture |
| FTP plaintext credentials | PCAP file | Username and password recovered from traffic |
| Password reuse | SSH service | FTP credentials valid for SSH access |
| cap_setuid on Python 3.8 | /usr/bin/python3.8 | One-liner privilege escalation to root |
Lessons Learned
- Always test IDOR on sequential URL parameters. Any URL containing a number is worth testing. Change
/data/1to/data/0immediately. The pattern costs nothing and catches a high percentage of access control failures. - FTP is not a secure protocol. Credentials pass in cleartext. If the traffic is captured anywhere, the credentials are exposed. Use SFTP or SCP. Always.
- Password reuse multiplies blast radius. One credential set should not open multiple services. Compromise on FTP should not mean compromise on SSH. Credential isolation per service is fundamental.
- Run getcap after every foothold.
find -perm -4000shows SUID bits. It does not show capabilities.getcap -r / 2>/dev/nullis a separate check and should be automatic. This box would have been missed entirely without it. - cap_setuid is as dangerous as a SUID bit. The capability grants the same privilege escalation path as setting SUID on the binary. Audit capabilities the same way you audit SUID files.