Base · Medium

CWE-328: Use of Weak Hash

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 (pr...

CWE-328 · Base Level ·7 CVEs ·1 Mitigations

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

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: 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: 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.

Potential Impact

Access Control

Bypass Protection Mechanism

Demonstrative Examples

In both of these examples, a user is logged in if their given password matches a stored password:
Bad
unsigned char *check_passwd(char *plaintext) {ctext = simple_digest("sha1",plaintext,strlen(plaintext), ... );
                        //Login if hash matches stored hash
                        if (equal(ctext, secret_password())) {login_user();}}
Bad
String plainText = new String(plainTextIn);MessageDigest encer = MessageDigest.getInstance("SHA");encer.update(plainTextIn);byte[] digest = password.digest();
                     //Login if hash matches stored hash
                     if (equal(digest,secret_password())) {login_user();}
This code relies exclusively on a password mechanism (CWE-309) using only one factor of authentication (CWE-308). 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 (CWE-328). It also does not use a salt (CWE-759).
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.
Bad
...
               logic [31:0] data_d, data_q
               logic [512-1:0] pass_data;
               ...
                  
                  Write: begin
                     
                     ...
                        
                        if (pass_mode) begin
                           
                           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].
Good
...
               logic [512-1:0] data_d, data_q
               logic [512-1:0] pass_data;
               ...
                  
                  Write: begin
                     
                     ...
                        
                        if (pass_mode) begin
                           
                           pass_data = data_d;
                           state_d = PassChk;
                           pass_mode = 1'b0;
                           
                        ...
                        
                     
                  end
                  
               ...

Mitigations & Prevention

Architecture and Design High

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, sinc

Detection Methods

  • Automated Static Analysis High — 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 sea

Real-World CVE Examples

CVE IDDescription
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.

Taxonomy Mappings

  • PLOVER: — Reversible One-Way Hash

Frequently Asked Questions

What is CWE-328?

CWE-328 (Use of Weak Hash) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Base-level weakness. 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 (pr...

How can CWE-328 be exploited?

Attackers can exploit CWE-328 (Use of Weak Hash) to bypass protection mechanism. This weakness is typically introduced during the Architecture and Design phase of software development.

How do I prevent CWE-328?

Key mitigations include: 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 re

What is the severity of CWE-328?

CWE-328 is classified as a Base-level weakness (Medium abstraction). It has been observed in 7 real-world CVEs.