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.||CWE||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 certificate's chain of trust with trusted root certificate.||Implement checking of certificate 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 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 design of software for vulnerabilities.|
|6.||CWE-759||Use of a One-Way Hash without a Salt||Software uses of a one-way hash without a salt||Always consider use of salt while implementing one way hash.|
|7.||CWE-325||Missing Required Cryptographic Step||Missing cryptographic lead to implement weaker encryption.||Cryptographic requirements should be clearly defined.|
|8.||CWE-326||Inadequate Encryption Strength||Software uses obsulute algorithm with 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 same seed in PRNG||Use 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 RSA algorithm.||Use OAEP for the RSA algorithm.|
|20.||CWE-347||Improper Verification of Cryptographic Signature||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 the plain text encryption.
|28.||CWE 330||Use of Insufficiently Random Values||Usage 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 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.|
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.