Exploring CWE-327 Use of a Broken or Risky Cryptographic Algorithm

Introduction

The OWASP Top Ten list provides in-depth information about the most common security issues facing web applications. Number two on the list is A02:2021 – Cryptographic Failures, which covers a wide range of common mistakes.

When selecting a cryptographic algorithm for use in an application, name recognition and security don’t always match up. CWE-327 describes the security risks associated with using a broken or otherwise risky cryptographic algorithm.

Cryptographic Algorithms Have a Limited “Shelf Life”

Cryptographic algorithms are designed to protect the confidentiality, integrity, and authenticity of data. Ideally, cryptographic algorithms would be secure forever. However in practice, most algorithms have a limited lifetime.

In some cases, this is caused by the discovery of errors within the protocols themselves. For example, the contests to select the Advanced Encryption Standard (AES) and post-quantum encryption standard candidates included algorithms that were found to be insecure during the contests themselves. In others, algorithms may be used for years before vulnerabilities were found, such as the issues with RC4.

Cryptographic algorithms can also fall prey to technological advancements. All cryptography is vulnerable to a brute force search for the secret key. As computers grew faster, some algorithms, like DES, had keys that were now vulnerable to this attack, rendering them insecure. The threat of quantum computing to classical asymmetric encryption is another example of how technological advancement imperils cryptographic security.

Once a potentially viable attack exists for a cryptographic algorithm, it should no longer be trusted to fulfill its purpose. The use of these broken algorithms only creates a false sense of security.

How Cryptographic Code Can Be Broken

Cryptographic algorithms provide strong security guarantees when correctly designed, implemented, and used. However, the security of these algorithms can be compromised in various ways, such as:

• Broken Algorithms: Over time, some cryptographic algorithms have been broken due to the discovery of new attacks or advances in computing. For example, DES’s 56-bit key length is now vulnerable to a brute force search. The use of DES or other broken algorithms provides negligible security benefits to the encrypted data.
• Custom Algorithms: Many data breaches, such as Zerologon, were made possible by the use of custom encryption algorithms or modifications to existing protocols. Designing a secure encryption algorithm is complex and prone to error — well-known cryptographers have submitted broken algorithms in the past — so custom encryption algorithms are very likely to be broken.
• Insecure Implementations: Cryptographic algorithms can be fragile, and even small differences in implementation can weaken the strength of encryption or expose them to side channel attacks. Using a custom or insecure implementation of a secure encryption algorithm may leave the encrypted data vulnerable.
• Incorrect Parameters: Cryptographic algorithms commonly include configuration parameters or additional data, such as the number of iterations used when hashing a password or the use of initialization vectors (IVs) when encrypting multiple blocks of data with AES. Choosing the wrong parameters or failing to follow the rules for a particular input (uniqueness, randomness, etc.) can break the security of the cryptographic algorithm.

Case Study: Dell EMC PowerScale OneFS

In 2022, a critical vulnerability was disclosed in Dell EMC PowerScale OneFS. This vulnerability, given a CVSS score of 10.0, is tracked as CVE-2022-26854.

The key exchange algorithms used by the software included diffie-hellman-group14-sha1 as one of the default options. SHA-1 is a hash function that was formally deprecated by NIST in 2011 and was fully broken in 2020 after a chosen-prefix collision was discovered. The use of this insecure hash algorithm could have allowed the attacker to gain full control over the target system if exploited by an attacker.

Avoiding Broken and Risky Cryptography

Developers run into problems with this vulnerability when they attempt to use nonstandard cryptographic algorithms or implementations. Some best practices that can help to avoid CWE 327 include:

• Follow cryptographic standards such as the ones published by NIST
• Never create custom cryptographic algorithms or modify existing ones
• Use a trusted library implementation of cryptographic code
• Read and follow documentation for configuring cryptographic parameters
• Review and update cryptographic code periodically to correct use of broken algorithms

Up Next

To help build understanding of how cryptography can go wrong and how to fix it, we’ll continue to dive deep into prevention measures and most of the 29 CWEs related to OWASP’s A02:2021 – Cryptographic Failures vulnerability in a series of blogs. Each blog will describe the weakness, why it happens, a real-world case study, and recommended mitigations.

We’re very committed to improving the state of cryptography and data security by sharing knowledge and helping to correct common misconceptions about how cryptography works and how to use it properly. To keep up with this series and our other research and cryptography content, make sure to subscribe to our blog in the page footer below.