
Web Application Exploitation | EP1 | C0m80 Vulnhub CTF challenge
We covered the solution for C0m80 Vulnhub where we demonstrated the exploitation of Mantis bug tracker web application and at the end escalated privileges on the Linux system using reverse engineering.
Mantis Bug Tracker is an open source issue tracker that provides a delicate balance between simplicity and power. Users are able to get started in minutes and start managing their projects while collaborating with their teammates and clients effectively. Once you start using it, you will never go back!
We used this exploit “Mantis Bug Tracker 2.3.0 – Remote Code Execution (Unauthenticated)”
We also demonstrated port tunneling in this challenge to access the internal port 65122 which was not visible during the first initial nmap scan.
Initial Foothold & Vulnerability Discovery
I started by scanning the machine and immediately spotted a login page for “Mantis Bug Tracker” software. A quick search on Exploit Database revealed a juicy password reset vulnerability (CVE) specific to the Mantis Bug Tracker version running on the target. This vulnerability allowed for resetting a user’s password just by providing their ID, and I found that only the password for “Alice” could be successfully reset. Once Alice’s password was reset, I logged in and began exploring the admin panel.
Exploiting an Insecure Feature
Inside Mantis Bug Tracker, an issue titled “remove insecure features” hinting at a “best FTP server” caught my eye, pointing to another potential vulnerability. I managed to download a file associated with this insecure feature, which was initially in a “backup” format (hexadecimal). I then used a script to convert this hex file into a binary, which resulted in an FTP executable and a necessary DLL file.
Analyzing the FTP Binary (Two Approaches)
I considered two paths for analyzing the FTP binary:
- The Hard Way (Reverse Engineering): I thought about using reverse engineering tools like IDA Pro to look for command injection or stack overflow vulnerabilities. I then used a tool (likely
radare2
or similar) to analyze the FTP binary. I ran commands to print the functions and assembly instructions, and then extracted strings. Analyzing these strings revealed the FTP server’s running port and instructions on how to use a “reporting feature” that involved a “report link.” Using OllyDbg, a debugger, I could see that after the program processed a URL for the report link, it executed a series ofCD
(change directory) commands without proper input filtering, confirming a command injection vulnerability. - The Easier Way (Exploiting the Reporting Feature): I connected to the FTP server using
netcat
. For example, the command would be something like:netcat [vulnerable_machine_IP] [port]
. When using the “report link” command (which I found from the string analysis), it prompted me to insert a link. I quickly identified this as a client-side attack vector. I then leveraged Metasploit to generate a malicious link using theexploit/multi/browser/firefox_proto_crmfrequest
module, setting myLHOST
andLPORT
. This generated Metasploit link was then pasted into the “insert link” prompt of the FTP server’s reporting feature. The moment “Bob” (a simulated user on the vulnerable machine) opened this link, a Meterpreter session was established back to my machine.
Privilege Escalation
From that initial Meterpreter session, I discovered a password manager file on the desktop. After downloading and opening it (using Alice/Alice credentials), I found credentials for various services, including RDP access to the vulnerable machine. I immediately logged into the machine via RDP. Inside the RDP session, I noticed a lack of permissions to browse a “backup” file/directory, but I did find an SSH directory (/ssh
) containing RSA keys. I deduced that Alice was a supervisor and decided to aim for an SSH session as Alice to gain root access.
An SSH connection was established as Alice using the found RSA key and the password “backups” from the password manager. The SSH port was 65122, which I had found from the SSH configuration on the vulnerable machine. The SSH command would look similar to: ssh -i [rsa_key_file] -p 65122 alice@[vulnerable_machine_IP]
.
I then remembered an NFS (Network File System) share running on the machine from my initial scan. I used a script called nfspy.sh
to enumerate and mount the NFS share. The command I used was: nfspy.sh [vulnerable_machine_IP] [NFS_share_directory]
, and the directory was later identified as /backup
.
The nfspy.sh
tool allowed me to interact with the NFS share. I changed the directory to “desktop” within the NFS context and uploaded a file. This uploaded file was a payload (generated with msfvenom
) designed to create a reverse shell (Meterpreter session) back to my machine. The critical part was that anything written to the /backup
directory (the NFS share) was executed with root permissions. This payload was then executed from the SSH session (as Alice, who had permission to execute files in the backup directory). This immediately resulted in a new Meterpreter session, this time with root privileges! I confirmed this using the Meterpreter command getuid
, which showed the user ID as root. I then dropped into a system shell using shell
and verified my user with whoami
and the hostname with hostname
.
Alternative (Harder) Exploitation Path via Command Injection in FTP Binary
I also revisited the command injection vulnerability in the FTP binary’s reporting feature. The idea here was to upload an exploit payload to the vulnerable machine (e.g., to C:\Users\Bob\Desktop\exploit.exe
) using the initial Meterpreter session. Then, I could craft a URL for the FTP reporting feature that, after opening an HTTP/HTTPS link, would use the CD
command (and potentially others) to navigate to the payload’s location and execute it. An example crafted input for the report link could be: http://google.com & C:\Users\Bob\Desktop\exploit.exe
. I also noted the possibility of a buffer overflow due to string copy
functions seen in the disassembly, which could be exploited to overwrite the return address and execute shellcode.
This challenge was a great example of how multiple vulnerabilities can be chained together to achieve full system compromise.
Post Comment