WhiteHacks 2025 | Unbearable

looking at the challenge file, u can see that there is a simple AES challenge with a few key steps,

1. User Input Handling: The client sends data in hex format via a POST request. This data is converted to bytes.

2. Plaintext Construction: The user's data is concatenated with the secret flag (user_data + flag).

3. Padding: The combined plaintext is padded using PKCS#7 padding to match the AES block size.

4. Encryption: AES-256-CBC encrypts the padded plaintext using the pre-generated 256-bit (32-byte) key and 128-bit (16-byte) IV.

Block Size: AES operates on a fixed 128-bit block size (16 bytes), regardless of the key length (256 bits in this case). The padding is explicitly applied to align the plaintext to this block size. The use of a static IV across all requests is a security weakness but doesn't affect the block size.

Hence, the induvidual characters of the flag can be guessed by sending in a null byte, this will cause the flag bytes to be added. Then this string will be padded to be 16 bytes to find one block. This block would then be AES-ed with a 32 byte key and 16 byte IV which is static, hence the system is deterministic. Classic example of a chosen-plaintext attack.

This solve script exploits the AES-CBC encryption oracle with a static IV to recover the flag byte-by-byte using a chosen-plaintext attack. Here's how it works:

Key Attack Steps

1. Static IV Vulnerability:

   • The server uses the same IV and key for every encryption request.
   • Identical plaintext blocks produce identical ciphertext blocks, enabling comparisons.

2. Controlling Plaintext Blocks:

   • The server constructs plaintext as user_data + flag.
   • By carefully crafting user_data, the attacker aligns the flag bytes into predictable positions in the ciphertext blocks.

3. Byte-by-Byte Bruteforce:

   • For each flag byte (starting from the first):
     • Step 1: Send user_data of length 15 - (current_flag_length % 16) to shift the target flag byte into the last position of the first block.
       • Example: To leak the 1st flag byte, send 15 bytes of padding (e.g., \x00). The first block becomes 15_pad_bytes + flag[0].
     • Step 2: Guess all possible values (0-255) for the target flag byte.
       • Construct a new user_data = current_pad + known_flag_bytes + guessed_byte.
       • If the guessed byte matches the actual flag byte, the first ciphertext block will match the original (due to identical plaintext blocks and static IV).

4. Validation via Ciphertext Matching:

   • Compare the first ciphertext block of the guessed plaintext with the original ciphertext block.
   • A match confirms the correct guess, appending the byte to known_flag.

5. Termination:

   • Repeat the process with the first block of 16 bytes and continue the chosen plaintext
   • The loop stops when the flag ends with } (indicating completion) or after a predefined length.

Why This Works

• CBC Determinism: Static IV + key ensures identical plaintext → identical ciphertext.
• Controlled Alignment: Adjusting user_data length forces flag bytes into predictable block positions.
• Bruteforce Efficiency: Only 256 guesses per byte (feasible for short flags).

Example Flow

1. Leak Flag[0]:

   • Send user_data = 15 bytes.
   • Server computes: 15_bytes + flag[0] + flag[1...].
   • Guess flag[0] by comparing ciphertext blocks.

2. Leak Flag[1]:

   • Send user_data = 14 bytes + known_flag[0].
   • Server computes: 14_bytes + flag[0] + flag[1] + flag[2...].
   • Guess flag[1] by matching ciphertext blocks.

3. Repeat until the full flag is recovered.

Critical Vulnerability

• Static IV: Allows comparing ciphertexts for equality to infer plaintext contents.
• No Authentication: The server acts as an encryption oracle, freely providing ciphertexts for any chosen input.