auth | T4QI-Blog

Reconnaissance & Traffic Analysis

I began by analyzing the provided network capture (PCAP) in Wireshark. The traffic showed an HTTP interaction on port 9000 between a client (192.168.1.50) and the server (192.168.1.100).

The Protocol Flow:
1. Client: Sends a GET /challenge request.
2. Server: Responds with 200 OK, providing a JSON object containing a random “challenge” string and a “nonce”.
3. Client: Sends a POST /verify request with a calculated response.
4. Server: Returns 200 OK if successful, or 401 Unauthorized if the calculation is wrong (as seen with the failed attempt from IP .51 in packet 33).

Reverse Engineering the Logic

By examining the successful requests and available leaked data (likely found in the unencrypted portions of the traffic), I recovered the hardcoded shared secret:

Secret Key: k3yM4st3r_S3cr3t!

I determined the server’s authentication logic required hashing the key combined with the challenge parameters. The correct algorithm for the “response” field was identified as:

$$\text{SHA256}(\text{Secret Key} + \text{Challenge String} + (\text{Server Nonce} + 1))$$

The Solution Script

I have developed a Python script, solve.py, to automate the handshake and retrieve the flag.

Key components of the exploit:

Session Management: Uses requests.Session() to maintain the connection.
Payload Construction:
The script dynamically calculates the valid response by incrementing the nonce and concatenating the parameters:
PYTHON
```
# Logic: SHA256( Key + Challenge + (Nonce+1) )
client_nonce = server_nonce + 1
payload_str = f"{SECRET_KEY}{challenge_str}{client_nonce}"
response_hash = hashlib.sha256(payload_str.encode()).hexdigest()
```
Execution:
The script sends the forged JSON payload to the /verify endpoint. If the hash matches the server’s expectation, the server responds with a JSON object containing the flag.

Result:

Running the script successfully bypasses the authentication mechanism and prints the [REDACTED] flag from the server response.