cryptofreeeasy

Protocol Analysis 5: Is This Real?

metactf

Task: a DawgCTF protocol analysis challenge where Alice is supposed to tell Bob to encrypt the flag under her public key, but Bob's recv template accepts any public key alongside Alice's name. Solution: generate our own asymmetric key pair, send Bob the hello message with our public key substituted for Alice's, then decrypt the returned ciphertext with our private key using the service's asym_decrypt helper.

$ ls tags/ techniques/
rsaasymmetric_encryptionmitmprotocol_analysisalice_and_bobdawgctfpublic_key_substitutionunauthenticated_key
direct_bob_triggerchosen_key_attackpublic_key_substitutionasymmetric_decryption_oracleno_identity_binding

Protocol Analysis 5: Is This Real? — metactf

Description

Alice and Bob are using this cool new thing called asymmetric cryptography! Alice isn't gonna leak her private key, so how could anyone intercept the flag?

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

Challenge 5 of the DawgCTF Protocol Analysis series. All Protocol Analysis tasks share the same PDF manual and live server at https://protocols.live.

Protocol

From the manual, Challenge 5 is specified as:

Protocol key:
    A = alice
    B = bob
    X = any name

Alice                                          Bob
send: "Hello",B,"this is",A,"send the flag
      encrypted with this asymmetric key",pubA
                                              recv: "Hello",B,"this is",A,"send the flag
                                                    encrypted with this asymmetric key",pubX
                                              send: "here it is",{[FLAG]}pubX
recv: "here it is",{[FLAG]}pubA

The critical notation detail is X = any name in the protocol key. Bob's recv template uses pub_X where the X subscript means "any public key is accepted". Bob will then use that same key in his send to encrypt the flag, so whoever supplies the key also gets to decrypt what Bob sends back.

Service primer

  • All actions are HTTP POST requests to https://protocols.live.
  • POST /model/5 creates a fresh instance and returns {"conn_id": ...}.
  • POST /alice and POST /bob take {"conn_id": ..., "content": ...} and advance the corresponding participant's script.
  • Utility endpoints under /util/ ignore conn_id and provide cryptographic helpers:
    • /util/gen_asym_key_pair returns a fresh public and private key.
    • /util/asym_decrypt takes k:<priv>|d:<ciphertext> and returns plaintext.
  • The content field is a pipe-separated list of typed items type:value. Types are t (text), n (name), k (key hex), d (data / hex blob).
  • If a request ever errors, the instance is destroyed and you must create a new one.

Vulnerability

...

🔒

Permission denied (requires auth)

Sign in to read this free writeup

This writeup is free — just sign in with GitHub to read it.

$ssh [email protected]