Cap

Metadata

• Platform: HackTheBox
• CTF: Cap
• OS: Linux
• Difficulty: Easy

Summary

Over a web service without any authentication mechanism, we can access a network surveillance dashboard, which provides PCAP files of the internal network traffic. By analyzing these logs, we can extract clear text credentials of a user account for FTP and SSH access to gain a foothold. The same web service requires extensive privileges for the python binary executing it, which we can manually leverage to spawn a shell as the root user.

Solution

Reconnaissance

An initial Nmap scan reveals three open ports:

Starting Nmap 7.95 ( https://nmap.org ) at 2025-02-05 13:34 CET
Nmap scan report for 10.10.10.245
Host is up (0.066s latency).
Not shown: 65532 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
21/tcp open  ftp     vsftpd 3.0.3
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.2 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 fa:80:a9:b2:ca:3b:88:69:a4:28:9e:39:0d:27:d5:75 (RSA)
|   256 96:d8:f8:e3:e8:f7:71:36:c5:49:d5:9d:b6:a4:c9:0c (ECDSA)
|_  256 3f:d0:ff:91:eb:3b:f6:e1:9f:2e:8d:de:b3:de:b2:18 (ED25519)
80/tcp open  http    Gunicorn
|_http-title: Security Dashboard
|_http-server-header: gunicorn
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel
 
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 86.12 seconds
 

Before diving into any possible vulnerabilities of services, let’s take a look at what the services offer us. If we try to log into the FTP server, we will be disappointed, as it does not allow for anonymous access, and we have no information about any users. Instead, let’s take a look at the web server.

The webpage presents some kind of security dashboard to us, monitoring security events and network activities. This by itself already look insecure, as we can enumerate any running internal services via the network status section.

However, the extended name of the security snapshot section reveals collection and analysis of PCAP files, which stores all network traffic passing through the severs network interface. The default URL of this section is http://10.10.10.245/data/2. The 2 in the very last part reveals that there are likely more endpoints we can check, since this endpoint does not present any data to us. While we don’t get any response from the endpoint 3, 1 and 0 seemingly do contain network packets we can even download. So let us take a look at some internal network traffic.

User Flag

Opening the file from endpoint 0 with Wireshark, we can analyze every one of the 72 network packets. Most of the entries contain HTTP, FTP and TCP connections. While skimming through the packets, we can witness a user connection to a webpage, which does not reveal anything useful to us, but we can also see a connection attempt to the FTP server, where someone logs in. As FTP uses unencrypted credential submission, we can extract not only the username, but also the password. The user seemingly also requested a file notes.txt, he was not severed the file, meaning we also do not have access to it.

nathan:Buck3tH4TF0RM3!

With the known credentials, why don’t we check for ourselves, whether the file exists. We log into the ftp server:

While there is not a file called notes.txt, we can download the user.txt claiming the first flag.

get user.txt
 
cat user.txt
6a5e6e8a0e24f272a507979e8c30bc04

Root Flag

Access to the ftp server alone is not enough to root the machine. It is likely, that Nathan uses the same password for SSH as well, so lets try to get the foothold.

This user does neither access to sudo, nor is part of any other permission group. Other users do also not seem to exist. So let’s check possible SUID exploits and compare them to GTFObins:

find / -perm -u=s -type f 2>/dev/null

Surprisingly, this does also no yield any results either, meaning we need to dig a little deeper.

As we noted earlier, the web server is able to present data about network connections. To achieve this, the running program needs to be somehow able to gain root permissions, since otherwise executables such as TCPdump do not work. So, let’s check what the server actually does. In /var/www/html we find app.py, which we can read. One section is especially interesting:

@app.route("/capture")
@limiter.limit("10 per minute")
def capture():
 
        get_lock()
        pcapid = get_appid()
        increment_appid()
        release_lock()
 
        path = os.path.join(app.root_path, "upload", str(pcapid) + ".pcap")
        ip = request.remote_addr
        # permissions issues with gunicorn and threads. hacky solution for now.
        #os.setuid(0)
        #command = f"timeout 5 tcpdump -w {path} -i any host {ip}"
        command = f"""python3 -c 'import os; os.setuid(0); os.system("timeout 5 tcpdump -w {path} -i any host {ip}")'"""
        os.system(command)
        #os.setuid(1000)
 
        return redirect("/data/" + str(pcapid))
 

As we can see, the script invokes a python call with the line os.setuid(0). This sets the SUID of the root user on demand, instead of having it set all the time. This is the reason we were not able to see this prior. However, this is only possible if the binary has the right permissions and capabilities, but since the webapp seems to work just fine, we can assume that this is the case. For our case this means, that we can invoke any python script, with the existing python environment and set the SUID for our context by ourselves. Let’s try that and spawn a shell as root.

Success! We have a root shell, allowing us to claim the root flag:

b0b52b23aef1af464f341703471e0a4b