Protocol Analysis 7: Mediation — metactf

Description

Alice send: pubA, A, certA, nA Bob recv: pubA, A, certA, nA Bob send: pubB, B, certB, nB, {B, nB, nA}privB Alice recv: pubX, X, certX, nX, {X, nX, nA}privX Alice send: {A, nX, nA}privA Bob recv: {A, nB, nA}privA Bob send: [FLAG]

Source: https://github.com/UMBCCyberDawgs/dawgctf-sp26/blob/main/Protocol%20Analysis%20(1-9)/Protocol_Analysis_chals.pdf

This challenge presents a simple authentication protocol between Alice and Bob. The goal is to drive the live service, satisfy Bob's authentication checks, and make him release the flag without possessing Alice's private key.

Recon

The service lives at https://protocols.live.

• POST /model/7 creates a fresh protocol instance and returns a conn_id.
• The same conn_id must be reused for both /alice and /bob inside that instance.
• Empty content to /alice triggers Alice's first send.
• Messages are pipe-delimited typed fields such as k:<hex>, n:<name>, d:<hex>, t:<text>.

Observed message shapes:

Alice first message:
k:<pubA>|n:alice|d:<certA>|d:<nA>

Bob reply:
k:<pubB>|n:bob|d:<certB>|d:<nB>|d:<sigB>

One subtle but important quirk is that signatures are verified over the literal typed-text framing, not over a reconstructed abstract tuple. Bob's signature verifies against:

t:n:bob|d:<nB>|d:<nA>

So when forging the attacker-controlled message for Alice, we must also sign the exact literal form:

t:n:mallory|d:<nB>|d:<nA>

Vulnerability

This protocol is vulnerable to an identity misbinding / mediation attack.

Bob signs (B, nB, nA), but Alice does not include Bob's identity, Bob's public key, or Bob's certificate in what she later signs. Alice only signs (A, nX, nA). That means an attacker can:

...