Vulnhub - Fristileaks walkthrough.


Over at, there are a load of virtual machines ready to be broken, hacked or used as a learning tool. I like a challenge, so I thought I would have a go. All that is required is a suitable VM player, such as virtualbox. For my first challenge, I chose the Frisileaks VM . The Challenge is aimed at a beginner, and is pitched to take around 4 hours.

Once the OVA is downloaded, it is simple to import into virtualbox. I chose to use Kali linux for my host machine, which I would also be launching attacks from. I modified the setttings of the VM, to use a host-only adapter, as I like to have control over what my VMs are doing. Especially when I have just downloaded a random VM from the internet. One that is made for Hackers no-less. Finding out that it did something nasty wouldn't be great, especially as part of the challenge is to have minimal information about the vm before you start.

I also start my VMs headless, so as I later realised, the DHCP IP assigned IP address was sitting on the console for me. The main reason for starting headless is to lower my impatence and not cheat by rooting the vm straight out the box. So my first task was to identify what IP address the VM had been assigned. Fortunately, this vm responds to ICMP pings, so discovery was as simple as running:

nmap -sP

This revealed 2 IPs in use on the subnet, (my kali machine) and (My target). If the machine hadn't responded to ICMP, I could have fired up wireshark and rebooted the machine. Lack of ICMP would would also mean any further nmap scans would need the -Pn option as well.

So now I have my target, I performed a quick and dirty top 1000 ports scan on the host, using the following command:

nmap -sV -T5

This in-turn revealed port 80 open, with apache 2.2.15 running WebDav and PHP. To start my investigate on the web side, the first thing I did was look at the robots.txt file. This file is used to tell search engines what to index and what to ignore. When looking in the file, it is trying to disallow the following directories:




Being from the UK, I wasn't sure what sisi is (after the challenge, I did look it up), but each of the 3 urls lead my to a picture of Alec Guiness as Obi-Wan Kenobi with the message "This is not the URL you are looking for".

Obi-Wan - These aren't the urls you are looking for...


At this point I downloaded the image and the source code. The source code was pretty sparse, just the image tag. The image was the same for all three, and when I ran identify on it, no metadata appeared to be present. For reference, the command I used to look for the metadata was:

identify -verbose 3037440.jpg

So, with the robots.txt seemingly leading no-where, I moved on the index page of the web server.

Keep calm and drink fristi


Apart from a large image (which again, I downloaded and ran identify on) saying "Keep calm and drink Fristi", there were a group of shout outs. I kept a note of the shoutouts, as it might be useful later (it transpired it wasn't, but hey). It then dawned on me that Fristi was a drink. A drink like beer, or cola, or may be sisi. A review of the source code also didn't really reveal much at this stage too. So I moved my web browser on to to see what I can find.

Aha. The admin portal. Password protected. With a big image.


Nelson - Haha

So, I download the image again and run identify on it as before. Again nothing is contained in the image. So now I start looking at the source code, for useful information. Comments are usally very help, and this page had 2 sets. The first one was:


<meta name="description" content="super leet password login-test page. We use base64 encoding for images so they are inline in the HTML. I read somewhere on the web, that thats a good way to do it.">



We need to clean this up for production. I left some junk in here to make testing easier.

- by eezeepz



 Looks like my next hint is that the images are inline and base64 encoded. Also the hint appears to mention the user "eezeepz". Scrolling down the page, I come across the next block of comments:


The double equals sign at the end is usually a good indicator of base64. Since that was my hint earlier, thats what I try. I run the following:

  cat >./base64img.b64 << EOM

Then paste in the everything between the comments. Once done, I hit return and type EOM. The promt is now returned. So, now I have the base64 image, Time to get the proper one. Running the following converted the base64 to the image file.

   base64 -d ./base64img.b64 > b64img.png

  The png was just a guess at this point, but once it was decoded, I ran the following:

   file b64img.png

   This confirmed the file was indeed a png. I ran identify on the image. As usual, the image did not contain metadata. But it was the image of some letters:

  So I have what could be a password. I give the combination a try, and bingo. I log in and I'm greeted with a file uploader. Since I now from nma (and the file extensions) that the web server is running php, I create a simple file to just run the phpinfo function. Its a helpful page, as it'll tell you how you passed variables to it. At this point the web server denies the upload. Only jpg/png/gif are allowed.

  Starting up burp suite, and switching my browser to use it as a proxy (I use foxy proxy for this quick change), adn jump through the hoops to get back to the page. The first thing I try is changing the extension, and that lets me up load the age. Great, so now I go to htt:// and see the page in all it's glory.

  So now I need a shell. Fortunately, kali has a load of shells, waiting for use. Since PHP was what the web server ran, I chose to use the laudnum reverse shell. I copied the shell from /usr/share/laudanum/php/php-reverse-shell.php to the area I was using to download the images. I edited the file to add the IP address of my kali machine and port to connect to (4444). Once complete, I set up netcat listing on port 4444, and up load the shell, renaming the extension. Once uploaded, I load the page of the new shell a see the new shell. A quick type of "whoami" reveals I am the web server (apache) user.

  Since I am the web server user, I have a look in the home directory. There is a file called "notes.txt" along with the usual folders for a web server. The notes.txt file reads:

hey eezeepz your homedir is a mess, go clean it up, just dont delete

the important stuff.


  So, the user eezeepz has a home directory. Good to know. First I decide on a nosey around the web server files, to make sure I haven't missed anything. The "checklogin.php" in the fristi directory reveals mysql login details, as well as a database and a username. I log on to the database, and realise that since I don't have the mysql database, I'm not root. Looking at the hackmenow database, and the single table, I realise that their is no further information to be gained. I make a note about the webserver and move on to eezeepz's home directory.

   After changing in to eezeepz's home directory, I notice another "notes.txt" file. This one says:

Yo EZ,

I made it possible for you to do some automated checks,

but I did only allow you access to /usr/bin/* system binaries. I did

however copy a few extra often needed commands to my

homedir: chmod, df, cat, echo, ps, grep, egrep so you can use those

from /home/admin/

Don't forget to specify the full path for each binary!

Just put a file called "runthis" in /tmp/, each line one command. The

output goes to the file "cronresult" in /tmp/. It should

run every minute with my account privileges.

- Jerry

  So, after running a few tests I was able to determine that the user running the script that output to cronresult was "admin", just like the home directory. I was also able to perform additional commands (like ls, which lives in /bin), by using a simple directory traversal cheat.

echo "/usr/bin/../../bin/ls /home/admin" >> /tmp/runthis

  This let me know that there were a few python scripts on the server, and that the cronjob itself was written in python. This was confirmed by running the ps command. To get a shell as the admin user, I created a file in the /tmp directory, with the contents of the shell form pentest monkey. I then told the cronjob to run the script as an argument for python. Python also lives in /usr/bin. This time I recieve the shell on port 1234, and I have netcat waiting. This is also good, because now, if I lose this shell, it will automatically restart 1 minute later.

   Now I have the new shell, I run whoami, to confirm I am indeed now the admin of the server. The next thing to catch my eye is another python script called I also notice 2 txt files, with jibberish inside them. Assuming that they have been encrypted, I have a look at the file in more detail:

#Enhanced with thanks to Dinesh Singh Sikawar @LinkedIn

import base64,codecs,sys

def encodeString(str):

    base64string= base64.b64encode(str)

    return codecs.encode(base64string[::-1], 'rot13')


print cryptoResult

  Looks simple enough. My next step is to build a decoder:

import base64,codecs,sys

def decodeString(str):

    base64string= codecs.decode(str[::-1], 'rot13')

    return base64.b64decode(base64string)


print cryptoResult

  I then run the contents of those 2 files through the decoder. Both return something that could be passwords.

sh-4.1$ python ./ `cat cryptedpass.txt`

python ./ `cat cryptedpass.txt`


sh-4.1$ python ./ `cat whoisyourgodnow.txt`

python ./ `cat whoisyourgodnow.txt`


  Running "sudo -l" tells me that although I have the passwords, I can't use sudo. Bit of a bugger. However, pentest monkey again comes up trumps with this little gem:

   python -c 'import pty; pty.spawn("/bin/sh")'

  Re-running "sudo -l" prompts me for a password, and I try "thisisalsopw123", which works. Sort of. The user isn't allowed to run sudo. The name of the second file was kind of cryptic, so I wondered if there were any more users on the system, before I try for root.

   Changing directory to /home indicates there is another user called "fristigod". I run su to the fristigod user and use what I hope to be Fristigod's password (LetThereBeFristi!) and now I am Fristigod. Cool. So can I sudo now? I run sudo -l again and get:

User fristigod may run the following commands on this host:

    (fristi : ALL) /var/fristigod/.secret_admin_stuff/doCom

 So, I run the command and get:

Nice try, but wrong user ;-)

  Bugger. So what now. I check out the permissions on the doCom program, and it has setuid and root is the owner. This is clearly the way, now what user do I need to run it? I've also got a password left over. Somehow while I am scratching my head over the last bit of the puzzle, I check out the user's bash history. This gives me the following command:

  sudo -u fristi /var/fristigod/.secret_admin_stuff/doCom

  I run it, and it tells me it needs an argument. I chose /bin/bash as my argument, and the shell looks no different. Hmm. I type whoami and bingo! I have root. I change to the root directory and then:

cat fristileaks_secrets.txt

Congratulations on beating FristiLeaks 1.0 by Ar0xA []

I wonder if you beat it in the maximum 4 hours it's supposed to take!

Shoutout to people of #fristileaks (twitter) and #vulnhub (FreeNode)

Flag: Y0u_kn0w_y0u_l0ve_fr1st1


   In conclusion, this was a fun first puzzle to get my head around. It was interesting, and well thought out. 




Display comments as (Linear | Threaded)

    No comments

Add Comment

Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
To leave a comment you must approve it via e-mail, which will be sent to your address after submission.
You can use [geshi lang=lang_name [,ln={y|n}]][/geshi] tags to embed source code snippets.
You can use [geshi lang=lang_name [,ln={y|n}]][/geshi] tags to embed source code snippets.

Submitted comments will be subject to moderation before being displayed.