CWE-301 covers simple authentication protocols that let an attacker use the target machine itself to impersonate a trusted user. It is a design flaw in handshakes, so it matters most to people who build or implement challenge and response schemes.
How it happens
MITRE describes a mutual authentication protocol in which each side must answer a random challenge from the other by encrypting or hashing it with a pre-shared key. The same key is often used with many different entities.
The attack goes like this, as MITRE lays it out:
- The attacker claims to be a valid user and asks the server for the hash of a random value.
- The server returns that hash and asks for its own value to be hashed in return.
- The attacker opens a second connection to the server. In that connection, the attacker asks the server to hash the very value the server demanded in the first connection.
- The server answers. The attacker takes that answer back to the first connection.
- The server sees a correct response and authenticates the attacker as the impersonated user.
The attacker never knew the key. The server did the work for them.
Observed CVEs in the MITRE record: CVE-2024-11022, where a web server includes the nonce in its challenge and response mechanism and allows a replay attack, and CVE-2005-3435, where authentication succeeds if a user-provided MD5 hash matches the stored hash and so can be replayed.
What an attacker gains
The main result is successful authentication to the target as an impersonated user, with the privileges that user has.
How to find it
The record lists no formal detection methods. Review the protocol on paper: does the responder use the same key and the same message format as the initiator? Can an attacker open two sessions and carry values from one to the other? A design review or threat model is the best tool.
How to fix it
MITRE gives two direct fixes:
- Use different keys for the initiator and the responder, or a different type of challenge for each role, so a response made for one role is useless in the other.
- Make the initiator prove its identity before the other side proceeds.
Also bind each response to its session, so a value from one connection cannot be accepted in another. Where you can, use a well-reviewed authentication protocol instead of inventing one.
Quick check
Does the attacker need the shared key?
No. That is the point of the attack. They only need to relay the server's own challenge back to it on another connection.
