HTB — CAP (Linux) | IDOR, FTP Credentials & Linux Capabilities

Cap is an easy difficulty Linux machine running an HTTP server that performs administrative functions including performing network captures. Improper controls result in Insecure Direct Object Reference (IDOR) giving access to another user's capture. The capture contains plaintext credentials and can be used to gain foothold. A Linux capability is then leveraged to escalate to root.

Reconnaissance / Enumeration

First, let's start with an initial Nmap scan. To speed things up, we'll scan all ports without version detection first.

Now that we know which ports are open, let's run a more targeted scan on those specific ports to detect service versions and run default Nmap scripts.

What can we see here:

• http-title: Security Dashboard // Possible app to explore
• gunicorn: Python server
• vsftpd 3.0.3: FTP
• OpenSSH 8.2p1 Ubuntu: Confirmation OS

Foothold / Initial Access

Let's try to access the web application:

Navigating the web application, we notice the URL structure: /data/2. The numeric parameter in it could be suspicious. This could be vulnerable to an IDOR (Insecure Direct Object Reference) attack, where we can access other users' data simply by changing the ID.

Let's try changing the value to 0 :

And indeed, packets were captured. We can even download a .pcap file containing network traffic data.

Let's open it in wireshark.

Analysing the capture, we can spot FTP traffic containing credentials in cleartext.

We now have two very valuable pieces of information:

• Username: nathan
• Password: Buck3tH4TFORM3!

Let's try these credentials on the FTP service first:

Login successful! We can now explore the FTP server to see if there is anything interesting.

We find a user.txt file. Let's download it with the get command. This gives us our first flag!

Now, remember that we discovered SSH on port 22 during our enumeration phase. A common mistake users make is reusing password across multiple services.

Let's test these credentials against SSH.

And indeed, the credentials work! We now have a proper interactive shell as nathan on the target machine.

Now that we have a foothold, let's move on to privilege escalation and try to get root access.

Privilege Escalation

To enumerate privilege escalation vectors, we transfer linpeas.sh to the target machine.

Unfortunately, by redirecting linpeas output directly to a file, linpeas got stuck prompting for a sudo password, breaking the interactivity of the script. Running it without output redirection would have prevented this issue.

So instead, we fall back to using getcap directly.

getcap is a command-line utility used to examine and display the file capabilities assigned to executable binaries. Running it recursively on the entire filesystem reveals something interesting

Multiple file capabilities were found, but one catches our eye more than the others.

cap_setuid allows a binary to change its user ID, meaning python3.8 can switch to any user on the system, including root (UID 0).

A quick search on Google and GTFObins get us to the following one-liner:

• -c allows us to execute Python code directly from the command line without needing a script file.
• import os gives us access to operating system functions
• os.setuid(0) sets our User ID to 0 (root), which is possible thanks to the cap_setuid capability
• os.system("/bin/bash") spawns an interactive shell now running as root

We now have a root shell! Navigating to /root, we find our final flag.

Lessons Learned

Attacker perspective :

• Always test for IDOR on numeric parameters in URLs
• PCAP files can contain credentials in cleartext
• Password reuse across services (FTP / SSH)
• Check Linux Capabilities with getcap_ during privilege escalation_

Defender perspective :

• Validate users can only access resources they own
• Never transmit credentials over unencrypted protocols
• Avoid assigning cap_setuid to interpreters like python

There's no spoon…