CWE Reference
CWE-323: Reusing a Nonce, Key Pair in Encryption
Official CWE-323 CWE context with Glexia analysis, remediation guidance, related CVEs, and ATT&CK context.
Release 4.20weaknessIncomplete
Glexia's Take
CWE-323: Reusing a Nonce, Key Pair in Encryption
Reusing a Nonce, Key Pair in Encryption represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Executive Impact
- Access Control: Bypass Protection Mechanism,Gain Privileges or Assume Identity: Potentially a replay attack, in which an attacker could send the same data twice, could be crafted if nonces are allowed to be reused. This could allow a user to send a message which masquerades as a valid message from a valid user.
Developer Pattern
CWE-323 is the kind of defect developers can usually prevent with explicit validation, safer framework defaults, and tests that exercise hostile input or unsafe state transitions.
Confidence
high confidence from CWE-323, 4.20.
Official CWE Definition
CWE-323: Reusing a Nonce, Key Pair in Encryption
Nonces should be used for the present occasion and only once.
Developer And Remediation Guidance
How teams prevent and detect this weakness
Causes
- This code takes a password, concatenates it with a nonce, then encrypts it before sending over a network: Because the nonce used is always the same, an attacker can impersonate a trusted party by intercepting and resending the encrypted password. This attack avoids the need to learn the unencrypted password.
- This code sends a command to a remote server, using an encrypted password and nonce to prove the command is from a trusted party: Once again the nonce used is always the same. An attacker may be able to replay previous legitimate commands or execute new arbitrary commands.
Remediation
- Implementation: Refuse to reuse nonce values.
- Implementation: Use techniques such as requiring incrementing, time based and/or challenge response to assure uniqueness of nonces.
Detection
- Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Mappings
Related CVEs, CWEs, and ATT&CK context
ATT&CK Relevance
ATT&CK relevance is shown only when reviewed or responsibly inferred.