CWE-294 is the flaw where an attacker sniffs network traffic and then replays it to the server, getting the same result as the original message, or nearly the same with small changes. MITRE calls capture-replay attacks common and hard to defeat without cryptography.
It matters to anyone who designs a custom protocol, a device handshake, or a login flow where the proof of identity is a fixed value.
How it happens
Imagine a client that logs in by sending the MD5 hash of its password, and a server that accepts any request whose hash matches the stored one. An observer on the network does not need to crack the hash. They copy the message and send it again.
The root cause is that the message is valid forever and for anyone. Nothing in it says "this is the one and only time this message may be used" and nothing ties it to a specific session.
MITRE gives two observed examples. CVE-2005-3435 describes a product where authentication succeeds if the user-provided MD5 hash matches the hash in its database, which can be subjected to replay. CVE-2007-4961 is a chain in which cleartext transmission of the MD5 hash of a password enables attacks against a server that is susceptible to replay.
What an attacker gains
Messages sent in a capture-replay attack allow access to resources that are otherwise protected by authentication. They gain privileges or assume the identity of the user whose message they recorded.
How to find it
The record lists no formal detection method. Useful questions during review:
- If I record a successful login and send the bytes again tomorrow, does it work?
- Does every request carry something that changes: a nonce, a timestamp, a counter?
- Can the server remember which values it has already accepted?
A traffic proxy makes the test quick: capture a request, resend it unchanged, and see whether the server accepts it twice.
How to fix it
MITRE suggests two design steps:
- Use a sequence number or time stamp together with a checksum that takes it into account, so a message can be parsed only once.
- Sign messages with cryptography. Anyone who can listen can see sequence numbers, so the sequence number must be covered by the signature. Otherwise an attacker simply edits the counter along with the content.
In practice, add a server-issued challenge or nonce per login, reject reused values, expire them quickly, and run the whole exchange over an authenticated, encrypted channel.
Quick check
Does hashing the password before sending it stop replay?
No. If the server accepts the hash itself as the proof, then the hash is the credential, and a copied hash works as well as a copied password.
Why sign the sequence number?
Because it is visible on the wire. Without a signature covering it, an attacker can alter the number to match their replayed content.
