Jinja2 SSTI - Filter Bypass help needed

Sadly that one also triggers the content filter as it decodes it quickly.

I’d never thought of using that before though, so I am going to add those to my notebooks! Thanks!

Might be a silly suggestion, but can you use Jinja2’s |safe filter to disable the automatic escaping?

@svenkali said:

Might be a silly suggestion, but can you use Jinja2’s |safe filter to disable the automatic escaping?

Sadly this isn’t working either. As far as I can establish, the content filtering is happening before the code is sent to Jinja2.

Bump - I am still stuck :smile: :cry:

Type your comment> @TazWake said:

Bump - I am still stuck :smile: :cry:

Can you send me challenge URL ? It’s seem fun, I want to give it a try :blush:

@jkana101 said:

Can you send me challenge URL ? It’s seem fun, I want to give it a try :blush:

It isn’t a publicly accessible challenge, sorry. Its provided by a commercial enterprise to a client who given me access.

So, I am still stuck, but I’ve made some progress.

I can write to the HTTP referrer string and I can call request.environ.HTTP_REFERER in the SSTI, but it still remains static.

So for example: {{os.popen.request.environ.HTTP_REFERER}} doesn’t work but {{request.environ.HTTP_REFERER}} does actually print whatever I put in the referer field.

Oh my god… Taz asking for help?

So for example: {{os.popen.request.environ.HTTP_REFERER}} doesn’t work but {{request.environ.HTTP_REFERER}} does actually print whatever I put in the referer field.

So clearly the OS module is not wholly imported, just os.popen.request. Maybe something useful in there? Not 100% sure though without being able to look at it.

Then again that has absolutely nothing to do with the HTTP_REFERER string unless you are down a rabbit hole, it does seem like a perfect XSS opportunity only question is how to trigger it…

It could well be a rabbit hole. Right now I have no way to tell.

However it is a lab on Jinja2 exploitation so I think XSS isn’t really part of the lab builders plans.

I have space for 41 characters between the {{ and }} markers, so my options are limited.

I’d like to do an os.popen('id').read() at the very least but ( and ) are blocked so that doesn’t work. Sending a referer with variations of the (id).read() string didn’t work.
Using __getchilditem__ syntax makes some progress but quickly runs out of space.

Type your comment> @TazWake said:

It could well be a rabbit hole. Right now I have no way to tell.

However it is a lab on Jinja2 exploitation so I think XSS isn’t really part of the lab builders plans.

SSTI is a subset of XSS

As for the rest, the only bracket bypass I can think of uses parenthesis… somehow the backend must be using them or else would not be able to run. That means there is prefiltering prior to hitting the template… have you looked into py modules that do this?

Yeah - the content filtering happens before the data is sent through to the Jinja2 part. As far as I can tell its a custom set of filtering and it creates all kinds of issues.

For example, any attempt to submit a request with (),[],%, ,+, \, " (and a few other symbols) is rejected before it gets to the engine. It also rejects various encodings to try and sneak them past.

Bump - just in case anyone has any good ideas.

I figure you would have told us already if you knew (mainly a bump excuse), but were you able to narrow down what the filter is likely built on? Is it getting filtered in the web app, a modification to the backend server running Jinja2, python, etc.?

The filter is the first stage of the application, the exploit path is built on an authentication form. If you create a user who already exists, the subsequent messages are passed through the app to an SSTI-vulnerable application.

For example, if you create the first user as {{'7'*7}}@example.com, nothing happens. If you then resend a user creation request with the same email, you get a message saying 77777@example.com already exists.

What this means is that the first creation has to work, which means it has to get through the filtering in place on that stage - this largely excludes anything I’ve tried :cry: :smile: .

I’ve made some progress here.

Turn out if I use "{{ ...... }}"@a.bc I can now use () and other characters in the SSTI string.

It does mean I lose another two characters in the payload though. Now I need a 39 character attack :smile:

Sadly, I still cant get anything to work! :smile: :cry: :scream:

Whoever created that challenge needs a hug, or a puppy, or both.

Type your comment> @TazWake said:

Sadly, I still cant get anything to work! :smile: :cry: :scream:

So I don’t know too much about the topic, but maybe some brainstorming triggers an idea.
So from what I know, character limits don’t go well with filter bypass. So what came to my mind is to declare variables and use them in another payload.

Something like:
{{asd=config.base_}}@ab.cd
{{asd.subclasses()}}@ab.cd

So this way you solve the problem of the character limit.

PD: I just run a htb machine with jinja2 to try this, and looks like it could work.

EDIT: the syntax to define a variable is {% set test = ‘DeepPurple’ %}

@gamedeth said:

So I don’t know too much about the topic, but maybe some brainstorming triggers an idea.
So from what I know, character limits don’t go well with filter bypass. So what came to my mind is to declare variables and use them in another payload.

Something like:
{{asd=config.base_}}@ab.cd
{{asd.subclasses()}}@ab.cd

So this way you solve the problem of the character limit.

PD: I just run a htb machine with jinja2 to try this, and looks like it could work.

EDIT: the syntax to define a variable is {% set test = ‘DeepPurple’ %}

Thats pretty genius! I hadn’t thought about that at all. I wont get a chance to try it until next week but its given me some new ideas and new hope! Thanks!

Type your comment> @gamedeth said:

Something like:
{{asd=config.base_}}@ab.cd
{{asd.subclasses()}}@ab.cd

So this way you solve the problem of the character limit.

PD: I just run a htb machine with jinja2 to try this, and looks like it could work.

EDIT: the syntax to define a variable is {% set test = ‘DeepPurple’ %}
I was thinking of that too, but didn’t suggest it because it needed either the % character when using variables, which was thought to be blocked initially, or line statements enabled in Jinja2 with an unblocked prefix.

I was looking at the namespace feature in Jinja2 to get around that, but it all required far too many characters.

Good luck!