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.

List of vulnerabilities come under Cryptographic Failures

Sr. No.CWEVulnerabilityDescriptionMitigation Technique
1. CWE-261Weak Encoding for PasswordUse of weak encoding techniques (e.g. base64) to obscure the passwordAlways use strong cryptography techniques for the storage of passwords
2. CWE-296Improper Following of a Certificate's Chain of TrustSoftware not following certificate's chain of trust with trusted root certificate.Implement checking of certificate in system design.
3.CWE-327Use of a Broken or Risky Cryptographic AlgorithmUse of non-standard algorithms that may be broken by attackers.Always use strong standard algorithms in the code of web applications.
4.CWE-335Incorrect Usage of Seeds in Pseudo-Random Number Generator(PRNG)Use of 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-757Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade')Downgrade the algorithm if not matches with client and server.Review design of software for vulnerabilities.
6.CWE-759Use of a One-Way Hash without a SaltSoftware uses of a one-way hash without a salt Always consider use of salt while implementing one way hash.
7.CWE-325Missing Required Cryptographic StepMissing cryptographic lead to implement weaker encryption.Cryptographic requirements should be clearly defined.
8.CWE-326Inadequate Encryption StrengthSoftware uses obsulute algorithm with weak encryption mechanism.Use standard algorithms that are tested by experts.
9.CWE-310Cryptographic IssuesThis weakness covers all vulnerabilities that come under Cryptographic failures.--
10.CWE-338Use 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-720OWASP Top Ten 2007 Category A9 - Insecure CommunicationsThis weakness covers all vulnerabilities that come under Insecure Communication--
12.CWE-336Same Seed in Pseudo-Random Number Generator (PRNG)Use of same seed in PRNGUse unique seed each time for PRNG
13.CWE-319Cleartext Transmission of Sensitive InformationNot 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-760Use of a One-Way Hash with a Predictable SaltUse of predictable salt value before hashing of dataUse an adaptive hash function to increase complexity for attackers.
15.CWE-331Insufficient EntropyAlgorithms 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-916Use of Password Hash With Insufficient Computational EffortNot using salt with a hash, Usage of outdated hash functions Use functions such as bcrypt, scrypt, and PBKDF2
17.CWE-322Key Exchange without Entity AuthenticationThe 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-340Generation of Predictable Numbers or IdentifiersThe software use modules that generate predictable numbers/identifiersGuide developers to not use modules that generate predictable numbers/identifiers
19.CWE-780Use of RSA Algorithm without OAEPNot using Optimal Asymmetric Encryption Padding (OAEP) for implementing RSA algorithm.Use OAEP for the RSA algorithm.
20.CWE-347Improper Verification of Cryptographic SignatureApplication is not able to verify or incorrectly verifies cryptographic signatures.Code review the software before deployment in production.
21.CWE-818Insufficient Transport Layer ProtectionUse of expired SSL on the resource.Always use an updated version of SSL to protect in-transit data.
22.CWE-324Use of a Key Past its Expiration DateContinue to use secret keys after expiration also.Create an alert for developers on the use of secret keys after expiration
23.CWE-523Unprotected Transport of CredentialsNot 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-323Reusing a Nonce, Key Pair in EncryptionUse of the same Nonce again for encryption of secrets.Never use the same nonce values for cryptographic operations.
25.CWE-321Use of Hard-coded Cryptographic KeySometimes 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-337Predictable 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-329Generation of Predictable IV with CBC ModeIf 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 the plain text encryption.
28.CWE 330Use of Insufficiently Random ValuesUsage of weak random generator library functions such as rand() or use of 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 328Use of Weak HashWeak 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

We have 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 vulnerabilites in the software products.

Subscribe us to receive more such articles updates in your email.

If you have any questions, feel free to ask in the comments section below. Nothing gives me greater joy than helping my readers!

Disclaimer: This tutorial is for educational purpose only. Individual is solely responsible for any illegal act.

You may also like...

Leave a Reply

Your email address will not be published.