There have been several interesting articles published on how to exploit the Jinja SSTI with several restrictions in place e.g. character restriction or access to the object restrictions. The very comprehensive article I have found with regards to Jinja Exploitation that covers almost all aspect can be found under the following URL: https://hackmd.io/@Chivato/HyWsJ31dI

However, there was a certain case that was not covered as a part of this article. What if we have SSTI in the field, which has limited payload size, e.g. email address which even by RFC3696 has size restrictions.

To get the working RCE payload, we need to somehow store the parts of the payload persistently to be able to access those parts from the template engine execution namespace.

Going straight to the solution we can use the “config” object which is the globally accessible object to store our payload. To do that, we send the payload to be executed inside the very short named URI parameter, then update one of the config items with that value passed in that parameter.

The following screenshot presents the sample request which would store a very long string passed as ‘a’ parameter in the config.a object.

tag

As we can see we can read that value from the config.

tag

Here comes the RCE with a reverse shell. First, we write our payload from the URL parameter ‘a’ to config.

tag

To confirm that the correct payload was saved to the config, we read the value from the config object.

tag

As you can see it is python reverse shell, then we run the payload with popen:

tag

Resulting in the poping shell.

tag

That would be a great challenge for the CTF combined with other restrictions bypasses. Hope that you enjoyed it.