napaseke2 — avitoctf

Description

The supplied TCP service registers users and returns a hexadecimal HoneyPass token containing an XMSSMT-MD5 signature followed by the username. A valid token for the seeded VIP profile vipuser allows its full wall post to be viewed. The source package redacts that post's flag, so local testing can prove the cryptographic exploit but cannot recover the competition's real flag.

Analysis

Parameters and token layout

params.c configures XMSSMT with:

• MD5-sized nodes: n = 16;
• Winternitz parameter w = 256, hence one base-256 digit per byte;
• total tree height 32, split across d = 4 layers of height 8;
• WOTS length 18: 16 message-digest digits and two checksum digits;
• a four-byte global index and a 1,684-byte signature.

The signed token layout is:

index (4) || R (16) ||
bottom WOTS (18*16) || bottom auth path (8*16) ||
layer 1 WOTS || auth path || layer 2 WOTS || auth path || layer 3 WOTS || auth path ||
username

The public key is root || pub_seed, 16 bytes each. For index idx, randomness R, and message m, the bottom-layer WOTS signs:

H_msg = MD5(pad(2) || R || root || idx_as_16_bytes || m)

The 18 WOTS chain digits are the 16 bytes of H_msg, followed by the two-byte big-endian value sum(255 - digest_byte). The checksum matters: satisfying only the 16 digest inequalities is not enough.

Race condition and one-time-key reuse

Registration deliberately splits the stateful signature operation:

1. xmssmt_sign_message() reads the shared signing index and produces a signature.
2. The new user and token are written out.
3. Only then does xmssmt_update_signing_key() advance the shared index.

...