Exploring CWE-321: Use of Hard-coded Cryptographic Key￼
A02:2021 – Cryptographic Failures is the second most common vulnerability on OWASP’s Top Ten List of web application vulnerabilities. Strong encryption is a fundamental component of data security and privacy, but it is easy to get wrong. Errors in data encryption can undermine or destroy its protections, leading to the exposure of sensitive information.
One of the cryptographic failures in this list is the use of a hardcoded cryptographic key, which is labeled as CWE-321: Use of Hard-coded Cryptographic Key. Hardcoded keys are vulnerable to exposure and can undermine the security of encryption or authentication processes.
Hardcoded Cryptographic Keys and Other Authentication Data
A cryptographic key is intended to remain secret. These keys can be used for data encryption, identity verification, and integrity protection. Cryptographic algorithms are designed so that the key is the sole secret and anyone with knowledge of the key can gain access to protected data or generate a fake digital signature.
Symmetric encryption requires knowledge of a secret key for data encryption or decryption, and asymmetric algorithms use secret keys for key agreement protocols, data decryption, and the generation of digital signatures. By embedding these keys within the code of an application or in configuration files associated with it, a developer can ensure that they are accessible when needed. However, this also dramatically increases their probability of exposure and misuse.
Encryption keys are not the only form of secret data that may be hardcoded within an application. Software may include hardcoded passwords or API keys designed to allow it to authenticate to various services. Manufacturers may also build hardcoded credentials into their systems to provide remote access and support for updates. While these may not be used for data encryption, they are used to verify identity, making them equally as damaging if exposed.
How Hardcoded Keys Get Exposed
By hardcoding a key into an application, a developer places sensitive information in an insecure storage location. These keys can be exposed in various ways, such as:
- Source Code Repositories: Applications commonly interact with APIs and need API keys or other authentication material to prove their identity. If these API keys are hardcoded within an application’s code or configuration files, this information may be leaked if the project is uploaded to a public source code repository such as Github or Gitlab.
- Software Reverse Engineering: While software is commonly released as compiled executables, tools and techniques exist for reverse engineering the code and data contained within these executables. If cryptographic keys or authentication information is hardcoded within an executable, then a reverse engineer can extract it.
- Data Leaks: Hardcoded credentials are commonly used under the assumption that they will remain secret, but this is rarely the case. Hardcoded keys may be exposed in documentation or accidentally by a developer.
- Key Guessing Attacks: Often, when hardcoded keys or authentication information is used within an application, the secret key is also weak. Many default passwords are common passwords (123456, password, etc.) or are based on the company’s name, making them easy to guess.
Another downside of hardcoded keys and other authentication material is that they cannot be easily changed after they are exposed. Mirai and other botnets have taken advantage of this, searching for devices that allow remote access via default passwords and adding them to Distributed Denial of Service (DDoS) botnets.
Case Study: Dell PowerPath Management Appliance
This vulnerability is potentially exploitable by a local user with high privileges on the affected system. Using these privileges and the hardcoded key, an attacker could decrypt sensitive information that could allow them to escalate their privileges on the system.
Properly Managing Encryption Keys
Hardcoding cryptographic keys, passwords, and other sensitive information is always a bad idea. Some key best practices that help to protect against this vulnerability include:
- Use trusted cryptographic libraries and key management solutions
- Leverage well supported secrets management solutions
- Generate unique keys for all users
- Implement access controls based on the principle of least privilege
- Configure git to ignore configuration files and other sensitive information
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.
Setup is quick and easy
Ready to get started?
Create a FREE account instantly and start encrypting data or get in touch to discuss a custom package for your organization.