Cryptography encompasses the tools and techniques used to protect communication and information exchange to ensure confidentiality, non-repudiation, integrity, and authenticity. Modern cryptographic techniques involve converting plain-text messages into ciphertext that the intended recipient can only decode. With the rapidly changing threat environment, traditional encryption and obfuscation techniques are susceptible to compromises, resulting in the exposure of sensitive data through a group of potential vulnerabilities known as cryptographic failures.
This article delves into why cryptographic failure is considered one of the most common application security threats and its standard form of attack and prevention measures.
What is a Cryptographic Failure Vulnerability?
A cryptographic failure is a critical web application security vulnerability that exposes sensitive application data on a weak or non-existent cryptographic algorithm. Those can be passwords, patient health records, business secrets, credit card information, email addresses, or other personal user information.
Modern web applications process data at rest and in transit, which require stringent security controls for comprehensive threat mitigation. Some deployments employ weak cryptographic techniques that can be cracked within a reasonable time frame. Even with the perfect implementation of cryptographic techniques, users may avoid embracing data protection best practices, subsequently making sensitive information susceptible to sensitive data theft.
Formerly known as sensitive data exposure (2017: A03), the cryptographic failure vulnerability has moved one spot to rank number two on OWASP’s Top Ten list of 2021. Apart from exposing sensitive information, as cryptographic failures can also compromise systems, the implications of this vulnerability are considered one of the most critical security risks for both organizations and business users.
Security flaws that commonly lead to cryptography failures include:
- Transmitting secret data in plain text
- Use of old/less-secure algorithm
- Use of a hard-coded password in config files
- Improper cryptographic key management
- Insufficient randomness for cryptographic functions
- Missing encryption
- Insecure implementation of certificate validation
- Use of deprecated hash functions
- Use of outdated padding methods
- Presence of sensitive data in source control
- Use of insecure initialization vectors
- Use of passwords as crypto keys without a password-based key derivation function
- Exploitable side-channel information or cryptographic error messages
Cryptographic Failures Prevention
The Online Web Application Security Project (OWASP) enumerates various measures to prevent cryptographic implementation defects in modern applications. These include:
Catalog All Data Processed By the Application
It is essential to catalog all forms of data, including stored, transmitted, or processed by the application. This data should be classified and protected according to security necessities, and the appropriate controls should be administered to secure data classified as sensitive or confidential. Developers and security professionals should also perform regular audits to keep track of the data’s location, ownership, and security measures to prevent security loopholes throughout different data lifecycle stages.
Discard Unused Data
Data that is not retained cannot be compromised. It is recommended that developers ensure that applications discard sensitive data as soon as it is no longer usable. PCI Data Security Standard compliant tokenization can help discard this sensitive information by replacing it with a non-sensitive placeholder. Truncation also makes sensitive data unreadable by removing a segment of the data.
Disable Caching for Responses with Sensitive Data
Caching helps improve server performance by storing a local copy of the server’s response. The content of a server response can be intercepted and abused by anyone getting access to the web/browser’s cache storing the copy of the response. As a security best practice, it is recommended to disable caching for all such server responses that contain private and sensitive data.
Use Appropriate Initialization Vectors
An initialization vector (IV) is a unique random number used with a key to facilitate encryption. An IV is used as a salt to provide true randomness in generating distinct encrypted values for the same binary sequences used repeatedly in the original message. Security teams should administer the most effective IVs depending on the mode of operation. For most cryptographic modes, it is also recommended to leverage a cryptographically secure random number generator (CSRNG) to ensure the generated random number is extremely hard to predict and abused by attack vectors.
Use Updated and Established Cryptographic Functions, Algorithms, and Protocols
Instead of developing an encryption scheme from scratch, developers and application security experts should adopt already established, effective cryptographic protocols and mainstream algorithms. As developers often overlook the changing threat landscape, building new cryptography from scratch seldom addresses the latest exploits. Established protocols and algorithms also address insecure design flaws that lead to advanced attacks in cracking operating encryption to prevent known transmission vulnerabilities.
Some modern encryption protocols include Triple Data Encryption Algorithm (TDEA), Advanced Encryption Standard (AES), RSA cryptosystem, etc.
Enforce Key Rotation
Encryption keys are susceptible to cryptographic attacks where the probability of an attack increases the longer the same key is being used. Attackers can leverage a security misconfiguration in version control systems to misuse the encryption key persistently. It is recommended that developers employ automated key generation and rotation to protect data from longstanding compromises. Additionally, the process should involve updating the keys and re-encrypt protected contents from preventing attackers from decrypting self-made backups.
Use Authenticated Encryption Instead of Plain Encryption
Plain encryption offers only confidentiality of the data, whereas authenticated encryption enforces authenticity along with confidentiality. Authenticated encryption uses the GCM (Galois Counter Mode) and CCM (Counter Mode with CBC MAC) block cipher modes to enforce data authenticity and privacy. Simultaneous enforcement of data authenticity and confidentiality offers protection from attack vectors, leaving minimal room for error when handling data in transit.
Cryptographic Failures Examples
A few examples of application vulnerabilities that can lead to cryptographic failures include:
Storing Passwords Using Simple/Unsalted Hashes
Although hashing is considered a powerful technique to protect passwords and sensitive data, it is often incapable of a foolproof solution to comprehensive security control. An increasing pattern of attacks suggests that it’s not unusual for attackers to break into password databases and access pre-calculated hashes created for each password.
Organizations that rely on unsalted hashes lack the cryptographic randomness that offers robust protection for sensitive data. Attackers can leverage a community-developed list of commonly used hashes, dictionaries, or brute-force attack techniques to breach encrypted byte arrays on hashes that comprise short strings and common words.
Lack of Protection for Seeds in Pseudo-Random Number Generators
A Pseudo-random number generator cannot produce true randomness in the sequence of numbers it generates. As a result, they are mainly used with seeds to develop a strong hashing algorithm and initialization vectors for cryptographic operations.
The output of the pseudo-random number generator usually depends on the seed values provided as input. As a best practice, seed values should be uniquely generated from a secure source and must be kept protected as cryptographic assets. Reusing seeds or an insufficiently protected seed allows hackers to uncover the entire output of the pseudo-random number generator to orchestrate a large variety of deeper attacks with severe business and personal implications.
Broken Chain of Trust
During an SSL/TLS communication, the application handshakes with the end-user through a trust certificate for session validity and trust. Every valid certificate follows a trust relationship model called a chain of trust, with the root server being the reputable entity at the end of the chain. A browser’s chaining mechanism often continues traversing through each certificate until a trusted root is found. Traversal through the entire trust chain until the reputable entity is crucial to determine the certificate’s validity. A trust chain may be broken in one of the following ways:
- Failure to check the server certificate across one or more links in the chain of trust
- Intermediate CA certificates that lack necessary extensions and primary constraints
- Certificate mismatches
- Compromised root certificate
- Self-signed, non-root certificates
Insufficient Transport Layer Security
Secure Sockets Layer (SSL)/Transport Layer Security (TLS) protocols are used for end-to-end security hardening of network traffic. Developers often deploy TLS/SSL for encrypting authentication services but overlook implementing it on external internet traffic, other network layers, or the web service. As a result of such network component misconfiguration, session IDs and credential data remain exposed and are potentially susceptible to interception, redirection, and injection by attack vectors. Once attackers intercept sessions, they can orchestrate various attacks, including account takeovers, data breaches, denial of service, man-in-the-middle attacks, etc.
FAQs for Cryptographic Failures
What is the difference between salting and seeding in cryptography?
A seed is a number that acts as the starting point and is used to generate a random series of numbers. Seeding involves the seed parameter assigned for the hashing function calls of a specific application.
On the other hand, a salt is a function added to a string to ensure that hash values are always unique. Adding the same salt function to the original string always results in a different hash, keeping functions, such as passphrases and sensitive data, hidden from exploits.
What are the different types of cryptographic failures?
Cryptographic failures are commonly categorized based on the security features impacted. The three primary categories of cryptographic failures are:
Access control vulnerabilities
Failed integrity checks
Loss of availability
This article has already been published on https://crashtest-security.com/owasp-cryptographic-failures/and has been authorized by Crashtest Security for a republish.
Top comments (0)