A02:2021 – Cryptographic Failures Owasp: Know This Cyber Trouble Better

What is Cryptographic Failure?

As per the OWASP cryptographic failure definition (2021), it’s a symptom instead of a cause. This failure is responsible for the exposure/leaking of data of critical and sensitive nature to ill-intended resources/people. Missing out on safeguarding such data leads to theft, public listing, breaches, and other problems.

In the 2017 list, the vulnerability named Sensitive Data Exposure was covering this. Only in the 2021 list, it became Cryptographic Failure OWASP when the scope was narrowed down to cryptography for the business-critical data. Here, the most common CWEs covered are: 

• CWE-259: It is about the Victim making use of Hard-coded Passwords;
• CWE-331: The randomizer function, when not working perfectly, results in insufficient Entropy;
• CWE-327: It is related to Utilizing a Broken or Risky algorithm for cryptography.

Note: CWE stands for Common Weakness Enumerations.

When it comes to managing sensitive data, one must understand that both the resting and in-resting data should be taken into account. 

• Resting data

Resting data is the data not used by any application presently but is important. Stored passwords and user information for accessing applications are examples of such data. unpublished offline data of an organization or old archives can also be considered the resting data.

It is better that businesses use well-encrypted or hased storage spaces, you are susceptible to cryptographic failure vulnerability.

• Data en route

Data en-route or in-transit, as clear from the name itself, is the data that an application is currently processing or using. For instance, the banking details being sent out through an encrypted medium during a payment process can become a victim of a man-in-the-middle attack.

To help you develop a better grasp on the topic, we present you with the most common cryptographic failure examples.

‍

Examples of Attacks

Example #1

Suppose there is an app-based solution encrypting credit card details with automated database encryption and fails to decrypt it automatically upon retrieving. This creates a scope for SQL injection attacks. With a successful SQL injection attack, an attacker can find out the saved credit card details and use them as per the will.

Example #2

In the case of websites, having weak encryption and not the implementation of TLS encryption on all the website pages is a major threat. Such websites become prime targets of attackers as they can easily monitor the traffic, access all the requests made, steal cookies, and force the connection to drop to HTTP from HTTPS. 

The hassles don’t end here. Threat actors can use the hijacked cookies and use them against the user to access sensitive data. Also, such poorly encrypted websites give attackers a chance to modify the transported data.

Example #3

Password databases generally use simple or unsalted hashes for password data storage. Any file upload error occurring in password databases is an opportunity for attackers to steal the password and use them for their benefit. If that happens, passwords stored using unsalted hashes will be exposed to pre-calculated hashes while the simple hash stored password will be cracked by GPUs.

‍

Here are the prevention measures that the OWASP recommends

OWASP not only tells you about the vulnerabilities but also suggests viable remedial solutions to fix these vulnerabilities. This way, if an issue makes it to the 2021 list, the chances of it appearing in OWASP Top 10 2022 or beyond, decrease.

It helps  For cryptographic failures as well, detailed preventive methods are suggested.

• Keep track of the process, store, and transfer data, and classify it. Make sure that you’re able to figure out the sensitive data as per the applied privacy laws and regulations. Enforce strong security practices on sensitive data so that risks are as less as possible.
• There is no point in storing unwanted or redundant data as it’s a sheer wastage of security resources and consumes more effort. It’s wise to discard such data at the earliest. Using PCI DSS compliant tokenization process and truncation is also a very viable approach to keep unused data at bay. 
• Every at-rest or moving data should be well-encrypted and is backed with security measures like robust standard algorithm, login keys, protocols, and end-to-end key management are implemented.
• For in-transit data, security needs to be more sound and you can make it happen with the implementation of TLS protocol with FS ciphers and secure parameters. Also, cipher prioritization should be done by the server. Strong encryption with HTTP Strict Transport Security or HSTS is also a great way to safeguard in-transit data. 
• Responses, featuring sensitive data, should have disabled caching. Also, sensitive data should only be protected with military-grade encryption. Nothing less than 256 Bit Encryption is permitted. One must not use legacy protocols like FTP or SMTP for sensitive information.
• Based upon the data classification parameters, required security controls should be implemented.
• It’s pointless to discuss the power of strong passwords for databases as we all know that a strong and complex password is hard to decode. Make sure all your strong passwords are stored using robustly salted and adaptive hashing. Also, a work or delay factor should be attached. Some of the suggested work factors are PBKDF2, bcrypt, script, and Argon2.
• When it comes to choosing the initialization vector or IV, the job should be done as per the mode of operations. When many modes are in place CSPRNG or Cryptographically Secure Pseudo-Random Number Generator is preferred. For nonce-requiring modes, the initialization vector won’t be needing CSPRNG. In no circumstances, IV can’t be used more than two times for a stagnant key. 
• Encryption applied should be authenticated first. 
• Encryption keys should be created cryptographically randomly and stored in the form of byte arrays in the memory. Passwords that are used must be converted to keys using the suitable password-based key derivation function.
• Using cryptographic randomness is a great way to reduce cryptographic failure risks. But, make sure that it’s not seeded with abject entropy or in a foreseeable manner. This sort of implementation will hold hardly any value. 
• MD5, SHA1, and PKCS number 1 v1.5 are some examples of padding schemes and deprecated cryptographic functions. One must avoid these elements for sure. 
• Configurations and settings should be verified for their effectiveness. 

‍

How Wallarm can help with cryptographic failures

Even though A02:2021 – Cryptographic Failures is a tough nut to crack, one can manage to stay safe from this vulnerability with a little bit of attention and the right resources. 

Wallarm, an industry-renowned API security platform, offers various viable preventive tools.

For instance, there is a Cloud WAF that is easy-to-use, fully automated, and packed with inventive prevention techniques. As it supports all the leading APIs, the protection delivered will be extensive and far-reaching.

In addition, there is a feature-rich API security solution offered that involves API monitoring. API threat detection, API prevention, and API testing facilities. Using this service, one can ensure that sensitive data, handled by APIs, is protected and risk-free from beginning to end.

Lastly, Wallarm offers GotestWAF, which is a very powerful security tool to test at-work WAF. It will help you find out the actual performance of your WAF and provide clear insights on threats detected by AppSec solutions.

All three solutions, when in place, ensure that sensitive cryptographic data is safe and sound.