| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An issue discovered in esptool 4.6.2 allows attackers to view sensitive information via weak cryptographic algorithm. |
| CryptoES is a cryptography algorithms library compatible with ES6 and TypeScript. Prior to version 2.1.0, CryptoES PBKDF2 is 1,000 times weaker than originally specified in 1993, and at least 1,300,000 times weaker than current industry standard. This is because it both defaults to SHA1, a cryptographic hash algorithm considered insecure since at least 2005, and defaults to one single iteration, a 'strength' or 'difficulty' value specified at 1,000 when specified in 1993. PBKDF2 relies on iteration count as a countermeasure to preimage and collision attacks. If used to protect passwords, the impact is high. If used to generate signatures, the impact is high. Version 2.1.0 contains a patch for this issue. As a workaround, configure CryptoES to use SHA256 with at least 250,000 iterations. |
| Inadequate encryption strength in mycli 1.27.0 allows attackers to view sensitive information via /mycli/config.py |
| Eaton easyE4 PLC offers a device password protection functionality to facilitate a secure connection and prevent unauthorized access. It was observed that the device password was stored with a weak encoding algorithm in the easyE4 program file when exported to SD card (*.PRG file ending). |
| Inadequate encryption strength vulnerability in multiple routers provided by ELECOM CO.,LTD. and LOGITEC CORPORATION allows a network-adjacent unauthenticated attacker to guess the encryption key used for wireless LAN communication and intercept the communication. As for the affected products/versions, see the information provided by the vendor under [References] section. |
|
Due to the implementation of "deriveVaultKey", prior to version 7.10, the generated vault key
would always have the last 16 bytes predetermined to be "arfoobarfoobarfo".
This issue happens because "deriveVaultKey" calls "retrieveCloudKey" (which will always
return "foobarfoobarfoobarfoobarfoobarfo" as the key), and then merges the 32byte
randomly generated key with this key (by takeing 16bytes from each, see "mergeKeys").
This makes the key a lot weaker.
This issue does not persist in devices that were initialized on/after version 7.10, but devices
that were initialized before that and updated to a newer version still have this issue.
Roll an update that enforces the full 32bytes key usage.
|
|
Vault Key Sealed With SHA1 PCRs
The measured boot solution implemented in EVE OS leans on a PCR locking mechanism.
Different parts of the system update different PCR values in the TPM, resulting in a unique
value for each PCR entry.
These PCRs are then used in order to seal/unseal a key from the TPM which is used to
encrypt/decrypt the “vault” directory.
This “vault” directory is the most sensitive point in the system and as such, its content should
be protected.
This mechanism is noted in Zededa’s documentation as the “measured boot” mechanism,
designed to protect said “vault”.
The code that’s responsible for generating and fetching the key from the TPM assumes that
SHA256 PCRs are used in order to seal/unseal the key, and as such their presence is being
checked.
The issue here is that the key is not sealed using SHA256 PCRs, but using SHA1 PCRs.
This leads to several issues:
• Machines that have their SHA256 PCRs enabled but SHA1 PCRs disabled, as well
as not sealing their keys at all, meaning the “vault” is not protected from an attacker.
• SHA1 is considered insecure and reduces the complexity level required to unseal the
key in machines which have their SHA1 PCRs enabled.
An attacker can very easily retrieve the contents of the “vault”, which will effectively render
the “measured boot” mechanism meaningless.
|
| PCR14 is not in the list of PCRs that seal/unseal the “vault” key, but
due to the change that was implemented in commit
“7638364bc0acf8b5c481b5ce5fea11ad44ad7fd4”, fixing this issue alone would not solve the
problem of the config partition not being measured correctly.
Also, the “vault” key is sealed/unsealed with SHA1 PCRs instead of
SHA256.
This issue was somewhat mitigated due to all of the PCR extend functions
updating both the values of SHA256 and SHA1 for a given PCR ID.
However, due to the change that was implemented in commit
“7638364bc0acf8b5c481b5ce5fea11ad44ad7fd4”, this is no longer the case for PCR14, as
the code in “measurefs.go” explicitly updates only the SHA256 instance of PCR14, which
means that even if PCR14 were to be added to the list of PCRs sealing/unsealing the “vault”
key, changes to the config partition would still not be measured.
An attacker could modify the config partition without triggering the measured boot, this could
result in the attacker gaining full control over the device with full access to the contents of the
encrypted “vault”
|
| EisBaer Scada - CWE-321: Use of Hard-coded Cryptographic Key |
| The device is observed to accept deprecated TLS protocols, increasing the risk of cryptographic weaknesses. |
| The server supports at least one cipher suite which is on the NCSC-NL list of cipher suites to be phased out, increasing the risk of cryptographic weaknesses. |
| Vulnerability of 5G messages being sent without being encrypted in a VPN environment in the SMS message module. Successful exploitation of this vulnerability may affect confidentiality. |
| Symmetric encryption used to protect messages between the AppsAnywhere server and client can be broken by reverse engineering the client and used to impersonate the AppsAnywhere server. |
|
Several versions of
ALEOS, including ALEOS 4.16.0, use a hardcoded
SSL certificate and
private key. An attacker with access to these items
could potentially
perform a man in the middle attack between the
ACEManager client
and ACEManager server.
|
| IBM AIX 7.2, 7.3, VIOS 3.1's OpenSSH implementation could allow a non-privileged local user to access files outside of those allowed due to improper access controls. IBM X-Force ID: 263476. |
| uthenticode is a small cross-platform library for partially verifying Authenticode digital signatures. Versions of uthenticode prior to the 2.x series did not check Extended Key Usages in certificates, in violation of the Authenticode X.509 certificate profile. As a result, a malicious user could produce a "signed" PE file that uthenticode would verify and consider valid using an X.509 certificate that isn't entitled to produce code signatures (e.g., a SSL certificate). By design, uthenticode does not perform full-chain validation. However, the absence of EKU validation was an unintended oversight. The 2.0.0 release series includes EKU checks. There are no workarounds to this vulnerability. |
| Use of Hard-coded Cryptographic Key vulnerability in Sifir Bes Education and Informatics Kunduz - Homework Helper App allows Authentication Abuse, Authentication Bypass.This issue affects Kunduz - Homework Helper App: before 6.2.3.
|
| A Cryptographic Issue vulnerability has been found on IBERMATICA RPS, affecting version 2019. By firstly downloading the log file, an attacker could retrieve the SQL query sent to the application in plaint text. This log file contains the password hashes coded with AES-CBC-128 bits algorithm, which can be decrypted with a .NET function, obtaining the username's password in plain text. |
|
** UNSUPPORTED WHEN ASSIGNED ** [An attacker can capture an authenticating hash
and utilize it to create new sessions. The hash is also a poorly salted MD5
hash, which could result in a successful brute force password attack. Impacted product is BCM-WEB version 3.3.X. Recommended fix: Upgrade to a supported product such
as Alerton
ACM.] Out of an abundance of caution, this CVE ID is being assigned to
better serve our customers and ensure all who are still running this product understand
that the product is end of life and should be removed or upgraded.
|
| A compliance problem was found in the Red Hat OpenShift Container Platform. Red Hat discovered that, when FIPS mode was enabled, not all of the cryptographic modules in use were FIPS-validated. |
