The software may use insufficiently random numbers or values in a security context that depends on unpredictable numbers.
Extended Description
When software generates predictable values in a context requiring unpredictability, it may be possible for an attacker to guess the next value that will be generated, and use this guess to impersonate another user or access sensitive information.
Time of Introduction
Architecture and Design
Implementation
Applicable Platforms
Languages
Language-independent
Common Consequences
Scope
Effect
Confidentiality
Other
Technical Impact: Other
When a protection mechanism relies on random values to restrict access
to a sensitive resource, such as a session ID or a seed for generating a
cryptographic key, then the resource being protected could be accessed
by guessing the ID or key.
Access Control
Other
Technical Impact: Bypass protection
mechanism; Other
If software relies on unique, unguessable IDs to identify a resource,
an attacker might be able to guess an ID for a resource that is owned by
another user. The attacker could then read the resource, or pre-create a
resource with the same ID to prevent the legitimate program from
properly sending the resource to the intended user. For example, a
product might maintain session information in a file whose name is based
on a username. An attacker could pre-create this file for a victim user,
then set the permissions so that the application cannot generate the
session for the victim, preventing the victim from using the
application.
Access Control
Technical Impact: Bypass protection
mechanism; Gain privileges / assume
identity
When an authorization or authentication mechanism relies on random
values to restrict access to restricted functionality, such as a session
ID or a seed for generating a cryptographic key, then an attacker may
access the restricted functionality by guessing the ID or key.
Likelihood of Exploit
Medium to High
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 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.
Demonstrative Examples
Example 1
This code generates a unique random identifier for a user's
session.
(Bad Code)
Example
Language: PHP
function generateSessionID($userID){
srand($userID);
return rand();
}
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.
This example also exhibits a Small Seed Space (CWE-339).
Example 2
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.
Application generates passwords that are based on
the time of day.
Potential Mitigations
Phase: 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.
Phase: Implementation
Consider a PRNG that re-seeds itself as needed from high quality
pseudo-random output sources, such as hardware devices.
Phase: 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.
Phases: Architecture and Design; Requirements
Strategy: Libraries or Frameworks
Use products or modules that conform to FIPS 140-2 [R.330.1] to avoid obvious entropy problems. Consult FIPS 140-2 Annex C ("Approved Random Number Generators").
Phase: Testing
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.
Background Details
Computers are deterministic machines, and as such are unable to produce
true randomness. Pseudo-Random Number Generators (PRNGs) approximate
randomness algorithmically, starting with a seed from which subsequent
values are calculated. There are two types of PRNGs: statistical and
cryptographic. Statistical PRNGs provide useful statistical properties, but
their output is highly predictable and forms an easy to reproduce numeric
stream that is unsuitable for use in cases where security depends on
generated values being unpredictable. Cryptographic PRNGs address this
problem by generating output that is more difficult to predict. For a value
to be cryptographically secure, it must be impossible or highly improbable
for an attacker to distinguish between it and a truly random value.
Weakness Ordinalities
Ordinality
Description
Primary
(where
the weakness exists independent of other weaknesses)
Description
