Skip to content

Security Issues

Security issues are critical vulnerabilities that can be exploited by attackers to gain unauthorized access, manipulate data, or disrupt services.

Each issue poses a unique threat and requires specific mitigation strategies to ensure system integrity and security. Understanding and addressing these security issues is essential for maintaining a secure software environment.

This section provides detailed descriptions and mitigation techniques for various common vulnerabilities as well as references to further readings.

Tip

Once the platform identifies a security issue, it can be flagged as important or marked as a false positive, among other statuses. See Vulnerability management to learn more.

CA certificate verification failed

The CA certificate trust chain can not be verified using the built-in trusted CA list. This means that the chain of trust, which typically includes the root certificate, intermediate certificates, and the end-entity certificate, is broken or incomplete. There can be many reasons for this, for example:

  • Missing or too long CA trust chain.
  • Certificate signed by an unknown or untrusted CA.
  • Self-signed or unknown root CA.
  • Other verification errors.

Common Weakness Enumerations:

  • CWE-296 - Improper Following of a Certificate's Chain of Trust
  • Verify Certificate Expiry: Check the certificate's validity period and renew it if it has expired.
  • Include All intermediate Certificates: Make sure that the server provides all intermediate certificates required to complete the chain.
  • Install Root Certificates: Make sure the root certificate is installed and trusted on the client. This might involve updating the trusted root certificates.
  • Correct Certificate Order: Make sure that the certificates are in the correct order, starting from the server certificate, followed by intermediate certificates, and ending with the root certificate.
  • Use Tools for Verification: You can use tools like OpenSSL to verify the certificate chain.

Certificate verification failed

The certificate trust chain can not be verified using the built-in trusted CA list. This means that the chain of trust, which typically includes the root certificate, intermediate certificates, and the end-entity certificate, is broken or incomplete. There can be many reasons for this, for example:

  • Missing or too long CA trust chain.
  • Certificate signed by an unknown or untrusted CA.
  • Self-signed or unknown root CA.
  • Other verification errors.

Common Weakness Enumerations:

  • CWE-295 - Improper Certificate Validation
  • Verify Certificate Expiry: Check the certificate's validity period and renew it if it has expired.
  • Include All Intermediate Certificates: Make sure that the server provides all intermediate certificates required to complete the chain.
  • Install Root Certificates: Make sure the root certificate is installed and trusted on the client. This might involve updating the trusted root certificates.
  • Correct Certificate Order: Make sure that the certificates are in the correct order, starting from the server certificate, followed by intermediate certificates, and ending with the root certificate.
  • Use Tools for Verification: You can use tools like OpenSSL to verify the certificate chain.

Code analysis: SQL injection

SQL injection (SQLi) is a security vulnerability that allows an attacker to interfere with the queries that an application makes to its database. This can enable the attacker to steal or manipulate data. In some situations, an attacker can escalate an SQL injection attack to compromise the underlying server or other back-end infrastructure.

Common Weakness Enumerations:

  • CWE-89 - Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
  • Use Prepared Statements: (with Parameterized Queries)**: This ensures that SQL code is defined first and user input is passed as a parameter, preventing the execution of malicious SQL code.
  • Use Stored Procedures: Properly constructed stored procedures can help separate data from code.
  • Database Abstraction Layers (DALs): Use frameworks that provide DALs, such as Entity Framework, Hibernate, or Active Record. These layers abstract the database interactions and help ensure that queries are constructed safely.
  • Input Validation: Implement allow-list input validation to ensure only expected data is processed.
  • Escaping User Input: As a last resort, escape all user-supplied input to ensure it is treated as data rather than executable code.
  • Least Privilege: Make sure the database user has only the minimum privileges necessary to perform its tasks.

Code analysis: code injection

Code injection is a security vulnerability that occurs when an attacker is able to inject malicious code into an application, which is then executed by the server or client. This type of attack exploits poor handling of untrusted data, allowing the attacker to execute arbitrary code, manipulate application behavior, or access sensitive information. Code injection can lead to severe consequences, including data breaches, unauthorized access, and complete system compromise.

Common Weakness Enumerations:

  • CWE-94 - Improper Control of Generation of Code ('Code Injection')
  • Input Validation: Implement strict input validation to ensure only the expected data is processed. Use allow-lists to define acceptable input.
  • Use Safe APIs: Utilize APIs that avoid the use of interpreters or execute commands in a safe manner.
  • Least Privilege: Make sure the application runs with only the minimum privileges necessary to perform its tasks, limiting the potential impact of an injection attack.

Code analysis: command injection

Command injection is a security vulnerability that occurs when an attacker is able to execute arbitrary commands on the host operating system via a vulnerable application. This type of attack exploits insufficient input validation, allowing the attacker to pass malicious commands through user input fields, which are then executed by the system shell. Command injection can lead to unauthorized access, data breaches, and complete system compromise, as the injected commands are executed with the same privileges as the vulnerable application.

Common Weakness Enumerations:

  • CWE-78 - Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
  • Avoid Direct OS Command Calls: Use built-in library functions or APIs instead of executing OS commands directly. For example, use mkdir() instead of system("mkdir /dir_name").
  • Input Validation: Implement strict input validation using allow-lists to ensure only expected data is processed. You can use regular expressions to validate input formats.
  • Escape Special Characters: Properly escape special characters in user input to neutralize any potentially harmful elements. For example, use escapeshellarg() in PHP.
  • Use Parameterized Commands: If calling system commands is unavoidable, use parameterized commands to separate data from command logic.
  • Least Privilege: Make sure the application runs only with the minimum privileges necessary to perform its tasks, limiting the potential impact of an injection attack.

Code analysis: dangerous service launch

A dangerous service launch vulnerability occurs when a potentially dangerous service or daemon, such as Dropbear, Telnet, or sshd, is automatically initiated by another application or service. These services are typically intended for troubleshooting or support situations and should not be enabled by default due to the security risks they pose. If left enabled, these services could be exploited by attackers to gain unauthorized access, execute arbitrary commands, or escalate privileges on the system.

Common Weakness Enumerations:

  • Disable Unnecessary Services: Make sure that potentially dangerous services are disabled by default and only enabled when absolutely necessary, such as for troubleshooting or support.
  • Access Control: Implement strict access control measures to limit who can enable or access high-risk services. Use strong authentication mechanisms.
  • Network Segmentation: Isolate systems running critical or vulnerable services from the rest of the network to minimize the potential impact of an exploit.
  • Logging and Monitoring: Enable logging and monitoring for any use of potentially dangerous services to detect and respond to unauthorized access attempts.

Code analysis: file inclusion

File inclusion occurs when an application allows users to include files from the server or remote locations. This can lead to Local File Inclusion (LFI) or Remote File Inclusion (RFI):

  • LFI allows an attacker to include files from the local server, potentially exposing sensitive data or executing malicious scripts.
  • RFI allows an attacker to include and execute files from remote servers, which can lead to remote code execution and full system compromise.

Both types of file inclusion vulnerabilities can be exploited to gain unauthorized access, manipulate data, or execute arbitrary code on the server.

Common Weakness Enumerations:

  • CWE-98 - Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')
  • CWE-829 - Inclusion of Functionality from Untrusted Control Sphere
  • Input Validation: Implement strict input validation using allow-lists to ensure only expected files are included. Avoid using user input directly in file paths.
  • Use Static File Paths: Avoid dynamic file inclusion whenever possible; use static file paths instead.
  • Disable Remote File Inclusion: Configure the server to disable remote file inclusion if it is not needed. For example, in PHP, set allow_url_include to Off.
  • Least Privilege: Make sure the application runs only with the minimum privileges necessary to perform its tasks, limiting the potential impact of an inclusion attack.

Code analysis: format string

A format string vulnerability occurs when an application processes user input as a format string in functions like printf, sprintf, or similar. This can allow an attacker to manipulate the format string to read from or write to arbitrary memory locations, leading to information disclosure, application crashes, or even arbitrary code execution.

Common Weakness Enumerations:

  • CWE-134 - Use of Externally-Controlled Format String
  • Avoid User-Controlled Format Strings: Never directly use user input as a format string. Always define format strings within the code.
  • Input Validation: Implement strict input validation to ensure that user input conforms to expected patterns and does not contain format specifiers.
  • Compiler Warnings: Enable compiler warnings for format string vulnerabilities. Many modern compilers can detect and warn about potential format string issues. For example, gcc supports -Wformat, -Wformat-nonliteral, and -Wformat-security.
  • Least Privilege: Run applications with only the minimum privileges necessary to limit the impact of a successful exploit.

Code analysis: header injection

Header injection occurs when an attacker is able to insert malicious headers into an HTTP response. This can lead to various attacks, such as HTTP response splitting, cross-site scripting (XSS), and cache poisoning. By manipulating headers, attackers can control the behavior of the web application and potentially compromise user data or redirect users to malicious sites.

Common Weakness Enumerations:

  • CWE-113 - Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')
  • Input Validation: Implement strict input validation to ensure that user input does not contain characters that can be interpreted as headers, such as newline characters (\n or \r\n).
  • Sanitize User Input: Use functions to sanitize user input, removing or encoding characters that could be used to inject headers.
  • Use Frameworks: Use web frameworks that automatically handle header construction and prevent injection attacks.
  • Content Security Policy (CSP): Implement CSP to restrict the sources from which content can be loaded, reducing the impact of header injection attacks.
  • Least Privilege: Make sure the web server runs with only the minimum privileges necessary to limit the impact of a successful exploit.

Code analysis: information leakage phpinfo

The phpinfo() function in PHP is used to output information about the PHP environment, including details about PHP compilation options, extensions, version, server information, and environment variables. While this function is useful for debugging and development, it can expose sensitive information if left accessible in a production environment. Attackers can leverage this information to gain insights into the server configuration, installed modules, and other details that can aid in further attacks.

Common Weakness Enumerations:

  • CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor
  • Disable phpinfo() in Production: Make sure that the phpinfo() function is disabled or removed from production environments by commenting out or deleting any calls to phpinfo() in your code.
  • Access Control: Restrict access to pages that use phpinfo() to authorized users only.
  • Environment Configuration: Use environment-specific configuration files to ensure that phpinfo() is only enabled in development environments and not in production.

Code analysis: insecure deserialization

Insecure deserialization occurs when an application deserializes untrusted data, allowing attackers to manipulate the serialized data to execute arbitrary code, escalate privileges, or perform other malicious actions. This vulnerability can lead to remote code execution, denial of service, and other security breaches. Deserialization attacks exploit the way data is converted from a serialized format back into an object, often bypassing security controls.

Common Weakness Enumerations:

  • CWE-502 - Deserialization of Untrusted Data
  • Avoid Deserialization of Untrusted Data: Make sure that only trusted data is deserialized. Validate and sanitize all input before deserialization.
  • Use Safe Deserialization Libraries: Use libraries and frameworks that provide secure deserialization mechanisms and avoid using unsafe deserialization methods.
  • Implement Integrity Checks: Use digital signatures or checksums to verify the integrity of serialized data before deserialization.
  • Restrict Deserialization to Known Types: Limit deserialization to a predefined set of classes and types to prevent unexpected objects from being deserialized.
  • Monitor and Log Deserialization Activities: Implement logging and monitoring to detect and respond to suspicious deserialization activities.
  • Least Privilege: Run applications with only the minimum privileges necessary to limit the impact of a successful exploit.

Code analysis: loose equality check

Loose equality checks occur when an application uses non-strict comparison operators (like == in JavaScript or PHP) that do not consider the data type of the operands. This can lead to unexpected behavior and security vulnerabilities, as different types of data can be considered equal. For example, in PHP, the string "0" and the integer 0 are considered equal when using the == operator. This can be exploited by attackers to bypass authentication, authorization, or other security mechanisms.

Common Weakness Enumerations:

  • CWE-597 - Use of Wrong Operator in String Comparison
  • Use Strict Comparison Operators: Always use strict comparison operators (like === in JavaScript or === in PHP) that check both the value and the type of the operands.
  • Input Validation: Implement strict input validation to ensure that data conforms to expected types and formats before performing comparisons.
  • Type Casting: Explicitly cast variables to the expected type before performing comparisons to avoid type juggling.

Code analysis: missing peer verification

Missing peer verification occurs when an application fails to properly verify the identity of the peer (for example a server) it is communicating with over a network. This can lead to man-in-the-middle (MitM) attacks, where an attacker intercepts and potentially alters the communication between the client and the peer. This vulnerability is particularly critical in TLS (Transport Layer Security) and DTLS (Datagram Transport Layer Security) connections, where the lack of proper verification can compromise the confidentiality and integrity of the transmitted data.

This issue is similar to Missing peer verification, but the vulnerability affects a script.

Common Weakness Enumerations:

  • CWE-311 - Missing Encryption of Sensitive Data
  • CWE-297 - Improper Validation of Certificate with Host Mismatch
  • CWE-295 - Improper Certificate Validation
  • CWE-599 - Missing Validation of OpenSSL Certificate
  • Enable Peer Verification: Make sure that peer verification is enabled in the network communication settings of your application. This typically involves setting the appropriate flags or options in your TLS/DTLS library (for example SSL_VERIFY_PEER in OpenSSL).
  • Avoid Disabling SSL Verification: Do not disable SSL verification through settings such as CURLOPT_SSL_VERIFYPEER in cURL. Disabling this setting (CURLOPT_SSL_VERIFYPEER set to 0) means that the authenticity of the peer's SSL certificate is not verified, making the connection vulnerable to MitM attacks. Always set CURLOPT_SSL_VERIFYPEER to 1 to enable verification.
  • Use Trusted Certificates: Configure your application to use a trusted certificate authority (CA) to verify the peer's certificate. This ensures that the peer's identity is authenticated by a trusted third party.
  • Implement Certificate Pinning: Use certificate pinning to bind the peer's certificate to the expected certificate or public key. This adds an additional layer of security by ensuring that only the specified certificate is accepted.

Code analysis: object instantiation

Object instantiation vulnerabilities occur when an application allows user input to control the creation of objects. This can lead to unauthorized access, data manipulation, or execution of arbitrary code. Attackers can exploit this vulnerability to instantiate objects that should not be accessible or to create objects with malicious properties.

Common Weakness Enumerations:

  • CWE-470 - Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
  • Input Validation: Make sure that all user inputs are validated against a strict allow-list to prevent unauthorized object creation.
  • Use Factory Methods: Implement factory methods to control object creation and ensure that only authorized objects are instantiated.

Code analysis: path traversal

Path traversal, or directory traversal, allows an attacker to access files and directories that are stored outside the designated directory (such as a web root). By manipulating variables that reference files with .. and other characters, attackers can gain unauthorized access to the file system, potentially exposing sensitive information, modifying files, or executing arbitrary code.

Common Weakness Enumerations:

  • CWE-22 - Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
  • Input Validation: Implement strict input validation to ensure that user-supplied data does not contain path traversal characters such as .. or /.
  • Sanitize User Input: Remove or encode special characters from user input to prevent malicious path traversal.
  • Safe APIs: Use APIs that abstract file system access and automatically handle path traversal issues.
  • Access Controls: Apply strict access controls to limit file system access to only necessary files and directories.
  • File System Restrictions: Configure the file system to restrict access to sensitive directories and files.
  • Least Privilege: Make sure that the application runs with the minimum privileges necessary to perform its tasks, reducing the impact of a successful path traversal attack.

Code analysis: plaintext communication

Plaintext communication refers to the transmission of data in an unencrypted format. This can lead to man-in-the-middle (MitM) attacks, where an attacker intercepts and potentially alters the communication between the client and the peer. Plaintext communication can lead to data breaches, identity theft, and other security incidents.

Common Weakness Enumerations:

  • CWE-311 - Missing Encryption of Sensitive Data
  • CWE-319 - Cleartext Transmission of Sensitive Information
  • Use Encryption: Implement encryption protocols such as TLS (Transport Layer Security) to encrypt data in transit, ensuring that it cannot be easily intercepted and read by attackers.
  • Secure Configuration: Make sure that encryption settings are properly configured and up-to-date to prevent vulnerabilities in the encryption process.
  • Authentication: Use strong authentication mechanisms to verify users and devices before allowing them to communicate.
  • Network Segmentation: Segment the network to limit the exposure of sensitive data and reduce the risk of interception.

Code analysis: stack buffer overflow

A stack buffer overflow occurs when a program writes more data to a buffer located on the stack than it can hold. This can overwrite adjacent memory, leading to unpredictable behavior, crashes, or the execution of malicious code. Attackers can exploit stack buffer overflow vulnerabilities to gain unauthorized access, escalate privileges, or execute arbitrary code.

Common Weakness Enumerations:

  • CWE-121 - Stack-based Buffer Overflow
  • Input Validation: Implement strict input validation to ensure that data written to buffers does not exceed their allocated size.
  • Use Safe Functions: Avoid using unsafe functions like strcpy, sprintf, and gets that do not perform bounds checking. Instead, use safer alternatives like strncpy, snprintf, and fgets.
  • Stack Canaries: Use stack canaries, which are special values placed on the stack to detect buffer overflows before they can cause harm.
  • Implement Address Space Layout Randomization (ASLR): Enable ASLR binary hardening at compile time. ASLR randomizes the memory addresses used by the program, making it harder for attackers to exploit stack overflows to gain code execution.
  • Implement Non-Executable Stack (NX): Enable NX binary hardening at compile time to prevent the execution of code directly in the stack.

Code analysis: weak crypto

Weak cryptography refers to the use of outdated or insecure encryption algorithms, protocols, or key management practices. This vulnerability can leave sensitive data exposed to attackers who can decrypt, modify, or intercept the data. Weak cryptography can lead to data breaches, unauthorized access, and compromise of sensitive information.

Common Weakness Enumerations:

  • CWE-326 - Inadequate Encryption Strength
  • CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
  • Use Strong Encryption Algorithms: Implement strong, modern encryption algorithms such as AES (Advanced Encryption Standard) and RSA (Rivest-Shamir-Adleman).
  • Update Protocols: Regularly update cryptographic protocols to the latest versions.
  • Key Management: Implement robust key management practices, including secure key generation, storage, rotation, and disposal.
  • Avoid Deprecated Algorithms: Avoid using deprecated algorithms like DES (Data Encryption Standard) and MD5 (Message-Digest Algorithm 5) which are known to be insecure.
  • Secure Configuration: Make sure that cryptographic settings are properly configured.

Custom user defined

User defined custom issue. See issue description for details.

Dangerous service launch

A dangerous service launch vulnerability occurs when a potentially dangerous service or daemon, such as Dropbear, Telnet, or sshd, is automatically initiated during startup. These services are typically intended for troubleshooting or support situations and should not be enabled by default due to the security risks they pose. If left enabled, these services could be exploited by attackers to gain unauthorized access, execute arbitrary commands, or escalate privileges on the system.

Common Weakness Enumerations:

  • Disable Unnecessary Services: Make sure that potentially dangerous services are disabled by default and only enabled when absolutely necessary, such as for troubleshooting or support.
  • Access Control: Implement strict access control measures to limit who can enable or access high-risk services. Use strong authentication mechanisms.
  • Network Segmentation: Isolate systems running critical or vulnerable services from the rest of the network to minimize the potential impact of an exploit.
  • Logging and Monitoring: Enable logging and monitoring for any use of potentially dangerous services to detect and respond to unauthorized access attempts.

ELF missing full read-only relocation

The Executable and Linkable Format (ELF) is a common standard for executables, object code, shared libraries, and core dumps. When ELF binaries are not compiled with full Relocation Read-Only (RELRO) support, they lack a critical security measure. Without full RELRO, the Global Offset Table (GOT) remains writable, allowing attackers to perform GOT overwrite attacks. This can lead to arbitrary code execution, as attackers can redirect function calls to malicious code.

  • Enable Full RELRO: Compile binaries with full RELRO support to ensure that the GOT is marked read-only after the dynamic linker resolves all function addresses at the start of program execution. RELRO can be enabled during compilation using the following gcc options: gcc -g -O0 -Wl,-z,relro,-z,now -o <binary_name> <source_code>.
  • Use Position Independent Executables (PIE): Compile binaries as PIE to randomize memory addresses, making it harder for attackers to predict the location of the GOT.

ELF missing non-executable stack

The Executable and Linkable Format (ELF) is a standard for executables, object code, shared libraries, and core dumps. When ELF binaries are not configured to mark the stack as non-executable, they lack a critical security measure. This can allow attackers to execute code from the stack, leading to potential exploits such as buffer overflow attacks. By executing code from the stack, attackers can gain unauthorized access, escalate privileges, or execute arbitrary code.

  • Enable Non-Executable Stack: Configure the ELF binaries to mark the stack as non-executable using the PT_GNU_STACK header.
  • Compiler Flags: Use compiler flags such as -z noexecstack to ensure that the stack is marked non-executable during compilation.

ELF missing stack canary

A stack canary is a security mechanism used to detect and prevent stack buffer overflow attacks. It involves placing a small, random value (the "canary") before the return address on the stack. If a buffer overflow occurs, the canary value is overwritten, which can be detected before the function returns, preventing the execution of malicious code. When ELF binaries are missing stack canaries, they lack this critical protection, making them vulnerable to buffer overflow attacks that can lead to unauthorized access, privilege escalation, or arbitrary code execution.

When compiling software with the stack canaries protection enabled, the compiler adds the random value, only if it sees a potential risk in the code, like arrays that could be exploited. For simple programs that don't have these risk factors, the values might not be added, making it seem like the protection is not there. You can enforce canaries everywhere, ensuring better security, by using a specific compile option (such as -fstack-protector-all in GCC).

  • Enable Stack Canaries: Configure the compiler to include stack canaries using flags such as -fstack-protector or -fstack-protector-all.

ELF non PIC/PIE

Position-Independent Code (PIC) and Position-Independent Executables (PIE) are techniques used to enhance the security of ELF (Executable and Linkable Format) binaries. When ELF binaries are not compiled as PIC or PIE, they lack the ability to be loaded at randomized memory addresses, making them more predictable and easier targets for attackers. This predictability can be exploited in attacks such as Return-Oriented Programming (ROP), where an attacker reuses existing code sequences to execute arbitrary actions.

  • Compile with PIC/PIE: Make sure that all ELF binaries are compiled with PIC/PIE by using compiler flags such as -fPIC for shared libraries and -pie for executables.
  • Implement Address Space Layout Randomization (ASLR): ASLR randomizes the memory addresses used by the program, making it harder for attackers to predict the location of code and data.

ELF non stripped

When ELF (Executable and Linkable Format) binaries are not stripped, they contain symbol information such as function names, variable names, and debugging information. This can be useful for developers during debugging but poses a security risk in production environments. Attackers can leverage this information to understand the binary's structure, identify potential vulnerabilities, and develop targeted exploits.

  • Strip Binaries: Use tools like strip to remove symbol information from ELF binaries before deploying them to production. This reduces the amount of information available to attackers.
  • Obfuscation: Consider using code obfuscation techniques to make it harder for attackers to reverse-engineer the binary.

Expired certificate

An expired certificate occurs when a digital certificate, used for authentication and encryption purposes, has passed its validity period. Digital certificates are crucial for establishing trust and securing communications in various protocols, including HTTPS, SSL/TLS, and code signing. When a certificate expires, it can lead to multiple security risks, such as service disruptions or man-in-the-middle (MITM) attacks

Common Weakness Enumerations:

  • CWE-324 - Use of a Key Past its Expiration Date

  • Automatically refresh certificates: Use automatic certificate refresh mechanism to automatically refresh and replace certificates and obtain trusted CA certificates.

  • Certificate inventory: Maintain a comprehensive, regularly updated certificate inventory.

Hardcoded SSH host key

A Hardcoded SSH host key issue occurs when there is an embedded SSH host key directly within the source code or firmware of an application. SSH host keys are used to verify the identity of a server during the SSH handshake process. Hardcoding these keys can pose a significant security risk as they can be easily extracted by anyone with access to the firmware, leading to potential man-in-the-middle attacks and unauthorized access.

Common Weakness Enumerations:

  • CWE-798 - Use of Hard-coded Credentials
  • CWE-259 - Use of Hard-coded Password
  • CWE-321 - Use of Hard-coded Cryptographic Key
  • CWE-323 - Reusing a Nonce, Key Pair in Encryption
  • Protected Memory Areas: Store SSH host keys in protected memory areas within the firmware. These areas are specifically designed to store sensitive information securely.
  • Encrypted Flash Memory: Use encrypted flash memory to store SSH host keys. This ensures that data is automatically encrypted when written and decrypted when read, providing a layer of protection against unauthorized access.
  • Trusted Platform Module (TPM): Use TPMs to securely store SSH host keys. TPMs provide hardware-based security features that can protect cryptographic keys and other sensitive information.
  • Secrets Management Tools: Use secrets management tools (for example, HashiCorp Vault, AWS Secrets Manager, and Azure Key Vault) to securely store and manage SSH host keys.

Hardcoded account password

A hardcoded account password issue occurs when the to authentication information (usernames and passwords) are embedded directly within firmware, source code, or configuration files, so the credentials cannot be changed by end users and remain consistent across all device deployments. This vulnerability provides attackers with a permanent backdoor to access the system as, once discovered, these credentials can be exploited to gain unauthorized access, potentially leading to complete system compromise, data theft, or use of the device in larger attack campaigns.

Common Weakness Enumerations:

  • CWE-257 - Storing Passwords in a Recoverable Format
  • CWE-798 - Use of Hard-coded Credentials
  • CWE-259 - Use of Hard-coded Password
  • Remove Hardcoded Credentials: Eliminate all hardcoded credentials from the firmware and replace them with user-configurable authentication mechanisms.
  • Enforce Password Changes: Implement mandatory password changes during initial setup to ensure default credentials are not used in production environments.
  • Implement Secure Storage: Store credentials in secure, encrypted storage rather than embedding them in code or configuration files.
  • Authentication Monitoring: Implement monitoring for authentication attempts, especially those using known default or hardcoded credentials, to detect potential exploitation.

Hardcoded certificate with private key

A hardcoded certificate with private key issue occurs when cryptographic credentials are embedded directly within firmware, source code, or configuration files. When private keys are hardcoded and shared across multiple devices, a compromise of one device potentially compromises the security of all devices using the same key. This can lead to various attacks including man-in-the-middle attacks, unauthorized data decryption, impersonation of legitimate devices, and compromise of secure communication channels.

Common Weakness Enumerations:

  • CWE-798 - Use of Hard-coded Credentials
  • CWE-259 - Use of Hard-coded Password
  • CWE-321 - Use of Hard-coded Cryptographic Key
  • CWE-323 - Reusing a Nonce, Key Pair in Encryption
  • Avoid Hardcoding Certificates: Never embed private keys or certificates directly into the firmware or source code. Use secure mechanisms for dynamic certificate provisioning.
  • Certificate Rotation: Implement regular certificate renewal and revocation processes to invalidate compromised or outdated certificates.
  • Implement Secure Storage: Use secure key storage solutions, such as encrypted storage, to store certificates and private keys safely.

Hardcoded credential

A hardcoded credential issue occurs when sensitive access tokens, API keys, or command parameters are embedded directly within firmware, source code, or configuration files. This includes:

  • AWS credentials
  • sshpass commands
  • openssl parameters
  • curl authentication tokens
  • wget commands
  • wgetrc files.

Once discovered, these credentials can be exploited to gain unauthorized access to cloud services, remote servers, or protected resources, potentially leading to data breaches and service abuse.

Common Weakness Enumerations:

  • CWE-257 - Storing Passwords in a Recoverable Format
  • CWE-798 - Use of Hard-coded Credentials
  • CWE-259 - Use of Hard-coded Password
  • Remove Hardcoded Service Credentials: Eliminate all hardcoded API keys, tokens, and command-line credentials from the firmware and replace them with secure credential management solutions.
  • Implement Secure Storage: Store service credentials in secure, encrypted storage rather than embedding them in code or configuration files.
  • Regular Credential Rotation: Implement processes to regularly rotate service credentials and ensure the firmware supports credential updates without requiring full firmware replacement.

Hardcoded private key

A hardcoded private key issue occurs when cryptographic private keys are embedded directly within firmware, source code, or configuration files. Private keys are meant to be kept secret and secure, as they are used for sensitive operations such as decryption, authentication, or digital signing. When a private key is hardcoded, it becomes accessible to anyone who can view the source code or reverse engineer the application. This exposure significantly compromises the security of the entire system that relies on that key. Attackers who obtain the hardcoded private key can potentially decrypt sensitive data, forge authenticated messages, or gain unauthorized access to protected resources. Moreover, hardcoding private keys makes it extremely difficult to rotate or update keys, which is a crucial security practice to mitigate the risks of key compromise.

ONEKEY can detect the following private key types:

  • PEM encoded private keys
  • DER/ASN1 encoded private keys
  • DER/ASN1 encoded private keys in HEX-encoded form
  • OpenSSH & Dropbear SSH keys

Common Weakness Enumerations:

  • CWE-798 - Use of Hard-coded Credentials
  • CWE-259 - Use of Hard-coded Password
  • CWE-321 - Use of Hard-coded Cryptographic Key
  • CWE-323 - Reusing a Nonce, Key Pair in Encryption
  • Generate Unique Keys: Make sure that each device has unique cryptographic keys generated rather than sharing common keys across multiple devices.
  • Key Management Systems: Implement a robust key management system for generating, distributing, and rotating cryptographic keys.
  • Access Controls: Implement strict access controls to limit who can view or use private keys.

Information leakage: DS_Store file

This information leakage issue occurs when .DS_Store files are inadvertently included in firmware, applications, or web deployments. These files, automatically generated by macOS, contain metadata about directory structures, file names, and sometimes file attributes. When exposed to users or attackers, .DS_Store files can reveal sensitive information about the development environment, internal file organization, hidden resources, or unpublished features. This metadata can be leveraged by attackers to discover potentially vulnerable files, understand application architecture, or gather intelligence for more targeted attacks.

Common Weakness Enumerations:

  • CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor
  • CWE-538 - Insertion of Sensitive Information into Externally-Accessible File or Directory
  • Implement Exclusion Rules: Configure version control systems and build processes to automatically exclude .DS_Store files using .gitignore or similar mechanisms.
  • Pre-deployment Scanning: Implement automated scans in CI/CD pipelines to detect and remove .DS_Store files before deployment.
  • File Cleanup Tools: Use tools that automatically remove macOS-specific metadata files from projects before packaging or deployment.

Information leakage: svn directory

Subversion (SVN) is a version control system used to manage and track changes in source code and other files. If an .svn directory is unintentionally left in a firmware, it can result in significant information leakage. Attackers can exploit this by retrieving sensitive project data, such as file structure, configuration files, source code, and even credentials embedded in the code, leading to severe security risks.

Common Weakness Enumerations:

  • CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor
  • CWE-538 - Insertion of Sensitive Information into Externally-Accessible File or Directory
  • Pre-deployment Scanning: Implement automated scans in CI/CD pipelines to detect and remove .svn files before deployment.

Information leakage: vim swap file

This information leakage issue occurs when Vim swap files (.swp, .swo, .swn) are inadvertently included in firmware, applications, or deployments. These temporary files are created by the Vim text editor during file editing to preserve changes in case of crashes or interruptions. Vim swap files contain partial or complete copies of the files being edited, including potentially sensitive information such as configuration data, credentials, or proprietary code. When exposed to users or attackers, these swap files can reveal confidential information that was never intended for distribution, potentially leading to security breaches, intellectual property theft, or exposure of authentication credentials.

Common Weakness Enumerations:

  • CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor
  • CWE-538 - Insertion of Sensitive Information into Externally-Accessible File or Directory
  • Implement Exclusion Rules: Configure version control systems and build processes to automatically exclude Vim swap files using .gitignore or similar mechanisms.
  • Pre-deployment Scanning: Implement automated scans in CI/CD pipelines to detect and remove Vim swap files before deployment.
  • Configure Vim Directory: Set up Vim to store swap files in a centralized directory outside of project folders using the 'directory' option.

Insecure Android build configuration

Insecure Android build configuration refers to improper settings in the Android default.prop file, which can lead to security vulnerabilities. Specifically, if the properties ro.secure and ro.debuggable are not correctly set, it can allow unauthorized access and debugging capabilities on the device. This can enable attackers to gain privileged access, execute arbitrary code, and compromise the device's security.

Common Weakness Enumerations:

  • Disable Debugging: Ensure that debugging is disabled by setting ro.debuggable=0 in the default.prop file. This prevents unauthorized debugging access.
  • Enable Secure Mode: Set ro.secure=1 in the default.prop file to enforce secure mode, which restricts access to sensitive system functions and data.

Insecure Dropbear SSH server launch

The improper use of certain command-line options in Dropbear SSH server configurations can compromise the security of the system. Specifically, options like

  • -B (allow blank password login)
  • -T (maximum number of authentication attempts)
  • -w (disallow root login)

must be carefully managed to prevent unauthorized access. Failing to configure these settings securely can lead to weak authentication mechanisms and expose the system to brute force or privilege escalation attacks.

Common Weakness Enumerations:

  • CWE-489 - Active Debug Code
  • CWE-757 - Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade')
  • CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
  • Disallow Blank Password Login (-B): Make sure that the -B option is not used, so blank password logins are disallowed. This prevents attackers from gaining access with empty passwords.
  • Limit Authentication Attempts (-T): Set the -T option to a low value (for example, -T 3) to restrict the maximum number of authentication attempts, thereby reducing the effectiveness of brute force attacks.
  • Disallow Root Login (-w): Always include the -w option to prevent direct root login. This ensures that attackers cannot directly target the root account, forcing them to escalate privileges from a less privileged user account.
  • Use Strong Authentication: Employ key-based authentication and avoid relying solely on passwords to secure the Dropbear SSH server.

Insecure OpenSSH server configuration

An insecure OpenSSH server configuration issue occurs when SSH daemon settings are improperly configured, creating potential security vulnerabilities despite using an inherently secure protocol.

The vulnerability typically involves problematic settings in sshd_config related to cryptographic parameters, authentication mechanisms, and access controls such as:

  • weak Ciphers
  • enabled HostbasedAuthentication
  • disabled IgnoreRhosts
  • outdated kexalgorithms
  • weak MACs
  • high MaxAuthTries values
  • enabled PermitEmptyPasswords
  • enabled PermitUserEnvironment
  • enabled PermitRootLogin
  • outdated Protocol versions
  • disabled StrictModes
  • enabled X11Forwarding

These misconfigurations can lead to unauthorized access, credential theft, man-in-the-middle attacks, or privilege escalation.

Common Weakness Enumerations:

  • CWE-489 - Active Debug Code
  • CWE-757 - Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade')
  • CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
  • Disable Unnecessary SSH Access: If possible, completely disable SSH access to the device. Only enable SSH when absolutely required for administration.
  • Secure Cryptographic Settings: Make sure configuration of cryptographic parameters including Ciphers, KexAlgorithms, MACs, and Protocol are secure. OpenSSH has secure default cryptographic configuration; do not change these settings unless you are sure about the security of the configured ciphers.
  • Harden Authentication Mechanisms: Disable insecure authentication modes by properly configuring HostbasedAuthentication, IgnoreRhosts, MaxAuthTries, PermitEmptyPasswords, PermitRootLogin, and StrictModes. OpenSSH has a secure default authentication configuration; do not change these settings unless you are comfortable with the potential security implications.

Insecure RSA exponent

The RSA (Rivest-Shamir-Adleman) algorithm is a widely used public-key cryptosystem. It relies on a public key for encryption and a private key for decryption. The public key consists of a modulus (n) and an exponent (e). An insecure RSA exponent, especially a small one like 3, can introduce vulnerabilities. Small exponents can lead to security risks, such as Hastad's Broadcast Attack, which exploits the fact that the same message encrypted with the same small exponent and different moduli can be easily broken. Additionally, without proper padding schemes like OAEP (Optimal Asymmetric Encryption Padding), small exponents can make it easier for attackers to recover the plaintext from the ciphertext.

Common Weakness Enumerations:

  • CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
  • Use a Larger Exponent: Choose a larger exponent, such as 65537 (recommended by NIST-800-78-4), which is commonly used and provides a good balance between security and performance.
  • Implement Proper Padding: Make sure that proper padding schemes like OAEP are used to protect against vulnerabilities introduced by small exponents.
  • Sufficient Key Length: Use RSA keys that are at least 2048 bits long.

Insecure management protocol

An insecure management protocols issue occurs when the device management protocols or their respective implementations are known to be insecure or contain back-door accounts/passwords. These vulnerabilities can allow unauthorized access, leading to potential data breaches, system compromise, and other security risks.

  • Disable Insecure Services: Make sure that insecure services are disabled by default and only enabled temporarily when necessary.
  • Use Firewalls: If the device does not provide a mechanism to disable insecure services, use firewalls to block or limit access to these services.
  • Secure Alternatives: Where possible, replace insecure management protocols with secure alternatives that provide encryption and authentication mechanisms.
  • Access Control: Implement strict access control measures to limit who can enable or configure management protocols. Make sure that only authorized personnel have access to these settings.

Invalid certificate

An invalid certificate issue occurs when a digital certificate cannot be properly loaded or verified. This issue often arises due to non-standard content, incompatible extensions, or an invalid combination of properties and extensions in the certificate. Such certificates may fail to establish secure connections, leaving the system vulnerable to interception or attacks, including man-in-the-middle (MITM) attacks, and potentially compromising the integrity of communications.

Common Weakness Enumerations:

  • CWE-295 - Improper Certificate Validation
  • Validate Certificates: Make sure all certificates conform to industry standards (for example, X.509) and comply with the expected format and extensions. Use validation tools to check for non-standard or incompatible properties.
  • Use Trusted Certificate Authorities (CAs): Obtain certificates from reputable and widely trusted CAs.
  • Update Certificate Libraries: Make sure that libraries handling certificates (like OpenSSL) are up to date to support modern standards and extensions.
  • Check Certificate Integrity: Verify that the certificate has not been tampered with or corrupted by comparing hashes or digital signatures.

Malicious software

Malicious software (malware) refers to programs or code designed to harm, exploit, or infiltrate systems without the user's consent. This includes viruses, worms, trojans, ransomware, and spyware. Embedded malicious code is often hidden within legitimate-looking software, allowing attackers to execute unauthorized actions, steal sensitive data, or compromise system integrity once the malware is activated.

Common Weakness Enumerations:

  • CWE-506 - Embedded Malicious Code
  • Use Reliable Antivirus Solutions: Deploy robust anti-virus and anti-malware tools to scan and detect malicious software in real time.
  • Implement Secure Software Supply Chains: Verify the authenticity of software before installation or deployment to avoid embedded malicious code.

Missing peer verification

Missing peer verification occurs when an application fails to properly verify the identity of the peer (for example a server) it is communicating with over a network. This can lead to man-in-the-middle (MitM) attacks, where an attacker intercepts and potentially alters the communication between the client and the peer. This vulnerability is particularly critical in TLS (Transport Layer Security) and DTLS (Datagram Transport Layer Security) connections, where the lack of proper verification can compromise the confidentiality and integrity of the transmitted data.

This issue us similar to Code analysis: missing peer verification, but the vulnerability is the script instead of the binary.

Common Weakness Enumerations:

  • CWE-297 - Improper Validation of Certificate with Host Mismatch
  • CWE-295 - Improper Certificate Validation
  • CWE-599 - Missing Validation of OpenSSL Certificate
  • Enable Peer Verification: Make sure that peer verification is enabled in the network communication settings of your application. This typically involves setting the appropriate flags or options in your TLS/DTLS library (for example SSL_VERIFY_PEER in OpenSSL).
  • Avoid Disabling SSL Verification: Do not disable SSL verification through settings such as CURLOPT_SSL_VERIFYPEER in cURL. Disabling this setting (CURLOPT_SSL_VERIFYPEER set to 0) means that the authenticity of the peer's SSL certificate is not verified, making the connection vulnerable to MitM attacks. Always set CURLOPT_SSL_VERIFYPEER to 1 to enable verification.
  • Use Trusted Certificates: Configure your application to use a trusted certificate authority (CA) to verify the peer's certificate. This ensures that the peer's identity is authenticated by a trusted third party.
  • Implement Certificate Pinning: Use certificate pinning to bind the peer's certificate to the expected certificate or public key. This adds an additional layer of security by ensuring that only the specified certificate is accepted.

Obsolete certificate version

An obsolete certificate version issue occurs when outdated versions of X.509 certificates are used, specifically version 1, which was published in 1988. The latest version - X.509 version 3 - was published in 2008 and includes support for certificate extensions and enhanced security features. Using version 1 certificates can expose systems to security risks due to the lack of modern cryptographic enhancements and extensions. This can lead to vulnerabilities such as man-in-the-middle attacks, unauthorized access, and data breaches.

Common Weakness Enumerations:

  • CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
  • Upgrade to Version 3: Make sure all X.509 certificates are upgraded to version 3.
  • Regular Updates: Regularly update certificates to adhere to current security standards and recommendations. This helps to patch known vulnerabilities and reduce the risk of exploitation

Obsolete communication protocol

Obsolete communication protocols, such as outdated versions of HTTP, FTP, and SSH, have inherent security flaws that are typically unfixable. Using these protocols is discouraged because they can expose systems to various security risks, including data breaches, unauthorized access, and man-in-the-middle attacks.

Common Weakness Enumerations:

  • CWE-757 - Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade')
  • CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
  • Disable Obsolete Protocols: Disable support for using obsolete secure communication protocols. Avoid using SSH versions lower than 2.0 ( SSH1.x has known security vulnerabilities and should be replaced with SSH2.0, which offers enhanced security features) and SSLv2, SSLv3, TLS1, TLS1.1 protocols (these older protocols have inherent weaknesses and should be replaced with TLS1.2 or higher).
  • Disable Insecure Services: Make sure that insecure services are disabled by default and only enabled temporarily when necessary. This reduces the attack surface and limits the exposure of vulnerable protocols.

Plaintext communication

A plaintext communication issue occurs when data is transmitted without encryption, exposing sensitive information to potential interception and tampering.

This vulnerability is commonly found in firmware and applications that use network utilities without proper security configurations. Specifically,

  • curl command invocations
  • wget command invocations

Common Weakness Enumerations:

  • CWE-311 - Missing Encryption of Sensitive Data
  • CWE-319 - Cleartext Transmission of Sensitive Information
  • Enforce HTTPS: Modify all curl and wget commands to use HTTPS instead of HTTP by default, ensuring data is encrypted during transmission.
  • Implement Certificate Validation: Make sure that certificate validation is properly enabled and not bypassed with options like --insecure (curl) or --no-check-certificate (wget).
  • Secure data channels: Do not trust any data obtained through insecure communication channels, especially software updates, control commands etc. Do not send any data over insecure communication channels, especially sensitive information such a passwords or other credentials, personal information, commands etc.

Privilege escalation

Privilege Escalation is a critical security vulnerability where an attacker gains elevated access to resources that are normally protected from an application or user. This occurs when an application or user is able to access functions or content reserved for more privileged accounts. There are two main types of privilege escalation:

  • Vertical: A lower privileged user accesses functions reserved for higher privileged users or applications.
  • Horizontal: A user accesses functions and content reserved for other users with similar access levels.

Privilege escalation can lead to unauthorized data access, system compromise, and potential full control of the affected system.

Common Weakness Enumerations:

  • CWE-269 - Improper Privilege Management
  • Implement Principle of Least Privilege: Make sure users and processes only have the minimum levels of access necessary to perform their functions.
  • Review Configuration Files: Review configuration files, such as sudoer definitions, to make sure that unprivileged users cannot execute arbitrary commands with elevated privileges.
  • Strong Access Controls: Implement robust authentication and authorization mechanisms, including multi-factor authentication where appropriate.
  • Input Validation and Sanitization: Implement thorough input validation and sanitization to prevent injection attacks that could lead to privilege escalation.
  • Privilege Separation: Design systems with clear separation of privileges, using techniques like sandboxing and containerization to isolate different parts of the application.

SSH Authorized Keys

SSH authorized key fingerprints are used for public key authentication in SSH, providing a secure way to authenticate users without passwords. However, if an attacker gains possession of the corresponding private key, they can log in via SSH, bypassing other authentication mechanisms. This risk is heightened if cryptographic keys are hardcoded into the system, as these keys can be extracted and misused to access the system or impersonate users.

Common Weakness Enumerations:

  • CWE-321 - Use of Hard-coded Cryptographic Key
  • Avoid Hardcoding Keys: Never embed SSH private keys directly into source code or firmware. Instead, use secure storage mechanisms for private keys.
  • Provide User Configuration Options: If SSH public-key authentication is absolutely required, instead of hard-coding keys, allow users to provide public keys through management interfaces or during device setup/initialization.
  • Enforce Strong Key Management: Rotate SSH keys periodically and revoke old or compromised keys promptly. Maintain a strict policy for authorized keys.
  • Restrict Key Usage: Limit the scope of authorized keys to specific tasks or systems by configuring command=, from=, and other SSH options in the authorized_keys file.
  • Implement Access Controls: Enforce strict file permissions on ~/.ssh directories and authorized_keys files to prevent unauthorized access or modification.

Short certificate key length

Short certificate key length refers to the use of cryptographic keys that are too short, which decreases the time required to crack or brute-force the private key. Using inadequate key lengths increases the risk of key compromise, allowing attackers to decrypt sensitive data, impersonate entities, and perform other malicious activities. This vulnerability is particularly concerning for certificates used in SSL/TLS, SSH, and other secure communications protocols.

Common Weakness Enumerations:

  • CWE-326 - Inadequate Encryption Strength
  • Use Adequate Key Lengths: Make sure that cryptographic keys meet the recommended minimum lengths. For RSA keys, use at least 2048 bits; for ECC keys, use at least 256 bits.
  • Regular Updates: Regularly update certificates and cryptographic keys to adhere to current security standards and recommendations.

Trusted CA missmatch

A Trusted CA Mismatch occurs when a certificate has the same subject as a trusted Certificate Authority (CA) certificate, but its fingerprint differs from the stored copy of the CA certificate. This can happen when CAs change their signature algorithm or renew their certificates, resulting in a new CA certificate. However, this mismatch can also be due to a malicious certificate implanted by an attacker to forge certificates and abuse trust. Such a scenario can lead to man-in-the-middle attacks, where attackers impersonate trusted entities to intercept or manipulate sensitive data.

Common Weakness Enumerations:

  • CWE-345 - Insufficient Verification of Data Authenticity
  • Certificate Validation: Implement strict certificate validation processes to ensure that the certificate's fingerprint matches the stored copy of the trusted CA certificate.
  • Regular Updates: Regularly update the list of trusted CA certificates to include the latest versions and remove outdated ones.
  • Certificate Pinning: Use certificate pinning to bind a service to a specific certificate or public key.
  • Fallback Mechanisms: Implement fallback mechanisms to handle cases where a certificate mismatch is detected, such as prompting the user for manual verification or blocking the connection until the issue is resolved.

Unwanted software

The inclusion of unnecessary software in embedded systems, such as GNU Debugger (gdbserver and gdb), tcpdump, TShark, Nmap, strace, ltrace, and netcat, poses significant security risks. These tools, used for debugging, network analysis, and system exploration, can be exploited by attackers during post-exploitation. Attackers can use these tools to analyze network traffic, map the system, monitor system calls, or execute arbitrary commands, severely compromising the device's security and functionality.

Common Weakness Enumerations:

  • Audit and Remove Unnecessary Tools: Identify and remove software like gdbserver, gdb, tcpdump, TShark, Nmap, strace, ltrace, and netcat before deploying the system to production.
  • Disable Debugging Tools in Production: Make sure that debugging and network analysis tools are disabled or completely removed from production firmware.

Vulnerability pattern

A vulnerability pattern issue occurs when there are known vulnerabilities within software components. These vulnerabilities can stem from outdated libraries, insecure code, or flawed design elements. When a component contains known vulnerabilities, it can be exploited by attackers to gain unauthorized access, execute malicious code, or compromise system integrity. This can lead to data breaches, system downtime, and other security incidents.

  • Regular Updates: Make sure that all software components are regularly updated to the latest versions.
  • Vulnerability Scanning: Implement automated vulnerability scanning tools to identify and assess known vulnerabilities in software components.
  • Dependency Management: Use dependency management tools to track and update libraries and frameworks. For example, ONEKEY is an excellent choice!

Weak certificate signing algorithm

A weak certificate signing algorithm issue occurs when digital certificates are signed using cryptographically vulnerable hashing algorithms such as MD5 or SHA1. These outdated algorithms have known vulnerabilities that can be exploited to generate hash collisions for certificate forgery. When certificates use weak signing algorithms, attackers can create fraudulent certificates that appear valid, enabling man-in-the-middle attacks, impersonation of legitimate services, or circumvention of authentication mechanisms.

Common Weakness Enumerations:

  • CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
  • CWE-328 - Use of Weak Hash
  • Use Strong Algorithms: Replace certificates using weak algorithms (MD5, SHA1) with certificates signed using SHA-256 or stronger algorithms.
  • Implement Certificate Validation: Make sure that systems verify the signing algorithm of certificates and reject those using deprecated algorithms.

Weak cipher usage

Weak cipher usage refers to the implementation of cryptographic algorithms that are insecure due to known vulnerabilities, insufficient key lengths, or outdated designs. These ciphers are susceptible to various cryptanalytic attacks, potentially compromising the confidentiality and integrity of encrypted data. Common examples include DES (Data Encryption Standard), RC4 (Rivest Cipher 4), and older versions of SSL/TLS protocols. The use of weak ciphers can lead to unauthorized data access, man-in-the-middle attacks, and other security breaches.

Common Weakness Enumerations:

  • CWE-326 - Inadequate Encryption Strength
  • CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
  • CWE-328 - Use of Weak Hash
  • Cipher Inventory and Removal: Conduct a thorough inventory of all cryptographic implementations across the system. Identify and remove all instances of weak ciphers such as DES, RC4, or any cipher with key lengths less than 128 bits.
  • Implement Strong Cipher Suites: Replace weak ciphers with strong, modern alternatives. For symmetric encryption, use AES (Advanced Encryption Standard) with at least 256-bit key length. For asymmetric encryption, use RSA with at least 2048-bit keys or elliptic curve cryptography (ECC) with 256-bit keys.
  • Update TLS Configurations: If the weak ciphers are part of SSL/TLS implementations, update to TLS 1.2 or preferably TLS 1.3. Configure the server to use only strong cipher suites, prioritizing those with Perfect Forward Secrecy (PFS) such as ECDHE-RSA-AES256-GCM-SHA384.
  • Automated Scanning Tools: Implement automated scanning tools - such as the **ONEKEY API - in the CI/CD pipeline to detect and prevent the introduction of weak ciphers in new code or configurations.