So here’s my guide to another CTF from VulnHub called Flick:1. This one was actually released before Tr0ll:1, but I finished this one after as I was trolled so much on the first one I had to take a break and try something else.

As usual, I made sure the VM was NAT’ed, booted and -sn ‘d my way to an IP, followed by a full port scan.

2 ports, 22 running OpenSSH and an unknown service on 8881. There was some interesting text appearing as can be seen above (there’s enough to see but I’ve cropped the rest). I telnet’ed to 8881.

So I’m looking to flick a switch and open a door. As you can see anything I pass is returned to me with ‘OK’ which clearly is not. Poirot here is already beginning to lose hope as this and SSH (which of course I don’t have any passwords for) are seemingly the only 2 things I have to go on….

Next. SSH to the boxto see if anything is out of the ordinary.

A nice ASCII title and my expected password prompt. But what’s this you say? Loads of ostensibly trivial hex? (once again there’s lots more above but I’ve cropped the picture). Ok so my leads so far are random hex, or the random hex.

Let’s decode the random hex.

Shazam. This looks like Base64. Let’s decode…

…and decode, and decode, and decode. Burp’s decoder made this very easy fortunately. I didn’t count but it was more than 10 times in total. But alas, could this string be a password? We could guess some usernames and see if we can now SSH in, but I was thinking more of our switch that we need to flick.

With only 2 ports to start with and both have now been looked at, the “door” almost has to be a metaphor for port. So here we go again.

Ok, 80’s up. I appear to have been overrun by cats….. No, I didn’t say “awww” either.

The site only seemed to have one other page, a login page. Every attempt to modify the URL to point elsewhere resulted in the second screenshot below, of which none of the links went anywhere.

I tried admin:admin, admin:password etc just to see, no joy. I then saw that the page stated that demo credentials needed to be used, so I tried demo:password, demo:demo and I (unfortunately I suppose) managed to guess the credentials of demo:demo123 a few tries later.

Once logged in there were 2 immediately apparent differences. The ability to download pictures and upload new ones. Contrary to the title of this post, there was nothing ‘quick’ about any of the tricks I tried to get a shell. I uploaded a shell without issue but couldn’t for the life of me get it to give me anything meaningful. My upload was stored on the second page and even though I managed to get it to connect to my netcat listener, something was going wrong as it was just sending the text back. If I were smarter and could code a better shell maybe this would have worked, who knows.

Time to move away from the upload and go to the download. I intercepted the below request when downloading a picture.

Woohoo, a file path. The LFI minions in my head scream out to me and I go to work. Strike 1…

All of the above attempts resulted in a page which contained the following:

My ../ seemed to be stripped out in the response, so I tested the theory further by adding a ….// into the file path. Strike 2…

/image/download?filename=../....//../etc/passwd

Which resulted in the following:

Great, it’s only stripping out a single ../ so I padded out the file path until I struck gold. Strike 3?

/image/download?filename=....//....//....//....//etc/passwd

No, home run. I noted a couple of users that were quickly identifiable. It was at this point that I admit to being stuck for ages, as I tried poking around other locations to try and enumerate further information but didn’t get anywhere meaningful. Then I finally noticed the ‘laravel’ cookie and having no idea what laravel was, a subsequent Google search told me it was a PHP framework and further reading identified a database config file to be located at app/config/database.php. Back in Burp repeater I changed the location and removed ….// one set at a time until…

Now we’re in business. We have a file path to an ‘old’ SQLite database which I’m going to check out first. Back to repeater.

/image/download?filename=....//app/database/production.sqlite

Why I do believe those are credentials! Robin’s password didn’t work, but fortunately Dean’s did.

There were 2 files in dean’s home directory, message.txt and an executable called real_docker. Sudo -l didn’t work so I started by looking at the txt file which stated that Dean should be able to read Robin’s dockerfile and provides a location.

So I run the read_docker program and the syntax says I need to pass the location. Copying the one from the message.txt outputs the following.

I noticed the the SUID bit was set on the program so I could run it as the owner, Robin.

-rwsr-xr-x 1 robin robin 8987 Aug 4 14:45 read_docker

I tried all manner of creating files/folders in various places to see if I could write something that would execute as Robin and nothing worked. I finally created a link to Robin’s profile and tried to get Docker to read it.

I tried a standard hard link first which failed, then a symbolic link which didn’t which resulted in successfully reading robin’s .bashrc file. So maybe if it exists I should try and grab his SSH private key?

Created a file, made it read-only and logged in.

A sudo -l to see what robin can do works:

robin@flick:~$ sudo -l
Matching Defaults entries for robin on this host:
env_reset, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User robin may run the following commands on this host:
(root) NOPASSWD: /opt/start_apache/restart.sh

Off we go. I wanted to read what the script was actually doing but I didn’t have permission. Running it didn’t give me any indication apart from what I expected it to say.

Docker is out of date. Let’s see if there’s anything we can play with here. Quick Googling identifies the following:

Shortly after I found the file on github. So I grabbed it and looked and examined the file.

This is a Docker Image used to test container breakout exploit first posted here:
http://stealth.openwall.net/xSports/shocker.c
The container will attempt to find and print contents of the Docker host's /etc/shadow.
## Usage
To run the PoC exploit use:
docker run gabrtv/shocker
## Building
To modify source and rebuild, use:
docker build -t gabrtv/shocker .
...

So I ran the first command, the script downloaded some files, worked some magic and….