Use of Weak Hash

Draft Base
Structure: Simple
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).

Extended Description

A hash function is defined as an algorithm that maps arbitrarily sized data into a fixed-sized digest (output) such that the following properties hold: 1. The algorithm is not invertible (also called "one-way" or "not reversible") 1. The algorithm is deterministic; the same input produces the same digest every time Building on this definition, a cryptographic hash function must also ensure that a malicious actor cannot leverage the hash function to have a reasonable chance of success at determining any of the following: 1. the original input (preimage attack), given only the digest 1. another input that can produce the same digest (2nd preimage attack), given the original input 1. a set of two or more inputs that evaluate to the same digest (birthday attack), given the actor can arbitrarily choose the inputs to be hashed and can do so a reasonable amount of times What is regarded as "reasonable" varies by context and threat model, but in general, "reasonable" could cover any attack that is more efficient than brute force (i.e., on average, attempting half of all possible combinations). Note that some attacks might be more efficient than brute force but are still not regarded as achievable in the real world. Any algorithm that does not meet the above conditions will generally be considered weak for general use in hashing. In addition to algorithmic weaknesses, a hash function can be made weak by using the hash in a security context that breaks its security guarantees. For example, using a hash function without a salt for storing passwords (that are sufficiently short) could enable an adversary to create a "rainbow table" [REF-637] to recover the password under certain conditions; this attack works against such hash functions as MD5, SHA-1, and SHA-2.

Common Consequences 1
Scope: Access Control

Impact: Bypass Protection Mechanism

Detection Methods 1
Automated Static AnalysisHigh
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Potential Mitigations 1
Phase: Architecture and Design
Use an adaptive hash function that can be configured to change the amount of computational effort needed to compute the hash, such as the number of iterations ("stretching") or the amount of memory required. Some hash functions perform salting automatically. These functions can significantly increase the overhead for a brute force attack compared to intentionally-fast functions such as MD5. For example, rainbow table attacks can become infeasible due to the high computing overhead. Finally, since computing power gets faster and cheaper over time, the technique can be reconfigured to increase the workload without forcing an entire replacement of the algorithm in use. Some hash functions that have one or more of these desired properties include bcrypt [REF-291], scrypt [REF-292], and PBKDF2 [REF-293]. While there is active debate about which of these is the most effective, they are all stronger than using salts with hash functions with very little computing overhead. Note that using these functions can have an impact on performance, so they require special consideration to avoid denial-of-service attacks. However, their configurability provides finer control over how much CPU and memory is used, so it could be adjusted to suit the environment's needs.

Effectiveness: High

Demonstrative Examples 3

ID : DX-101

In both of these examples, a user is logged in if their given password matches a stored password:

Code Example:

Bad
C
c

//Login if hash matches stored hash* if (equal(ctext, secret_password())) { ``` login_user(); } }

Code Example:

Bad
Java
java

//Login if hash matches stored hash* if (equal(digest,secret_password())) { ``` login_user(); }

This code relies exclusively on a password mechanism (Use of Password System for Primary Authentication) using only one factor of authentication (Use of Single-factor Authentication). If an attacker can steal or guess a user's password, they are given full access to their account. Note this code also uses SHA-1, which is a weak hash (Use of Weak Hash). It also does not use a salt (Use of a One-Way Hash without a Salt).

ID : DX-153

In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications.
At least one OT product used weak hashes.
The example code below is taken from the JTAG access control mechanism of the Hack@DAC'21 buggy OpenPiton SoC [REF-1360]. Access to JTAG allows users to access sensitive information in the system. Hence, access to JTAG is controlled using cryptographic authentication of the users. In this example (see the vulnerable code source), the password checker uses HMAC-SHA256 for authentication. It takes a 512-bit secret message from the user, hashes it using HMAC, and compares its output with the expected output to determine the authenticity of the user.

Code Example:

Bad
Verilog

...

logic [31:0] data_d, data_q

logic [512-1:0] pass_data; ...

verilog

pass_data = { {60{8'h00}}, data_d};** state_d = PassChk; pass_mode = 1'b0; ... end ...

The vulnerable code shows an incorrect implementation of the HMAC authentication where it only uses the least significant 32 bits of the secret message for the authentication (the remaining 480 bits are hard coded as zeros). As a result, the system is susceptible to brute-force attacks where the attacker only needs to determine 32 bits of the secret message instead of 512 bits, weakening the cryptographic protocol.
To mitigate, remove the zero padding and use all 512 bits of the secret message for HMAC authentication [REF-1361].

Code Example:

Good
Verilog

...

logic [512-1:0] data_d, data_q logic [512-1:0] pass_data; ...

verilog

pass_data = data_d;** state_d = PassChk; pass_mode = 1'b0; ... end ...

Observed Examples 7
CVE-2022-30320Programmable Logic Controller (PLC) uses a protocol with a cryptographically insecure hashing algorithm for passwords.
CVE-2005-4900SHA-1 algorithm is not collision-resistant.
CVE-2020-25685DNS 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-6707blogging product uses MD5-based algorithm for passwords.
CVE-2019-14855forging of certificate signatures using SHA-1 collisions.
CVE-2017-15999mobile app for backup sends SHA-1 hash of password in cleartext.
CVE-2006-4068Hard-coded hashed values for username and password contained in client-side script, allowing brute-force offline attacks.
References 16
MD5 considered harmful today
Alexander Sotirov et al.
ID: REF-289
The Art of Software Security Assessment
Mark Dowd, John McDonald, and Justin Schuh
Addison Wesley
2006
ID: REF-62
bcrypt
Johnny Shelley
ID: REF-291
Tarsnap - The scrypt key derivation function and encryption utility
Colin Percival
ID: REF-292
RFC2898 - PKCS #5: Password-Based Cryptography Specification Version 2.0
B. Kaliski
2000
ID: REF-293
How To Safely Store A Password
Coda Hale
31-01-2010
ID: REF-294
How Companies Can Beef Up Password Security (interview with Thomas H. Ptacek)
Brian Krebs
11-06-2012
ID: REF-295
Password security: past, present, future
Solar Designer
2012
ID: REF-296
Our password hashing has no clothes
Troy Hunt
26-06-2012
ID: REF-297
Rainbow table
Wikipedia
03-03-2009
ID: REF-637
Cryptanalysis of SHA-1
Bruce Schneier
18-02-2005
ID: REF-1243
At death's door for years, widely used SHA1 function is now dead
Dan Goodin
Ars Technica
23-02-2017
ID: REF-1244
OT:ICEFALL: The legacy of "insecure by design" and its implications for certifications and risk management
Forescout Vedere Labs
20-06-2022
ID: REF-1283
Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Technologies:
ICS/OT : Undetermined
Modes of Introduction
Architecture and Design
Taxonomy Mapping
  • PLOVER
Notes
MaintenanceSince CWE 4.4, various cryptography-related entries including Use of Weak Hash have been slated for extensive research, analysis, and community consultation to define consistent terminology, improve relationships, and reduce overlap or duplication. As of CWE 4.6, this work is still ongoing.