Quick Tutorial: Cryptographic Failures vulnerabilities

Cryptographic Failures vulnerabilities are at number two in OWASP Top 10 2021. This vulnerability may expose sensitive data available on the application or on the server side. This blog explains vulnerabilities related to cryptographic failures come under this category.

A list of vulnerabilities comes under Cryptographic Failures

Sr. No.	CWE No	Vulnerability	Description	Mitigation Technique
1.	CWE-261	Weak Encoding for Password	Use of weak encoding techniques (e.g. base64) to obscure the password	Always use strong cryptography techniques for the storage of passwords
2.	CWE-296	Improper Following of a Certificate's Chain of Trust	Software not following the certificate's chain of trust with the trusted root certificate.	Implement checking of certificates in system design.
3.	CWE-327	Use of a Broken or Risky Cryptographic Algorithm	Use of non-standard algorithms that may be broken by attackers.	Always use strong standard algorithms in the code of web applications.
4.	CWE-335	Incorrect Usage of Seeds in Pseudo-Random Number Generator(PRNG)	Use of the same seed multiple times while implementing software. In addition, current time use as a seed is not recommended.	Use uniquely generated seeds and protect seeds just like other secrets.
5.	CWE-757	Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade')	Downgrade the algorithm if not matches with client and server.	Review the design of software for vulnerabilities.
6.	CWE-759	Use of a One-Way Hash without a Salt	The software uses a one-way hash without a salt	Always consider the use of salt while implementing a one-way hash.
7.	CWE-325	Missing Required Cryptographic Step	Missing cryptography leads to implementing weaker encryption.	Cryptographic requirements should be clearly defined.
8.	CWE-326	Inadequate Encryption Strength	The software uses an obsolete algorithm with a weak encryption mechanism.	Use standard algorithms that are tested by experts.
9.	CWE-310	Cryptographic Issues	This weakness covers all vulnerabilities that come under Cryptographic failures.	--
10.	CWE-338	Use of Cryptographically Weak Pseudo-Random Number Generator(PRNG)	Use of weak PRNG algorithm in the product. example: use of rand() and Random.nextInt(), not considered cryptographically strong	If possible, use a hardware-based random number generator.
11.	CWE-720	OWASP Top Ten 2007 Category A9 - Insecure Communications	This weakness covers all vulnerabilities that come under Insecure Communication	--
12.	CWE-336	Same Seed in Pseudo-Random Number Generator (PRNG)	Use of the same seed in PRNG	Use a unique seed each time for PRNG
13.	CWE-319	Cleartext Transmission of Sensitive Information	Not using cryptographic mechanisms to secure in-transit data.	Identify the need for encryption for the application, and if required, encrypt the data before sending.
14.	CWE-760	Use of a One-Way Hash with a Predictable Salt	Use of predictable salt value before hashing of data	Use an adaptive hash function to increase complexity for attackers.
15.	CWE-331	Insufficient Entropy	Algorithms using weak entropy functions such as rand() or using the same seed again and again to generate random numbers.	Use appropriate randomness by selecting the length of keys and seeds.
16.	CWE-916	Use of Password Hash With Insufficient Computational Effort	Not using salt with a hash, Usage of outdated hash functions	Use functions such as bcrypt, scrypt, and PBKDF2
17.	CWE-322	Key Exchange without Entity Authentication	The software performs an exchange of keys without verifying the identity of an entity.	Must review the design of software before going into the development phase.
18.	CWE-340	Generation of Predictable Numbers or Identifiers	The software use modules that generate predictable numbers/identifiers	Guide developers to not use modules that generate predictable numbers/identifiers
19.	CWE-780	Use of RSA Algorithm without OAEP	Not using Optimal Asymmetric Encryption Padding (OAEP) for implementing the RSA algorithm.	Use OAEP for the RSA algorithm.
20.	CWE-347	Improper Verification of Cryptographic Signature	The application is not able to verify or incorrectly verifies cryptographic signatures.	Code review the software before deployment in production.
21.	CWE-818	Insufficient Transport Layer Protection	Use of expired SSL on the resource.	Always use an updated version of SSL to protect in-transit data.
22.	CWE-324	Use of a Key Past its Expiration Date	Continue to use secret keys after expiration also.	Create an alert for developers on the use of secret keys after expiration
23.	CWE-523	Unprotected Transport of Credentials	Not use measures for the protection of username and password in transit from front end to server.	Always use an updated version of SSL to protect in-transit data.
24.	CWE-323	Reusing a Nonce, Key Pair in Encryption	Use of the same Nonce again for encryption of secrets.	Never use the same nonce values for cryptographic operations.
25.	CWE-321	Use of Hard-coded Cryptographic Key	Sometimes developers left secret cryptographic keys in the code that may be recovered by attackers by using different tools.	Audit the code before deploying it in a production environment.
26.	CWE-337	Predictable Seed in Pseudo-Random Number Generator (PRNG)	PRNG uses easy-to-predict seeds such as time or process id.	Use modules that conform latest FIPS standards
27.	CWE-329	Generation of Predictable IV with CBC Mode	If the application developer uses a predictable initialization vector (IV) with CBC mode, the same input is encrypted using the same plaintext.	Implement NIST-recommended methods to generate unpredictable IV for CBC mode. The first method is to generate IV randomly. The second method is to use an encrypted nonce (with the same key) for plain text encryption.
28.	CWE 330	Use of Insufficiently Random Values	Usage of weak random generator library functions such as rand() or use of the same seed to generate a random number.	Use of standard algorithms, random seed to generate a random number, and use modules that confirm FIPS 140-2.
29.	CWE 328	Use of Weak Hash	Weak hash denotes three conditions: if two or more different inputs produce the same hash value, able to reconvert the hash into the original value, and another input provides hash.	It is recommended to use secure hash functions such as bcrypt, script, and PBKDF2.

Conclusion

This blog covered vulnerabilities that come under the category of cryptographic failures. Most of the vulnerabilities in this category are easily identified by source code review. Although, you can also use both dynamic and static analysis tools to analyze cryptographic vulnerabilities in the software products.