Fuzzing {{7*7}} Till {{P1}}

By September 23, 2019 September 25th, 2019 Bugbounty
SSTI

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

28 Comments

Leave a Reply