CWE-330: Use of Insufficiently Random Values

Description:
The product uses insufficiently random numbers or values in a security context that depends on unpredictable numbers.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific
Parent weaknesses: CWE-693

Consequences:
  - Confidentiality: Other
  - Access Control: Bypass Protection Mechanism
  - Access Control: Bypass Protection Mechanism

Detection methods:
  - Black Box: Use monitoring tools that examine the software's process as it interacts with the operating system and the network. This technique is useful in cases when source code is unavailable, if the software w
  - Automated Static Analysis - Binary or Bytecode: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             
  - Manual Static Analysis - Binary or Bytecode: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             
  - Dynamic Analysis with Manual Results Interpretation: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             

Mitigations:
  - [Architecture and Design] Use a well-vetted algorithm that is currently considered to be strong by experts in the field, and select well-tested implementations with adequate length seeds. 
                   In general, if a pseudo-random number generator is not advertised as being cryptographically secure, then it is probab
  - [Implementation] Consider a PRNG that re-seeds itself as needed from high quality pseudo-random output sources, such as hardware devices.
  - [Architecture and Design] Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems. Consult FIPS 140-2 Annex C ("Approved Random Number Generators").

Demonstrative examples:
This code attempts to generate a unique random identifier for a user's session.
Because the seed for the PRNG is always the user's ID, the session ID will always be the same. An attacker could thus predict any user's session ID and potentially hijack the session.
function generateSessionID($userID){ srand($userID); return rand(); }

The following code uses a statistical PRNG to create a URL for a receipt that remains active for some period of time after a purchase.
This code uses the Random.nextInt() function to generate "unique" identifiers for the receipt pages it generates. Because Random.nextInt() is a statistical PRNG, it is easy for an attacker to guess the strings it generates. Although the underlying design of the receipt system is also faulty, it would be more secure if it used a random number generator that did not produce predictable receipt identifiers, such as a cryptographic PRNG.
String GenerateReceiptURL(String baseUrl) { Random ranGen = new Random(); ranGen.setSeed((new Date()).getTime()); return(baseUrl + ranGen.nextInt(400000000) + ".html"); }

Real-world examples:
  - CVE-2021-3692: PHP framework uses mt_rand() function (Marsenne Twister) when generating tokens
  - CVE-2020-7010: Cloud application on Kubernetes generates passwords using a weak random number generator based on deployment time.
  - CVE-2009-3278: Crypto product uses rand() library function to generate a recovery key, making it easier to conduct brute force attacks.
  - CVE-2009-3238: Random number generator can repeatedly generate the same value.
  - CVE-2009-2367: Web application generates predictable session IDs, allowing session hijacking.