Book a Security Review

Weakness · High

CWE-330: Use of Insufficiently Random Values

What it is

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

Likelihood of exploit: High1 exploited in the wildMITRE CWE 4.19.1

Severity (our rating)
High
Likelihood of exploit
High
Introduced during
Architecture and Design, Implementation
Exploited in the wild
1 known exploited CVE

What an attacker can do

  • Other (Confidentiality, Other, Access Control)
  • Bypass Protection Mechanism (Access Control, Other)
  • Gain Privileges or Assume Identity (Access Control)

How to prevent it

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 probably a statistical PRNG and should not be used in security-sensitive contexts. Pseudo-random number generators can produce predictable numbers if the generator is known and the seed can be guessed. A 256-bit seed is a good starting point for producing a "random enough" number.
  • Use products or modules that conform to FIPS 140-2 to avoid obvious entropy problems. Consult FIPS 140-2 Annex C ("Approved Random Number Generators").

Implementation

  • Consider a PRNG that re-seeds itself as needed from high quality pseudo-random output sources, such as hardware devices.

Testing

  • Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible.
  • Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

How to find it

  • 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 was not developed by you, or if you want to verify that the build phase did not introduce any new weaknesses. Examples include debuggers that directly attach to the running process; system-call tracing utilities such as truss (Solaris) and strace (Linux); system activity monitors such as FileMon, RegMon, Process Monitor, and other Sysinternals utilities (Windows); and sniffers and protocol analyzers that monitor network traffic. Attach the monitor to the process and look for library functions that indicate when randomness is being used. Run the process multiple times to see if the seed changes. Look for accesses of devices or equivalent resources that are commonly used for strong (or weak) randomness, such as /dev/urandom on Linux. Look for library or system calls that access predictable information such as process IDs and system time.
  • Automated Static Analysis - Binary or Bytecode. According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Bytecode Weakness Analysis - including disassembler + source code weakness analysis Binary Weakness Analysis - including disassembler + source code weakness analysis
  • Manual Static Analysis - Binary or Bytecode. According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies
  • Dynamic Analysis with Manual Results Interpretation. According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Man-in-the-middle attack tool
  • Manual Static Analysis - Source Code. According to SOAR, the following detection techniques may be useful: Highly cost effective: Focused Manual Spotcheck - Focused manual analysis of source Manual Source Code Review (not inspections)
  • Automated Static Analysis - Source Code. According to SOAR, the following detection techniques may be useful: Cost effective for partial coverage: Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer
  • Architecture or Design Review. According to SOAR, the following detection techniques may be useful: Highly cost effective: Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

CWE-330 on MITRE's CWE site

Exploited in the wild: 1 CVE

Vulnerabilities caused by CWE-330 that attackers have used, from CISA's Known Exploited Vulnerabilities catalog, newest first.

All known exploited vulnerabilities

H2 Security

Found it in your code?

We review where it appears, fix it with your team, and check it was not already used against you.

Talk to our team

T Academy

Stop writing it in the first place

Learn to build software and systems without weaknesses like this one, with practice on real hosts in your browser, every objective checked on the machine.

Start free

Source: MITRE Common Weakness Enumeration, CWE version 4.19.1. CWE is a trademark of The MITRE Corporation.