Use of Insufficiently Random Values
|ID: 330||Date: (C)2012-05-14 (M)2017-10-12|
|Type: weakness||Status: USABLE|
|Abstraction Type: Class|
The software may use insufficiently random numbers or values in
a security context that depends on unpredictable numbers.
Extended DescriptionWhen 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.
Likelihood of Exploit: Medium to High
Applicable PlatformsLanguage Class: Language-independent
Time Of Introduction
- Architecture and Design
Related Attack Patterns
|ConfidentialityOther ||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_ControlOther ||Bypass protection
mechanismOther ||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
|Access_Control ||Bypass protection
mechanismGain 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. |
|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. || || |
|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. || || |
|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. || || |
|Architecture and DesignRequirements ||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"). || || |
|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. || || |
RelationshipsThis can be primary to many other weaknesses such as cryptographic errors,
authentication errors, symlink following, information leaks, and
|CWE-330 ChildOf CWE-905 ||Category ||CWE-888 || |
Demonstrative Examples (Details)
- 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. (Demonstrative Example Id DX-46)
- This code generates a unique random identifier for a user's
session. (Demonstrative Example Id DX-45)
- 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.
- CVE-2009-2158 : Password recovery utility generates a relatively small number of random passwords, simplifying brute force attacks.
- CVE-2009-0255 : Cryptographic key created with a seed based on the system time.
- CVE-2008-5162 : Kernel function does not have a good entropy source just after boot.
- CVE-2008-4905 : Blogging software uses a hard-coded salt when calculating a password hash.
- CVE-2008-4929 : Bulletin board application uses insufficiently random names for uploaded files, allowing other users to access private files.
- CVE-2008-3612 : Handheld device uses predictable TCP sequence numbers, allowing spoofing or hijacking of TCP connections.
- CVE-2008-2433 : Web management console generates session IDs based on the login time, making it easier to conduct session hijacking.
- CVE-2008-0166 : SSL library uses a weak random number generator that only generates 65,536 unique keys.
- CVE-2008-2108 : Chain: insufficient precision causes extra zero bits to be assigned, reducing entropy for an API function that generates random numbers.
- CVE-2008-2020 : CAPTCHA implementation does not produce enough different images, allowing bypass using a database of all possible checksums.
- CVE-2008-0087 : DNS client uses predictable DNS transaction IDs, allowing DNS spoofing.
- CVE-2008-0141 : Application generates passwords that are based on the time of day.
For more examples, refer to CVE relations in the bottom box.
White Box Definitions None
Black Box Definitions None
|PLOVER || ||Randomness and Predictability || |
|7 Pernicious Kingdoms || ||Insecure Randomness || |
|OWASP Top Ten 2004 ||A2 ||Broken Access Control ||CWE_More_Specific |
|CERT C Secure Coding ||MSC30-C ||Do not use the rand() function for generating pseudorandom
numbers || |
|WASC ||11 ||Brute Force || |
|WASC ||18 ||Credential/Session Prediction || |
|CERT Java Secure Coding ||MSC02-J ||Generate strong random numbers || |
|CERT C++ Secure Coding ||MSC30-CPP ||Do not use the rand() function for generating pseudorandom
numbers || |
|CERT C++ Secure Coding ||MSC32-CPP ||Ensure your random number generator is properly
seeded || |
- Information Technology Laboratory, National Institute of
Standards and Technology .SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC
- John Viega Gary McGraw .Building Secure Software: How to Avoid Security Problems the
Right Way 1st Edition. Addison-Wesley. Published on 2002.
- M. Howard D. LeBlanc .Writing Secure Code 2nd Edition. Microsoft. Section:'Chapter 8, "Using Poor Random Numbers" Page
259'. Published on 2002.
- Michael Howard David LeBlanc John Viega .24 Deadly Sins of Software Security. McGraw-Hill. Section:'"Sin 20: Weak Random Numbers." Page 299'. Published on 2010.