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

SSL verification is disabled through curl CURLOPT_SSL_VERIFYPEER setting.

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

Do not use disable SSL verification. Ensure that certificates or public keys that could be used to verify peer certificate or host-keys are provided. Alternatively, publish verification information through DNS and use DNSSEC to protect the authenticity of the verification information.

Enforce strict peer validation when establishing secure communication.

Code analysis: object instantiation

A new object is created where the class name is based on user input. This could lead to remote code execution, as it allows to instantiate any class in the application.

Common Weakness Enumerations:

  • CWE-470 - Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')

Sanitize all user and untrusted input before using it in new object instantiation

Code analysis: path traversal

Using user input when opening, modifying, or deleting files is potentially dangerous. A malicious actor could use this to create, modify, or access files they have no right to.

Common Weakness Enumerations:

  • CWE-22 - Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

Sanitize all user and untrusted input before using the variable to calculate a file path.

Code analysis: plaintext communication

Unencrypted communication can compromise the confidentiality, integrity and authenticity of the data.

Common Weakness Enumerations:

  • CWE-311 - Missing Encryption of Sensitive Data
  • CWE-319 - Cleartext Transmission of Sensitive Information

Avoid using non encrypted communication protocols, such as HTTP, FTP, telnet, rlogin/rsh/rexec. Use secure protocol variants such as HTTPS, SFTP or SSH.

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.

Where appropriate, block insecure communication channels using firewalls (though, depending on which protocols are required, this may degrade the functionality of the device).

Code analysis: stack buffer overflow

The binary copies user controlled data to a buffer allocated on the stack without checking boundaries. By writing data past the allocated buffer, an attacker could redirect execution and achieve arbitrary code execution.

Common Weakness Enumerations:

  • CWE-121 - Stack-based Buffer Overflow

Use secure C functions + FORTIFY + stack canary + ASLR.

Code analysis: weak crypto

Detected usage of weak cryptographic function

Common Weakness Enumerations:

  • CWE-326 - Inadequate Encryption Strength
  • CWE-327 - Use of a Broken or Risky Cryptographic Algorithm

Consider using stronger alternatives

Custom user defined

User defined custom issue. See issue description for details.

Dangerous service launch

Potentially dangerous service/daemon is started, which should be used only for troubleshooting or support situation, but should not be enabled by default.

System launches dropbear, telnet or sshd during boot. Detection only via rcS and inetd.conf files.

Common Weakness Enumerations:

Disable dangerous services (sshd, telnetd) used only for debugging or troubleshooting purpose. These should be enabled only temporarily when necessary.

If the device does not provide a mechanism to disable services use firewalls to block or limit access.

ELF missing full read-only relocation

Modern Linux distributions offer some mitigation techniques to make it harder to exploit software vulnerabilities reliably. RELRO is a memory corruption mitigation technique to harden the data sections of an ELF binary. There are two different operation modes of RELRO: Partial RELRO and Full RELRO.

Read-only relocation prevents attackers from over-writing the Global Offset Table (.got) or in case of a partial RelRO the .got.plt (Procedure Linkage Table) is writeable only.

Compile binaries with RelRO enabled.

RELRO can be enabled during compilation using the following gcc options: gcc -g -O0 -Wl,-z,relro,-z,now -o <binary_name> <source_code>

ELF missing non-executable stack

Modern Linux distributions offer some mitigation techniques to make it harder to exploit software vulnerabilities reliably. NoExecute (NX) / Data Execution Prevention (DEP) marking in the ELF program header indicates that the stack is not executable.

Compile binaries with no execute enabled.

It is enabled by modern GCC compiler unless the -z execstack flag is used.

ELF missing stack canary

Modern Linux distributions offer some mitigation techniques to make it harder to exploit software vulnerabilities reliably. Stack canaries can detect potential stack overflows and abort program execution.

A random data (canary) is pushed on the stack at the start of a function call and once the function call ends it is checked if the same value is read. A stack-overflow would overwrite the data and hence detecting the overflow would be possible.

⚠️ When compiling software with stack canaries protection enabled, the compiler adds special checks called stack canaries to detect certain types of attacks, but 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, these checks might not be added, making it seem like the protection isn't there. Customers can enforce these checks everywhere, ensuring better security, by using a specific compile option (e.g. -fstack-protector-all in GCC).

Compile binaries with stack canaries or stack guard enabled. This is done automatically by GCC unless the -fno-stack-protector flag is used. To enforce these checks everywhere, ensuring better security, we recommend using the -fstack-protector-all compile flag in GCC.

ELF non PIC/PIE

Modern Linux distributions offer some mitigation techniques to make it harder to exploit software vulnerabilities reliably. Allows code to be executed regardless of its absolute address. This allows to take advantage of memory mitigation features such as Address space layout randomization (ASLR).

Compile binaries with PIE/PIC enabled.

It is enabled by modern GCC compiler unless the -no-pie flag is used.

ELF non stripped

Modern Linux distributions offer some mitigation techniques to make it harder to exploit software vulnerabilities reliably. The presence of symbols in a binary make it easier for an attacker to reverse engineer the application. Binaries can be stripped to remove symbols which also decreases the file size.

Strip compiled binaries.

Binaries can be stripped using the strip command.

Expired certificate

Certificate is valid only for a pre-defined time window, defined by the not_valid_before and not_valid_after properties. Certificate should not be used or trusted outside of this time window. Using cryptographic materials past it's expiration time increase the time-window for cracking the key.

Common Weakness Enumerations:

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

Use proper automatic certificate refresh mechanism to automatically refresh certificates and obtain trusted CA certificates. Replace the certificate with a new, valid one. Make sure to obtain/issue a new certificate before the previous one expires.

Ensure that some mechanism is in place whereby invalid certificate can be removed effectively (for example, when a certificate is revoked).

If the certificate is a CA certificate, use the latest certificate of the given CA.

Hardcoded SSH host key

Hardcoding or sharing private key is a bad practice as any attacker with access to the firmware can easily impersonate any device using the key.

Detects SSH host keys in firmware.

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

Always use unique cryptographic keys and never share between devices. All cryptographic keys must be generated in a secure way and must not be shared between devices. Default keys required for initial setup must be replaced during device setup. The device should provide a way to replace/regenerate secure keys in case a key is compromised.

Hardcoded account password

Depending on which services are started at runtime, an attacker can log in via the serial port (physical access required) or over the network (telnet, SSH etc).

The following are checked to detect hardcoded accounts with password:

  • passwd & shadow files
  • htpasswd files
  • chpasswd commands
  • password hashes (des, md5, crypt, sha256, sha512)

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

Never share the same password between accounts or devices. Do not hardcode passwords in scripts or applications as these can be easily recovered by attackers and not easily replaced by vendors. Passwords should never be stored in plaintext. Passwords should never be hard-coded in a device firmware. Where passwords must be used, they should be generated on a per-device basis. Ensure that if a default password must be set, it is unique to the device.

Never share the same password between accounts or devices. If a default password is required for initial setup, always ensure that this password is unique to the given device, derived from information which may only be obtained given by a user with physical access to the device.

Wherever passwords might be used to gain privileged access to a device, try to limit service availability (e.g: disable SSH or other management interface access)

Passwords should never be stored in plaintext. Where passwords must be stored on the device, always use secure password hashing algorithms with unique salt values. This can help mitigate brute-force attacks, even if a hash is compromised.

Hardcoded certificate with private key

Hardcoding or sharing private key is a bad practice as any attacker with access to the firmware can easily impersonate any device using the key.

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

Always use unique cryptographic keys and never share between devices. All cryptographic keys must be generated in a secure way and must not be shared between devices. Default keys required for initial setup must be replaced during device setup. The device should provide a way to replace/regenerate secure keys in case a key is compromised.

Hardcoded credential

Hardcoding or sharing credentials is a bad practice as any attacker with access to the firmware can easily impersonate any device.

The following are checked to detect hardcoded credentials:

  • AWS credentials
  • sshpass commands
  • openssl commands
  • curl commands
  • wget commands & wgetrc files

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

Never share the same password between accounts or devices. Do not hardcode passwords in scripts or applications as these can be easily recovered by attackers and not easily replaced by vendors. Passwords should never be stored in plaintext. Passwords should never be hard-coded in a device firmware. Where passwords must be used, they should be generated on a per-device basis.

Hardcoded private key

Hardcoding or sharing private key is a bad practice as any attacker with access to the firmware can easily impersonate any device using the key.

Detects private keys in the firmware filesystem. The following private key types are detected:

  • PEM encoded private keys in the following formats:
  • BEGIN PRIVATE KEY
  • BEGIN RSA PRIVATE KEY
  • BEGIN DSA PRIVATE KEY
  • BEGIN X509 CERTIFICATE
  • 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

Ensure that each device uses a unique cryptographic key. A single private key should never be shared between multiple devices. All cryptographic keys must be generated in a secure way and must not be shared between devices. Default keys required for initial setup must be replaced during device setup. The device should provide a way to replace/regenerate secure keys in case a key is compromised.

Information leakage: DS_Store file

Detects information artifacts that are unintentionally leaked during the firmware development/build process. Information such as internal hostnames, IPs, URLs and usernames. This information is useful for an attacker in an information gathering phase of an attack against the organization who develops the firmware. This information could be used in further attacks.

The Mac OS X Finder stores information about how it displays directories and files in files named .DS_Store in each directory which it has touched. If necessary precautions with the automated deployment process are not taken by the developer or system administrator - then these files may land in the firmware and leak hidden files or directories.

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

Remove debug, build or source related files from production builds.

Only include production artifacts in firmware images. (Explicitly list files to be included in a production build and use automatic steps to build production firmware images)

Information leakage: svn directory

Detects information artifacts that are unintentionally leaked during the firmware development/build process. Information such as internal hostnames, IPs, URLs and usernames. This information is useful for an attacker in an information gathering phase of an attack against the organization who develops the firmware. This information could be used in further attacks.

A Subversion (SVN) working copy is created when part of a SVN repository is checked out. The information stored in the working copy folder .svn contains the URL of the repository and the usernames of developers. In some cases the working copy folder might contain source code that that is not intended to be shared outside the organization who develops the firmware.

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

Remove debug, build or source related files from production builds.

Only include production artifacts in firmware images. (Explicitly list files to be included in a production build and use automatic steps to build production firmware images)

Information leakage: vim swap file

Detects information artifacts that are unintentionally leaked during the firmware development/build process. Information such as internal hostnames, IPs, URLs and usernames. This information is useful for an attacker in an information gathering phase of an attack against the organization who develops the firmware. This information could be used in further attacks.

VIM swap files are created when a file is edited with VIM. The file extension is .swp, but in case of an existing swap file the extension is .swn, .swm...

Swap files can be used to recover changes made to file and are deleted when the file is closed. Apart from the changes to the file the swap file also contains the hostname, username and local file path of the user who edited the file. This information is useful for an attacker in an information gathering phase of an attack against the organization who develops the firmware.

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

Remove debug, build or source related files from production builds.

Only include production artifacts in firmware images. (Explicitly list files to be included in a production build and use automatic steps to build production firmware images)

Insecure Android build configuration

Performs checks on the Android default.prop file.

Common Weakness Enumerations:

Disable debugging and enable secure mode on Android devices by setting ro.secure=1 and ro.debuggable=0 in default.prop.

Insecure Dropbear SSH server launch

Miss-configuration of an even secure daemon/service could still cause potential serious risk.

The following command line options are currently checked:

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

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 SSH access to the device. If SSH access is required, disable weak authentication option in Dropbear:

  • Disable root login by adding -w option
  • Limit the maximum authentication tries by setting -T 3 option
  • Disable login with blank password by dropping -B option

If the device does not provide a mechanism to disable or modify SSH access, use firewalls to block or limit access.

Insecure OpenSSH server configuration

Miss-configuration of an even secure daemon/service could still cause potential serious risk.

OpenSSH server configuration is checked to detect potentially insecure settings in sshd_config:

  • Ciphers
  • HostbasedAuthentication
  • IgnoreRhosts
  • kexalgorithms
  • MACs
  • MaxAuthTries
  • PermitEmptyPasswords
  • PermitUserEnvironment
  • PermitRootLogin
  • Protocol
  • StrictModes
  • X11Forwarding

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 SSH access to the device. If SSH access is required, disable the usage of obsolete SSH protocol version and weak cryptographic ciphers and enforce the usage of secure protocols and ciphers:

Ciphers, KexAlgorithms, MACs, Protocol

OpenSSH has secure default cryptographic configuration, only change these settings if you are sure about the security of the configured ciphers. If the device does not provide a mechanism to disable or modify SSH access use firewalls to block or limit access.

Authentication

Disable SSH access to the device. If SSH access is required, disable the usage of insecure authentication modes:

  • HostbasedAuthentication, IgnoreRhosts, MaxAuthTries, PermitEmptyPasswords, PermitRootLogin, StrictModes

OpenSSH has a secure default authentication configuration: only change these settings if you are comfortable with the potential security implications.

If the device does not provide a mechanism to disable or modify SSH access, use firewalls to block or limit access.

Insecure RSA exponent

Choosing an insecure RSA exponent can significantly decrease the security of a certificate or RSA key.

Common Weakness Enumerations:

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

Issue or obtain a new certificate with a proper RSA public exponent.

NIST-800-78-4 recommends using 65537 as a public exponent.

Insecure management protocol

Some device management protocols or their respective implementations is know to be insecure or contains back-door accounts/passwords.

Disable insecure services and these should be enabled only temporarily when necessary.

If the device does not provide a mechanism to disable services use firewalls to block or limit access.

Invalid certificate

The certificate can not be properly loaded and checked. Most likely the certificate contains some non-standard content or extension or in some case some invalid combination of properties and extensions.

Common Weakness Enumerations:

  • CWE-295 - Improper Certificate Validation

Use certificate which confirms to the X509 standard and avoid using non-standard extensions.

Malicious software

Detects malicious software through anti-virus scanning.

Common Weakness Enumerations:

  • CWE-506 - Embedded Malicious Code

Investigate identified files and why they ended up in your firmware.

Missing peer verification

Encrypted communication without verifying the peer could lead into man in the middle attack.

The following instances of potential missing or flawed peer certificate ot host-key verifications are checked:

  • curl command invocations
  • wget command invocations
  • dropbear command invocations
  • ssh (OpenSSH) command invocations

Common Weakness Enumerations:

  • CWE-297 - Improper Validation of Certificate with Host Mismatch
  • CWE-295 - Improper Certificate Validation
  • CWE-599 - Missing Validation of OpenSSL Certificate

Ensure that certificates or public keys that could be used to verify peer certificate or host-keys are provided. Alternatively, publish verification information through DNS and use DNSSEC to protect the authenticity of the verification information.

Enforce strict peer validation when establishing secure communication. Do not explicitly disable peer validation. Ensure that the following command-line or configuration flags are not used:

  • curl: -k --insecure --proxy-insecure
  • wget: --no-check-certificate
  • dropbear: -y
  • openssh: User or Global KnownHostsFile set to null

Obsolete certificate version

X.509 certificate version 1 is expired, the latest version is 3.

Common Weakness Enumerations:

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

The latest version of the X.509 standard is 3.

Issue or obtain a new certificate using the latest version of the X.509 standard.

Obsolete communication protocol

Certain older protocols have inherent security flaws and their usage is discouraged due to these usually non-fixable issues.

The following instances of potential obsolete protocol usages are checked:

  • curl command invocations
  • wget command invocations
  • ssh (OpenSSH) command invocations

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 support for using obsolete secure communication protocols. Avoid using:

  • SSH versions lower than 2.0
  • SSLv2, SSLv3, TLS1, TLS1.1 protocols.

Plaintext communication

Unencrypted communication can compromise the confidentiality, integrity and authenticity of the data.

The following instances of potential plaintext communications are checked:

  • curl command invocations
  • wget command invocations

Common Weakness Enumerations:

  • CWE-311 - Missing Encryption of Sensitive Data
  • CWE-319 - Cleartext Transmission of Sensitive Information

Avoid using non encrypted communication protocols, such as HTTP, FTP, telnet, rlogin/rsh/rexec. Use secure protocol variants such as HTTPS, SFTP or SSH.

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.

Where appropriate, block insecure communication channels using firewalls (though, depending on which protocols are required, this may degrade the functionality of the device).

Privilege escalation

The firmware is affected by a misconfiguration allowing an unprivileged user to execute arbitrary commands with elevated privileges (root), therefore breaking privilege boundaries. If a legitimate user or an attacker can gain code execution on the device, they can take advantage of it to fully compromise the device.

Common Weakness Enumerations:

  • CWE-269 - Improper Privilege Management

We recommend reviewing configuration files such as sudoers definitions to make sure that unprivileged users cannot execute arbitrary commands with elevated (root) privileges.

SSH Authorized Keys

SSH authorized key fingerprints are used for SSH public key authentication. An attacker who possesses the associated private key can log in via SSH.

Common Weakness Enumerations:

  • CWE-321 - Use of Hard-coded Cryptographic Key

Do not hardcode authorized keys in the firmware. Usually it is used for providing vendor support & troubleshooting access, but this could be a backdoor as well.

To provide remote support functionality, it should be enabled by the user, where the user provides a secure key/code when remote troubleshooting is requested.

If the use of SSH public-key authentication is absolutely required, there are alternatives to hard-coding SSH public keys:

  • Allow a user to provide a public key through another management interface.
  • Allow a user to set up public key(s) during the device setup or initialization phase.

A secure mechanism to replace public keys should also be provided, in case a key is compromised.

If you are not the vendor of the device, and cannot remove the hardcoded authorized keys; disable SSH access either on the device or block SSH traffic to the device.

Short certificate key length

The key used by the certificate uses an inadequate key length which decrease the time required to crack or bruteforce the private key. Using too short keys could increase the risk of the compromise of the key.

Common Weakness Enumerations:

  • CWE-326 - Inadequate Encryption Strength

Issue or obtain a new certificate with an adequate key length.

Use at least 2048bit RSA keys and 256bit Elliptic Curve keys.

Trusted CA missmatch

The certificate has the same subject as a trusted CA certificate, however the fingerprint is different from our stored copy of CA certificate. Sometimes CAs change the signature algorithm or simply renew the certificate, hence a new CA certificate is available.

However the CA certificate can be a malicious certificate implanted by an attacker to forge certificates in order to abuse trust.

Common Weakness Enumerations:

  • CWE-345 - Insufficient Verification of Data Authenticity

Refresh and verify the CA certificate from a trusted source, like the CA website.

Unwanted software

Software that enables vulnerability analysis and post-exploitation by an attacker. The following components are categorized as unwanted: GNU Debugger (gdbserver and gdb), tcpdump, TShark, Nmap, strace, ltrace, and Netcat.

Common Weakness Enumerations:

Do not include applications used for debugging or troubleshooting in production firmware images. Remove debug symbols, debugging tools, packet dumpers, network scanners, and similar components.

Vulnerability pattern

Component contains know vulnerability.

Upgrade vulnerable component to the latest version or to the version recommended by the vendor.

Weak certificate signing algorithm

Certificate is using a known bad (MD5, SHA1) or an unknown certificate signing algorithm.

Common Weakness Enumerations:

  • CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
  • CWE-328 - Use of Weak Hash

Issue or obtain a new certificate with an adequate modern signature algorithm like SHA256, SHA512. (MD5 and SHA1 are considered outdated and insecure)

Weak cipher usage

Communication is protected by a known weak cipher, which increases the chance of a successful attack.

The following instances of potential obsolete protocol usages are checked:

  • curl command invocations
  • wget command invocations
  • ssh (OpenSSH) command invocations

Common Weakness Enumerations:

  • CWE-326 - Inadequate Encryption Strength
  • CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
  • CWE-328 - Use of Weak Hash

Use and enforce secure cryptographic algorithms. Most application, cryptographic & SSL libraries provide secure default values. Only override these settings when sure about the security of provide ciphers.