APICrash - Race Condition Vulnerability

Writeup for the APICrash challenge on YesWeHack.

Table of contents

Description

The application is vulnerable to Race Condition within the updatePost workflow of the GraphQL API.

The vulnerability is caused when multiple threads attempt to update the TinyDB database simultaneously, which result in the JSON database getting corrupted. In this scenario, the application’s error handling catches the JSONDecodeError and exposes sensitive information (the flag).

The Race condition is introduced within the following lines:

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)

Exploitation

The exploitation process relies on forcing the application to process multiple update operations in parallel to trigger the collision during file I/O.

Analyzing the application functionality, an attacker could identify the GraphQL schema, exposing the updatePost query.

Graphene automatically converts snake_case Python fields (update_post) to camelCase GraphQL fields (updatePost). By default Graphene applies auto_camelcase=True when generating schemas.

How can we perform multiple operation simultaneously?

To avoid naming conflicts, we need to use aliases. This enables us to request multiple instances of the same field in a single HTTP request.

The attacker sends a query containing multiple aliased calls to updatePost. The server spawns a thread for each alias almost instantly.

The threads race to write to data.json. The lack of locking causes file corruption. When the application subsequently attempts to read the database to return the results, the JSON parser fails, triggering the error handler that reveals the flag.

PoC

{
  op1: updatePost(id: 1, content: "ExploitThread1")
  op2: updatePost(id: 1, content: "ExploitThread2")
}

Providing the previous GraphQL payload to the endpoint https://dojo-yeswehack.com/challenge-of-the-month/dojo-47 utilizes aliases to trigger simultaneous write operations and results in the disclosure of the flag environment variable content: FLAG{M4ke_It_Cr4sh_Th3y_Sa1d?!}

Risk

Integrity: The primary risk is database corruption. The race condition permanently damages the integrity of the data file, rendering the application unusable until the database is manually restored or cleared.

Availability: Once the database file is corrupted, all subsequent API calls to fetch or update posts will fail, resulting in a persistent Denial of Service for all users.

Confidentiality: As demonstrated by the capture of the flag, improper error handling triggered by this crash can lead to Information Disclosure, leaking sensitive environment variables or debug data.

Remediation

To fix this vulnerability, the application must ensure that only one thread can write to the database file at a time.

File-based databases like TinyDB are generally not suitable for concurrent web applications. Migrating to a robust DBMS like PostgreSQL or MySQL, or using SQLite (which handles file locking natively), would structurally eliminate this class of vulnerability.

It is recommended that a complete security review of the application’s code is carried out to identify and address any other potential security issues.