All posts by rocco

CWE-325 – Missing Cryptographic Step

Read Time:21 Second

Description

The product does not implement a required step in a cryptographic algorithm, resulting in weaker encryption than advertised by the algorithm.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-573
CWE-358

 

Consequences

Access Control: Bypass Protection Mechanism

Confidentiality, Integrity: Read Application Data, Modify Application Data

Accountability, Non-Repudiation: Hide Activities

 

Potential Mitigations

CVE References

  • CVE-2001-1585
    • Missing challenge-response step allows authentication bypass using public key.

CWE-326 – Inadequate Encryption Strength

Read Time:57 Second

Description

The software stores or transmits sensitive data using an encryption scheme that is theoretically sound, but is not strong enough for the level of protection required.

A weak encryption scheme can be subjected to brute force attacks that have a reasonable chance of succeeding using current attack methods and resources.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-693

 

Consequences

Access Control, Confidentiality: Bypass Protection Mechanism, Read Application Data

An attacker may be able to decrypt the data using brute force attacks.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Use an encryption scheme that is currently considered to be strong by experts in the field.

CVE References

  • CVE-2002-1697
    • Weak encryption produces same ciphertext from the same plaintext blocks.
  • CVE-2002-1975
    • Encryption error uses fixed salt, simplifying brute force / dictionary attacks (overlaps randomness).

CWE-327 – Use of a Broken or Risky Cryptographic Algorithm

Read Time:2 Minute, 15 Second

Description

The use of a broken or risky cryptographic algorithm is an unnecessary risk that may result in the exposure of sensitive information.

The use of a non-standard algorithm is dangerous because a determined attacker may be able to break the algorithm and compromise whatever data has been protected. Well-known techniques may exist to break the algorithm.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-693
CWE-311

 

Consequences

Confidentiality: Read Application Data

The confidentiality of sensitive data may be compromised by the use of a broken or risky cryptographic algorithm.

Integrity: Modify Application Data

The integrity of sensitive data may be compromised by the use of a broken or risky cryptographic algorithm.

Accountability, Non-Repudiation: Hide Activities

If the cryptographic algorithm is used to ensure the identity of the source of the data (such as digital signatures), then a broken algorithm will compromise this scheme and the source of the data cannot be proven.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Phase: Architecture and Design

Effectiveness: Defense in Depth

Description: 

Ensure that the design allows one cryptographic algorithm can be replaced with another in the next generation or version. Where possible, use wrappers to make the interfaces uniform. This will make it easier to upgrade to stronger algorithms. This is especially important for hardware, which can be more difficult to upgrade quickly than software.

Phase: Architecture and Design

Description: 

Carefully manage and protect cryptographic keys (see CWE-320). If the keys can be guessed or stolen, then the strength of the cryptography itself is irrelevant.

Phase: Architecture and Design

Description: 

Phase: Implementation, Architecture and Design

Description: 

When using industry-approved techniques, use them correctly. Don’t cut corners by skipping resource-intensive steps (CWE-325). These steps are often essential for preventing common attacks.

CVE References

  • CVE-2008-3775
    • Product uses “ROT-25” to obfuscate the password in the registry.
  • CVE-2007-4150
    • product only uses “XOR” to obfuscate sensitive data
  • CVE-2007-5460
    • product only uses “XOR” and a fixed key to obfuscate sensitive data
  • CVE-2005-4860
    • Product substitutes characters with other characters in a fixed way, and also leaves certain input characters unchanged.
  • CVE-2002-2058
    • Attackers can infer private IP addresses by dividing each octet by the MD5 hash of ’20’.
  • CVE-2008-3188
    • Product uses DES when MD5 has been specified in the configuration, resulting in weaker-than-expected password hashes.
  • CVE-2005-2946
    • Default configuration of product uses MD5 instead of stronger algorithms that are available, simplifying forgery of certificates.
  • CVE-2007-6013
    • Product uses the hash of a hash for authentication, allowing attackers to gain privileges if they can obtain the original hash.

CWE-328 – Use of Weak Hash

Read Time:57 Second

Description

The product uses an algorithm that produces a digest (output value) that does not meet security expectations for a hash function that allows an adversary to reasonably determine the original input (preimage attack), find another input that can produce the same hash (2nd preimage attack), or find multiple inputs that evaluate to the same hash (birthday attack).

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-326
CWE-327

 

Consequences

Access Control: Bypass Protection Mechanism

 

Potential Mitigations

Phase: Architecture and Design

Effectiveness: High

Description: 

CVE References

  • CVE-2020-25685
    • DNS product uses a weak hash (CRC32 or SHA-1) of the query name, allowing attacker to forge responses by computing domain names with the same hash.
  • CVE-2012-6707
    • blogging product uses MD5-based algorithm for passwords.
  • CVE-2019-14855
    • forging of certificate signatures using SHA-1 collisions.
  • CVE-2017-15999
    • mobile app for backup sends SHA-1 hash of password in cleartext.
  • CVE-2006-4068
    • Hard-coded hashed values for username and password contained in client-side script, allowing brute-force offline attacks.

CWE-329 – Generation of Predictable IV with CBC Mode

Read Time:1 Minute, 28 Second

Description

The product generates and uses a predictable initialization Vector (IV) with Cipher Block Chaining (CBC) Mode, which causes algorithms to be susceptible to dictionary attacks when they are encrypted under the same key.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: Medium

 

Related Weaknesses

CWE-1204
CWE-573

 

Consequences

Confidentiality: Read Application Data

If the IV is not properly initialized, data that is encrypted can be compromised and leak information.

 

Potential Mitigations

Phase: Implementation

Description: 

NIST recommends two methods of generating unpredictable IVs for CBC mode [REF-1172]. The first is to generate the IV randomly. The second method is to encrypt a nonce with the same key and cipher to be used to encrypt the plaintext. In this case the nonce must be unique but can be predictable, since the block cipher will act as a pseudo random permutation.

CVE References

  • CVE-2020-5408
    • encryption functionality in an authentication framework uses a fixed null IV with CBC mode, allowing attackers to decrypt traffic in applications that use this functionality
  • CVE-2017-17704
    • messages for a door-unlocking product use a fixed IV in CBC mode, which is the same after each restart
  • CVE-2017-11133
    • application uses AES in CBC mode, but the pseudo-random secret and IV are generated using math.random, which is not cryptographically strong.
  • CVE-2007-3528
    • Blowfish-CBC implementation constructs an IV where each byte is calculated modulo 8 instead of modulo 256, resulting in less than 12 bits for the effective IV length, and less than 4096 possible IV values.
  • CVE-2011-3389
    • BEAST attack in SSL 3.0 / TLS 1.0. In CBC mode, chained initialization vectors are non-random, allowing decryption of HTTPS traffic using a chosen plaintext attack.

CWE-33 – Path Traversal: ‘….’ (Multiple Dot)

Read Time:55 Second

Description

The software uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize ‘….’ (multiple dot) sequences that can resolve to a location that is outside of that directory.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-23

 

Consequences

Confidentiality, Integrity: Read Files or Directories, Modify Files or Directories

 

Potential Mitigations

Phase: Implementation

Effectiveness: High

Description: 

Phase: Implementation

Description: 

Inputs should be decoded and canonicalized to the application’s current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.

CVE References

  • CVE-1999-1082
    • read files via “……” in web server (doubled triple dot?)
  • CVE-2004-2121
    • read files via “……” in web server (doubled triple dot?)
  • CVE-2001-0491
    • multiple attacks using “..”, “…”, and “….” in different commands

CWE-330 – Use of Insufficiently Random Values

Read Time:4 Minute, 15 Second

Description

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

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.

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.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-693

 

Consequences

Confidentiality, Other: 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: 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: Bypass Protection Mechanism, Gain Privileges or 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.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Phase: Implementation

Description: 

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

Phase: Testing

Description: 

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.

Phase: Architecture and Design, Requirements

Description: 

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”).

Phase: Testing

Description: 

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.

CVE References

  • 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-2108
    • Chain: insufficient precision (CWE-1339) in
      random-number generator causes some zero bits to be reliably
      generated, reducing the amount of entropy (CWE-331)
  • 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.

CWE-331 – Insufficient Entropy

Read Time:50 Second

Description

The software uses an algorithm or scheme that produces insufficient entropy, leaving patterns or clusters of values that are more likely to occur than others.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-330
CWE-330

 

Consequences

Access Control, Other: Bypass Protection Mechanism, Other

An attacker could guess the random numbers generated and could gain unauthorized access to a system if the random numbers are used for authentication and authorization.

 

Potential Mitigations

Phase: Implementation

Description: 

Determine the necessary entropy to adequately provide for randomness and predictability. This can be achieved by increasing the number of bits of objects such as keys and seeds.

CVE References

  • CVE-2001-0950
    • Insufficiently random data used to generate session tokens using C rand(). Also, for certificate/key generation, uses a source that does not block when entropy is low.
  • CVE-2008-2108
    • Chain: insufficient precision (CWE-1339) in
      random-number generator causes some zero bits to be reliably
      generated, reducing the amount of entropy (CWE-331)

CWE-332 – Insufficient Entropy in PRNG

Read Time:1 Minute, 24 Second

Description

The lack of entropy available for, or used by, a Pseudo-Random Number Generator (PRNG) can be a stability and security threat.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: Medium

 

Related Weaknesses

CWE-331

 

Consequences

Availability: DoS: Crash, Exit, or Restart

If a pseudo-random number generator is using a limited entropy source which runs out (if the generator fails closed), the program may pause or crash.

Access Control, Other: Bypass Protection Mechanism, Other

If a PRNG is using a limited entropy source which runs out, and the generator fails open, the generator could produce predictable random numbers. Potentially a weak source of random numbers could weaken the encryption method used for authentication of users.

 

Potential Mitigations

Phase: Architecture and Design, Requirements

Description: 

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”).

Phase: Implementation

Description: 

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

Phase: Architecture and Design

Description: 

When deciding which PRNG to use, look at its sources of entropy. Depending on what your security needs are, you may need to use a random number generator that always uses strong random data — i.e., a random number generator that attempts to be strong but will fail in a weak way or will always provide some middle ground of protection through techniques like re-seeding. Generally, something that always provides a predictable amount of strength is preferable.

CVE References

  • CVE-2019-1715
    • security product has insufficient entropy in the DRBG, allowing collisions and private key discovery

CWE-333 – Improper Handling of Insufficient Entropy in TRNG

Read Time:34 Second

Description

True random number generators (TRNG) generally have a limited source of entropy and therefore can fail or block.

The rate at which true random numbers can be generated is limited. It is important that one uses them only when they are needed for security.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: Low

 

Related Weaknesses

CWE-331
CWE-703

 

Consequences

Availability: DoS: Crash, Exit, or Restart

A program may crash or block if it runs out of random numbers.

 

Potential Mitigations

Phase: Implementation

Description: 

Rather than failing on a lack of random numbers, it is often preferable to wait for more numbers to be created.

CVE References