Дресс-код — alfactf

Description

Дресс-код

English summary: the target was a clothing shop where purchases were first written as encrypted pending transactions and later processed by a Rust validator. The goal was to obtain one item from each required clothing category and then call /check_dresscode to receive the flag.

Analysis

Transaction design

Source review showed that the Python shop created purchase transactions as JSON and encrypted them with AES-CBC:

plaintext = json.dumps(data).encode()
iv = os.urandom(16)
cipher = AES.new(AES_KEY, AES.MODE_CBC, iv)
ciphertext = cipher.encrypt(pad(plaintext, AES.block_size))
mac = hmac.new(MAC_KEY, ciphertext, hashlib.sha256).hexdigest()

The important flaw is that the HMAC covers only ciphertext, not iv.

The Rust validator repeated the same assumption:

fn verify_mac(&self, ciphertext: &[u8], expected_mac: &str) -> bool {
    let mut mac = HmacSha256::new_from_slice(&self.mac_key).expect("HMAC key error");
    mac.update(ciphertext);
    let result = mac.finalize().into_bytes();
    hex::encode(result) == expected_mac
}

In CBC mode, changing the IV changes the first plaintext block after decryption while keeping the ciphertext untouched. Because the MAC ignored the IV, the validator would still accept the modified transaction.

SQL injection primitive

The order comment update route was SQL injectable:

query = f"UPDATE transactions SET comment = '{new_comment}' WHERE id = '{order_id}'"

That let us update arbitrary columns of our own pending order record. We did not need to change the ciphertext or MAC at all; we only needed to change iv server-side.

Why only the first block mattered

The purchase JSON was created as:

trx_data = {
    'from': session['user_id'],
    'to': recipient_id,
    'items': [item['id'] for item in items_in_cart],
    'amount': total
}

Its first bytes were predictable:

{"from": "<user_id>",

...