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. There could be many reason for that:
- missing or too long CA trust chain
- certificate signed by an unknown or untrusted CA
- other verification error
- self-signed or unknown root CA
Common Weakness Enumerations:
- CWE-296 - Improper Following of a Certificate's Chain of Trust
Use certificates issues by a trusted CA and deploy the complete CA chain in order to help verification.
Certificate verification failed¶
The certificate trust chain can not be verified using the built-in trusted CA list. There could be many reason for that:
- missing or too long CA trust chain
- certificate signed by an unknown or untrusted CA
- other verification error
- self-signed or unknown root CA
Common Weakness Enumerations:
- CWE-295 - Improper Certificate Validation
Use certificates issues by a trusted CA and deploy the complete CA chain in order to help verification.
Code analysis: SQL injection¶
User data flows into this manually-constructed SQL string. User data can be safely inserted into SQL strings using prepared statements or an object-relational mapper (ORM). Manually-constructed SQL strings is a possible indicator of SQL injection, which could let an attacker steal or manipulate data from the database.
Common Weakness Enumerations:
- CWE-89 - Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Use prepared statements ($mysqli->prepare("INSERT INTO test(id, label) VALUES (?, ?)");) or a
safe library.
Code analysis: code injection¶
The script calls the assert, eval or mb_ereg_replace (The eval modifier (e) evaluates the
replacement argument as code.) function on unsanitized user input. This is equivalent to 'eval'-ing and can lead to
arbitrary code injection.
Common Weakness Enumerations:
- CWE-94 - Improper Control of Generation of Code ('Code Injection')
Sanitize all user and untrusted input before using the variable or passing to an insecure function
Code analysis: command injection¶
The script executes an OS command constructed from unsanitized user input. This could lead to arbitrary command injection.
Common Weakness Enumerations:
- CWE-78 - Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Sanitize all user and untrusted input before using the variable or passing to a os execution call
Code analysis: 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 within a binary.
Common Weakness Enumerations:
- CWE-489 - Active Debug Code
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.
Code analysis: file inclusion¶
Detected non-constant file inclusion. This can lead to local file inclusion (LFI) or remote file inclusion (RFI) if user input reaches this statement. LFI and RFI could lead to sensitive files being obtained by attackers.
Common Weakness Enumerations:
Sanitize all user and untrusted input before using the variable and explicitly specify what to include.
Code analysis: format string¶
The software uses a function that accepts a format string as an argument, but the format string originates from an external source. When an attacker can modify an externally-controlled format string, this can lead to buffer overflows, denial of service, or data representation problems.
Common Weakness Enumerations:
- CWE-134 - Use of Externally-Controlled Format String
Use the appropriate format specifiers with printf and scanf family of functions and sanitize user input to prevent any malicious format string input.
Code analysis: header injection¶
Using user input when setting headers with header() is potentially dangerous.
This could allow an attacker to inject a new line and add a new header into the response. This is called HTTP response
splitting.
Common Weakness Enumerations:
- CWE-113 - Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')
Sanitize all user and untrusted input before passing to header() call and do not allow
whitespace inside
Code analysis: information leakage phpinfo¶
The 'phpinfo' function may reveal sensitive information about your environment.
Common Weakness Enumerations:
- CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor
Do not use phpinfo() in production code.
Code analysis: insecure deserialization¶
The script calls 'extract()' on user-controllable data.
Common Weakness Enumerations:
- CWE-502 - Deserialization of Untrusted Data
Sanitize all user and untrusted input before using the variable in extract() or use EXTR_SKIP
flag to prevent overwriting existing variables.
Code analysis: loose equality check¶
Potential type juggling problem due to improper comparison
Common Weakness Enumerations:
- CWE-597 - Use of Wrong Operator in String Comparison
Make sure comparisons involving md5 values are strict (use === not ==) to avoid type
juggling issues
Code analysis: missing peer verification¶
SSL verification is disabled through curl CURLOPT_SSL_VERIFYPEER setting.
Common Weakness Enumerations:
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:
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¶
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:
- CWE-489 - Active Debug Code
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:
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:
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:
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:
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 KEYBEGIN RSA PRIVATE KEYBEGIN DSA PRIVATE KEYBEGIN X509 CERTIFICATE- DER/ASN1 encoded private keys
- DER/ASN1 encoded private keys in HEX-encoded form
- OpenSSH & Dropbear SSH keys
Common Weakness Enumerations:
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:
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:
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:
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:
- CWE-489 - Active Debug Code
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:
Disable SSH access to the device. If SSH access is required, disable weak authentication option in Dropbear:
- Disable root login by adding
-woption - Limit the maximum authentication tries by setting
-T 3option - Disable login with blank password by dropping
-Boption
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:
CiphersHostbasedAuthenticationIgnoreRhostskexalgorithmsMACsMaxAuthTriesPermitEmptyPasswordsPermitUserEnvironmentPermitRootLoginProtocolStrictModesX11Forwarding
Common Weakness Enumerations:
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:
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:
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:
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:
- CWE-489 - Active Debug Code
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:
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:
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.