Flick Challenge

Here is another interesting challenge we are going to solve. The vulnerable machine name is Flick. As usual, we started the game by hosting the image in a virtual machine and running an Nmap scan on the target.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

We found two ports: 22 running OpenSSH and an unknown service on 8881. As can be seen above, there was some interesting text appearing for port 8881.

We tried to telnet to the port 8881 and it was showing a message "welcome to the admin server". We tried to login by using some default passwords, but nothing worked.

The next port was SSH, so we tried to login via SSH, but when we connected to the SSH port, we got a nice wall of text returned to us.

We copied the whole hexadecimal text and give it to an online decoder to decode it in plain-text format.

As can be seen in the above figure, the decoded is looks like base64 encoded.

We started to decode the string. We decoded the output value again and again until we didn't find a simple string. At last we found something which looks like a simple text.

Now we again connected on 8881 and used that decoded text file as the password, and we got a success message that said, "Accepted! The door should be open now".

We understood "door should be open" to indicate that a new service had been launched on the target. Another quick port scan revealed that port 80 had been opened.

We found that port 80 http service is active.

So we opened the target's IP address via browser and found an image hosting web application on it. We found the login page, but we don't have the login credentials. We started to brute force the login panel with a huge list of credentials. While brute forcing we noticed a message on the login page that they have configured demo credentials for the first user, so we also add the username, password as demo:demo, and we successfully logged in.

After login we found that the application allows users to upload s photo and also to download their uploaded photo. We tried to upload a shell on the server, but it didn't work. But we noticed that when we were downloading an image from the server, it was retrieving the image file directly from the directory.

There could be a chance of local file inclusion attack (LFI).

So took the download request in Burp's repeater and passed the simple LFI payload and attempted to read the passwd file, but it failed.

We assumed there was some basic filtering going on, so I tried a different approach: ….//….//….//….//etc/passwd and it worked successfully.

Next we tried to trigger the default Apache file by using this payload: ….//….//….//….//etc /apache2/services-enabled/000-default and in the response we found the root directory of the application.

While browsing the application we noticed the 'laravel' cookie in the request, 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/database/production.sqlite

Again, back in Burp Repeater, we changed the location to: ….//….//….//….//var/www/flick_photos/app/database/production.sqlite

And it revealed the sqlite file. We found two users, Robin and Dean, as well credentials.

Robin's password didn't work, but fortunately Dean's did. We found two files on his directory: message.txt and read_docker file.

We opened the message file and found a message for Dean.

The script being referred to in the message was the read_docker binary. Running this and passing /home/robin/flick-dev output the following:

We again the ran the docker file for checking its usage syntax.

read_docker was basically reading the contents of /home/robin/flick-dev/Dockerfile, but we could pass it to any directory we wanted, so long as it had a Dockerfile in it. We assumed that we could read other files in /home/robin if we created symbolic links to it.

Now we tried to read /home/robin/.ssh/id_rsa, assuming that it existed and it worked.

We found Robin's private SSH key and copied it over to our machine as robin_id_rsa, changed the permissions so that it was read only, and typed in ssh -i /root/Desktop/robin_id robin@192.168.0.103

As can be seen below, we are successfully logged in as Robin.

We ran sudo -l to see what Robin can do:

We found that we had no access to any files, so we started to Google for the Docker script. After Googling a little bit, we found info about the program and its usage commands. Type in docker ps -l

And we found an Ubuntu image on the server. Next, we were able to run commands in this image as root.

We found that it was possible to mount the host OS's /root directory into the image's /root directory. This allowed us to access the contents of the host OS's /root and also opened the shell. Then we used the ls command to browse the directories.

Next we moved into the root directory and found two files over there.

We opened the flag.txt file, and it was a fake one.

Again we moved into the other directory and we found the real flag on that directory.

r00t! w00t!

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

References: https://leonjza.github.io/blog/2014/08/07/flick-can-you-find-the-flag/