API Crash

Monthly Challenge - 47

Description

The application is a GraphQL-based web service that manages blog posts using TinyDB for storage and Graphene for GraphQL implementation. The application suffers from a thread safety vulnerability combined with insecure error handling. The vulnerable code path allows an attacker to corrupt the TinyDB JSON storage file through race conditions in threaded database operations, triggering GraphQL execution errors that subsequently expose a sensitive environment variable (FLAG). This occurs due to improper synchronization of concurrent database writes and the inclusion of sensitive data in error responses.

Exploitation

The application presents a GraphQL endpoint that allows users to query and mutate blog post data. A thorough code analysis during initial reconnaissance revealed the underlying tech stack: Python, Graphene (GraphQL), TinyDB (JSON file database), Jinja2 templating, and threading for asynchronous operations.

Vulnerable Code Analysis

The first step in analyzing the vulnerability is to examine the main execution flow where user input is processed:

query = unquote("")  # User input injected here
schema = graphene.Schema(query=GraphqlQuery)
schema.execute(query)  # First GraphQL execution with user input

The user's GraphQL query is URL-decoded and executed first. This allows the execution of GraphQL mutations like updatePost, which runs database operations in separate threads:

def resolve_update_post(self, info, id, content):
    t = threading.Thread(target=GraphqlQuery.update_post_in_db, args=[id, content])
    t.start()
    threads.append(t)

After all threads complete, a second fixed GraphQL query executes:

result = schema.execute("{ getPosts { id content } }")

The critical vulnerability lies in the error handling logic:

if result.errors:
    posts = json.dumps({"FLAG": os.environ["FLAG"]}, indent=2)
else:
    posts = json.dumps(result.data, indent=2)

Conclusion From Code Analysis

The application's architecture creates a race condition vulnerability through:

1. Non-thread-safe database operations: TinyDB is not designed for concurrent writes

2. Sensitive data exposure in errors: The FLAG environment variable is revealed when GraphQL queries fail

3. Controllable data corruption: User input can write malformed JSON to the database

The goal was to identify and extract the FLAG stored in an environment variable. Based on the analysis, the critical point was reaching the result.errors condition after the second GraphQL query execution. This was possible due to database corruption caused by race conditions in threaded writes.

Execution Flow

To trigger the vulnerable path, we needed to corrupt the TinyDB JSON file (data.json) such that db.all() in resolve_get_posts would raise an exception during the second GraphQL query execution.

The attack flow:

1. Send malicious GraphQL mutation: The mutation updatePost with malformed content value

2. Trigger race conditions: Multiple concurrent mutations increase corruption probability

3. Corrupt database storage: Malformed JSON written to TinyDB file

4. Cause read failure: Second query's resolve_get_posts calls db.all(), which fails to parse corrupted JSON

5. Expose flag: Exception sets result.errors, triggering the flag exposure branch

PoC

The proof of concept involves injecting a GraphQL payload that causes database corruption through concurrent malformed writes. The payload exploits the race condition by spawning multiple threads that simultaneously write invalid JSON to the same database record.

The payload used is:

{ a:updatePost(id:1,content:"{") b:updatePost(id:1,content:"\"") c:updatePost(id:1,content:"}") }

How the payload works:

1. Multiple concurrent operations: The single query contains three updatePost mutations with aliases (a, b, c), spawning three threads simultaneously

2. Database corruption: Each thread attempts to update record id:1 with malformed JSON characters ({, ", })

3. Race condition exploitation: Non-thread-safe TinyDB writes interleave, corrupting data.json file structure

4. Triggering read failure: The subsequent getPosts query attempts to read corrupted database via db.all(), causing JSON parsing exception

5. Flag exposure: Exception sets result.errors, triggering output of {"FLAG": os.environ["FLAG"]}

Risk

The vulnerability presents a significant risk as it allows attackers to exploit race conditions to corrupt application data storage and trigger sensitive information disclosure. By leveraging concurrent write operations without proper synchronization, attackers can manipulate application behavior to expose environment variables containing secrets, API keys, or other sensitive configuration data. This type of vulnerability can lead to data integrity issues and credential leakage, posing a severe threat to the application's security.

Remediation

1. Implement proper synchronization: Use threading locks (threading.Lock) around all TinyDB operations.

2. Remove sensitive data from error responses: Never expose environment variables in error output.

3. Use thread-safe database: Consider SQLite with proper connection handling instead of TinyDB for concurrent applications.

4. Input validation: Validate and sanitize content the field to prevent JSON-breaking characters.

5. Atomic operations: Consider queue-based processing instead of direct threading for database operations.

6. Defensive error handling: Use generic error messages in production, logging details internally only.

# Add thread lock (Fixed Code )
import threading
db_lock = threading.Lock()

def update_post_in_db(id, content):
    with db_lock:
        node = db.search(tinydb.Query().id == int(id))
        if not node:
            return False
        # Validate content doesn't break JSON
        if '"' in content or '{' in content or '}' in content:
            content = content.replace('"', '\\"')
        node[0]['content'] = content
        db.update(node[0], tinydb.Query().id == int(id))
    return True

# Fix error handling
if result.errors:
    posts = json.dumps({"error": "Internal server error"}, indent=2)

Flag

"FLAG": "FLAG{M4ke_It_Cr4sh_Th3y_Sa1d?!}"

Reference

1. https://graphql.org/learn/mutations/

2. https://dojo-yeswehack.com/challenge-of-the-month/dojo-47