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.)
CWE-328 Base Borrador
Use of Weak Hash
This vulnerability occurs when software uses a hashing algorithm that is cryptographically weak, allowing attackers to feasibly reverse the hash to find the original input, find a different input…
Definición
What is CWE-328?
This vulnerability occurs when software uses a hashing algorithm that is cryptographically weak, allowing attackers to feasibly reverse the hash to find the original input, find a different input that creates the same hash, or discover collisions where two inputs produce identical hash values.
A secure cryptographic hash function must be a one-way, deterministic process that reliably produces a unique fixed-length output (digest) from any input. For security, it must prevent three key attacks: recovering the original input from the hash (preimage attack), finding a different input that matches a given hash (second preimage attack), and generating two arbitrary inputs that hash to the same value (birthday attack). A 'weak' hash fails to adequately resist these attacks, often because the math behind it allows methods significantly faster than simple brute-force guessing.
Weakness can stem from the algorithm itself (like MD5 or SHA-1, which are now considered broken for many uses) or from improper application. For example, using a cryptographically sound hash without a unique salt for password storage can enable pre-computed rainbow table attacks, effectively breaking the security the hash was meant to provide. The definition of a 'feasible' attack depends on context, but generally includes any method more efficient than brute force.
Impacto en el mundo real
Real-world CVEs caused by CWE-328
-
Programmable Logic Controller (PLC) uses a protocol with a cryptographically insecure hashing algorithm for passwords.
-
SHA-1 algorithm is not collision-resistant.
-
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.
-
blogging product uses MD5-based algorithm for passwords.
-
forging of certificate signatures using SHA-1 collisions.
-
mobile app for backup sends SHA-1 hash of password in cleartext.
-
Hard-coded hashed values for username and password contained in client-side script, allowing brute-force offline attacks.
Cómo lo explotan los atacantes
Ruta del atacante paso a paso
- 1
In both of these examples, a user is logged in if their given password matches a stored password:
- 2
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).
- 3
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.
- 4
At least one OT product used weak hashes.
- 5
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.
Ejemplo de código vulnerable
Vulnerable C
In both of these examples, a user is logged in if their given password matches a stored password:
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();
}
} Ejemplo de código seguro
Secure Verilog
To mitigate, remove the zero padding and use all 512 bits of the secret message for HMAC authentication [REF-1361].
...
**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
... What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Lista de prevención
How to prevent CWE-328
- 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.
Señales de detección
How to detect CWE-328
CWE-328
Don't catalog this weakness. Prove it's reachable.
Plexicus turns CWE catalogs into evidence: every CWE-pattern is matched against your real code graph, reach is proven on a sandbox clone, and verified findings ship as reviewed PRs.
Preguntas frecuentes ¿Qué es CWE-328?
¿Qué gravedad tiene CWE-328?
¿Qué lenguajes o plataformas se ven afectados por CWE-328?
¿Cómo puedo prevenir CWE-328?
¿Cómo detecta y corrige Plexicus CWE-328?
¿Dónde puedo aprender más sobre CWE-328?
Frequently asked questions
¿Qué es CWE-328?
This vulnerability occurs when software uses a hashing algorithm that is cryptographically weak, allowing attackers to feasibly reverse the hash to find the original input, find a different input that creates the same hash, or discover collisions where two inputs produce identical hash values.
¿Qué gravedad tiene CWE-328?
MITRE no ha publicado una calificación de probabilidad de explotación para esta debilidad. Trátala como de impacto medio hasta que tu modelo de amenazas demuestre lo contrario.
¿Qué lenguajes o plataformas se ven afectados por CWE-328?
MITRE lists the following affected platforms: ICS/OT.
¿Cómo puedo prevenir CWE-328?
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,…
¿Cómo detecta y corrige Plexicus CWE-328?
El motor SAST de Plexicus detecta la firma de flujo de datos para CWE-328 en cada commit. Cuando hay coincidencia, nuestro agente Codex Remedium abre un PR de corrección con el código corregido, las pruebas y un resumen de una línea para el revisor.
¿Dónde puedo aprender más sobre CWE-328?
MITRE publica la definición canónica en https://cwe.mitre.org/data/definitions/328.html. También puedes consultar la documentación de OWASP y NIST para guías relacionadas.
Debilidades relacionadas
Weaknesses related to CWE-328
CWE-327 Padre
Use of a Broken or Risky Cryptographic Algorithm
The software relies on a cryptographic algorithm or protocol that is either fundamentally flawed or considered too weak by modern security…
CWE-1240 Hermano
Use of a Cryptographic Primitive with a Risky Implementation
This weakness occurs when a product uses a custom, unverified, or non-compliant implementation of a cryptographic algorithm instead of a…
CWE-780 Hermano
Use of RSA Algorithm without OAEP
This vulnerability occurs when an application implements RSA encryption but fails to use Optimal Asymmetric Encryption Padding (OAEP),…
CWE-916 Hermano
Use of Password Hash With Insufficient Computational Effort
This vulnerability occurs when a system protects passwords by hashing them, but uses a hashing algorithm that is too fast or…
Recursos
Further reading
- MITRE — CWE-328 oficial https://cwe.mitre.org/data/definitions/328.html
- MD5 considered harmful today http://www.phreedom.org/research/rogue-ca/
- bcrypt https://bcrypt.sourceforge.net/
- Tarsnap - The scrypt key derivation function and encryption utility http://www.tarsnap.com/scrypt.html
- RFC2898 - PKCS #5: Password-Based Cryptography Specification Version 2.0 https://www.rfc-editor.org/rfc/rfc2898
- How To Safely Store A Password https://codahale.com/how-to-safely-store-a-password/
¿Listo para validar lo que importa?
Listo para validar lo que importa.
Plexicus es Proof-Driven AppSec: hallazgos validados, comprensión contextual y remediación revisada — anclada en evidencia, acotada contigo.