
Hello Guys, here is my first blog. This blog will be a part of series where if any interesting vulnerabilities have been found, will be added to this list. In this blog poat I have shared my views on one of my recent findings – Server Side Template Injection. This was something different than other blog posts on the internet. In this methodology I’ve specified a way to exploit SSTI where traditional methods of exploitation failed. Please make sure you read till the end to understand the working of this methodology and make sure to subscribe to my blog.
Web Applications mostly use template engines to dynamically generate webpage or emails. These Template engines allow embedding users to input into the web application. Server-Side Template injections occur when a web application accepts input from users without sanitizing it properly.
Case Study:
Recently I was invited to a private program. But for 2 weeks straight there was no luck into finding vulnerabilities. All hopes were lost until I received an email from the program I was working on. The email read as follows:
Hello err0rr,
victim commented on your post:
4949
Thank you
This looked straightaway like an SSTI vulnerability. To confirm the existence of this, the data in all visible fields of the webpage were checked. On observing the comment section, the payload {{7*7}}{{7*7}} was inserted a few days back, which fired in the email. It was seen that in the comment section any user could comment on the objects on the webpages and in turn the owner would receive an E-mail. The payload didn’t fire on the same place but indirectly was a Email triggering payload. Thus the payload {{7*7}}{{7*7}} returned the output 4949 in the Email.
Attack:

To exploit this SSTI, we need to validate the working of exploit and then identify which back-end template engine is being used. To detect the running back-end engine there are some payloads that we need to test and based on the response we get from the server we can classify the template Engine. After testing all the payloads, it was found that Jinja2 is the Template Engine used by the server. Now the next step is to check if the template engine is running in sandbox or not. After testing the payload related to exploitation, a conclusion was derived that it is running in sandbox, as are most of template engines these days. So, if server encounters any kind of warning or error it won’t process the request and rejects the values indirectly not giving back results. It was also observed that the server is blocking single quote (‘) and Dot (.). It seems that blacklisting was done as an extra level of protection.

Here is the some list of payloads that I have tested:
{{7*7}} = 49
{%for c in [1,2,3] %}{{c,c,c}}{% endfor %} = (1,1,1)(2,2,2)(3,3,3)
{{‘7’*7}} = No email.
{{config.items()}} = No email.
{{ [].class.base.subclasses() }} = No email.
{{ [].class.base.subclasses() }} = No email.
{{”.class.mro()[1].subclasses()}} = No email.
As this results shows the Engine is running in sand-boxed environment with some kind of Single quot and Dot keywords blacklisting.
After trying all kinds of bypass available online, a conclusion was derived that there is hardly any way to access the global variable. So a wordlist was created with all the common variables used to bruteforce the injection point and see if any local variable was accessible. You can find the wordlist on my Github.
Bingo!
3 of the local variable got fired.
Payload:
Username: {{username}} First Name: {{first_name}} Second Name: {{last_name}}
Result:
I got an email as:-

Impact:
{%for c in [1,2,3] %}{{c,c,c}}{% endfor %} = (1,1,1)(2,2,2)(3,3,3)
We can do Application level DoS attack if we trigger the endless loop.
We can also access the local variable by brute forcing the common wordlist as I did. These two Proof Of concept was enough get this bug triaged and marked as P1.
SSTI Automation tool:
Tplmap assists in the exploitation of Code Injection and Server-Side Template Injection vulnerabilities with a number of sandbox escape techniques to get access to the underlying operating system.
Tips:
Use this below payload that can help you to detect multiple vulnerability in one go. It can detect Sqli, XSS, SSTI and CSTI.

Thank you for reading my blog. If you have any queries please do comment below.
//err0rr
Bhai… Maa kasm kya to post hai… Ek no… Very helpful
Thanks bro! 🙂
I configure burp suite certificate and proxy still burp not capture the request how many ways to fix?
Hi,
Did you added the certificate in “Trusted Root Certification Authority” You can check this portswigger post that might help you https://support.portswigger.net/customer/portal/articles/1783087-installing-burp-s-ca-certificate-in-firefox If you still face the same issue ping me on Twitter.
ek number post
Thanks AK! 🙂
sab payload try kiya yaha ka, but no luck
Did you able to get {{7*7}} = 49 payload injected?
Nice work bro ? 🙂
Thanks Dude! 😀
Can u plz add a video poc to learn only
Its a private program i cloud not share the POC video but in future if i create any lab i will post it here. 🙂
That’s awesome … thanks for the word list..! 🙂
Thanks! 🙂
Awesome work, tons of thanks for sharing Buddy.
Thanks Buddy!
Template injection In addition to the Dos attack, what other attack methods can be exploited?
You can also get RCE thats P1.
Nice blog bro
Waiting for more writeups
Stay Tuned 😉
Yes… But it didnt give 49
Please catch me on Twitter https://twitter.com/err0rrrrr
nice github reference mentioned and also great approach of exploiting it .. +1
Thanks a lot 🙂
Nice write up.. Sharing is caring.. Stay blessed and keep posting more write ups.. Video poc will add more charm to write up. Thanks dude.
Thanks for the comment. That motivates 🙂
How are we going to execute RCE with that? i tried many payloads but returned internal server error